< draft-lior-radius-prepaid-extensions-06.txt   draft-lior-radius-prepaid-extensions-07.txt >
Network Working Group A. Lior Network Working Group A. Lior
INTERNET-DRAFT Bridgewater Systems INTERNET-DRAFT Bridgewater Systems
Category: Informational P. Yegani Category: Informational P. Yegani
draft-lior-radius-prepaid-extensions-06.txt Cisco draft-lior-radius-prepaid-extensions-07.txt Cisco
Expires: 24 March, 2005 K. Chowdhury Expires: 20 July, 2005 K. Chowdhury
Nortel Starent Networks
Y. Li Y. Li
Bridgewater Systems Bridgewater Systems
C. Guenther C. Guenther
Siemens Siemens
October 25, 2004 February 20, 2005
PrePaid Extensions to Remote Authentication Dial-In User Service PrePaid Extensions to Remote Authentication Dial-In User Service
(RADIUS) (RADIUS)
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance and any of which I become aware will be disclosed, in accordance
with RFC 3668. with RFC 3668.
skipping to change at page 1, line 41 skipping to change at page 1, line 40
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 24, 2005 This Internet-Draft will expire on July 20, 2005
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This draft presents an extension to the Remote Authentication Dial- This draft presents an extension to the Remote Authentication Dial-
In User Service (RADIUS) protocol to support charging for prepaid In User Service (RADIUS) protocol to support charging for prepaid
services. The charging models supported are namely: volume-based services. The charging models supported are namely: volume-based
charging, duration-based charging and one-time-based charging. charging, duration-based charging and one-time-based charging.
Table of Contents Table of Contents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
2. Overview.......................................................6 2. Overview.......................................................6
2.1 PrePaid Charging Model.....................................7 2.1 PrePaid Charging Model.....................................7
2.2 Architectural Model........................................7 2.2 Architectural Model........................................7
2.3 Why not existing RADIUS attributes?.......................13 2.3 Why not existing RADIUS attributes?.......................13
3. Use-cases.....................................................15 3. Use-cases.....................................................15
3.1 Simple pre-paid access use-case...........................15 3.1 Simple pre-paid access use-case...........................15
3.2 Support for Multi-Services................................17 3.2 Support for Multi-Services................................17
3.3 Resource Pools............................................18 3.3 Resource Pools............................................18
3.4 Support for Complex Rating Functions......................20 3.4 Support for Complex Rating Functions......................20
3.5 One-Time-based Prepaid Charging...........................21 3.5 One-Time-based Prepaid Charging...........................21
3.6 Support for Roaming.......................................22 3.6 Support for Tariff Switching..............................22
3.7 PrePaid termination.......................................23 3.7 Support for Roaming.......................................24
3.8 Querying and Rebalancing Prepaid Resources................23 3.8 PrePaid termination.......................................24
4. Operations....................................................24 3.9 Querying and Rebalancing Prepaid Resources................25
4.1 General Requirements......................................24 4. Operations....................................................25
4.1.1 Broker AAA Requirements..............................24 4.1 General Requirements......................................25
4.2 Authentication and Authorization for Prepaid Enabled SADs.24 4.1.1 Broker AAA Requirements..............................25
4.3 Session Start Operation...................................26 4.2 Authentication and Authorization for Prepaid Enabled SADs.26
4.4 Mid-Session Operation.....................................27 4.3 Session Start Operation...................................28
4.5 Dynamic Operations........................................29 4.4 Mid-Session Operation.....................................29
4.5.1 Unsolicited Session Termination Operation............30 4.5 Dynamic Operations........................................31
4.5.2 Unsolicited Change of Authorization Operation........30 4.5.1 Unsolicited Session Termination Operation............31
4.6 Termination Operation.....................................31 4.5.2 Unsolicited Change of Authorization Operation........32
4.7 Mobile IP Operations......................................31 4.6 Termination Operation.....................................32
4.8 Operation consideration for Multi-Services................32 4.7 Mobile IP Operations......................................33
4.8.1 Initial Quota Request................................33 4.8 Operation consideration for Multi-Services................34
4.8.2 Quota Update.........................................33 4.8.1 Initial Quota Request................................34
4.8.3 Termination..........................................34 4.8.2 Quota Update.........................................35
4.8.4 Dynamic Operations...................................34 4.8.3 Termination..........................................35
4.8.5 Support for Resource Pools...........................35 4.8.4 Dynamic Operations...................................36
4.8.6 One-Time-Charging....................................35 4.8.5 Support for Resource Pools...........................36
4.8.7 Error Handling.......................................36 4.8.6 One-Time-Charging....................................36
4.9 Accounting Considerations.................................36 4.8.7 Error Handling.......................................37
4.10 SAD Operation............................................36 4.9 Accounting Considerations.................................38
4.11 Interoperability with Diameter Credit Control Application36 4.10 SAD Operation............................................38
5. Attributes....................................................37 4.11 Interoperability with Diameter Credit Control Application38
5.1 PPAC Attribute............................................37 5. Attributes....................................................38
5.2 Session Termination Capability............................38 5.1 PPAC Attribute............................................39
5.3 PPAQ Attribute............................................38 5.2 Session Termination Capability............................40
5.4 Table of Attributes.......................................44 5.3 PPAQ Attribute............................................40
6. Security Considerations.......................................44 5.4 Prepaid Tariff Switching (PTS)............................46
6.1 Authentication and Authorization..........................45 5.5 Table of Attributes.......................................49
6.2 Replenishing Procedure....................................45 6. Security Considerations.......................................49
7. IANA Considerations...........................................45 6.1 Authentication and Authorization..........................49
8. Normative References..........................................46 6.2 Replenishing Procedure....................................50
9. Informative References........................................46 7. IANA Considerations...........................................50
10. Call Flows...................................................47 8. Normative References..........................................51
10.1 Simple Concurrent Services...............................48 9. Informative References........................................51
10.2 One-time Charging........................................50 10. Call Flows...................................................52
Contributor......................................................51 10.1 Simple Concurrent Services...............................53
Acknowledgments..................................................51 10.2 One-time Charging........................................55
Author's Addresses...............................................51 Contributor......................................................56
Intellectual Property Statement..................................52 Acknowledgments..................................................56
Disclaimer of Validity...........................................52 Author's Addresses...............................................56
Copyright Statement..............................................52 Intellectual Property Statement..................................57
Expiration Date..................................................53 Disclaimer of Validity...........................................57
Copyright Statement..............................................57
Expiration Date..................................................58
1. Introduction 1.
Introduction
This draft describes RADIUS protocol extensions supporting charging This draft describes RADIUS protocol extensions supporting charging
for PrePaid Data Services. for PrePaid Data Services.
PrePaid data services are cropping up in many wireless and wireline PrePaid data services are cropping up in many wireless and wireline
based networks. A PrePaid Data Service subscriber is one that based networks. A PrePaid Data Service subscriber is one that
purchases a contract to receive a data service for either a period purchases a contract to receive a data service for either a period
of time, or a quantity of data. Before providing a prepaid data of time, or a quantity of data. Before providing a prepaid data
service, the service provider checks that the prepaid subscriber has service, the service provider checks that the prepaid subscriber has
sufficient funds to cover the particular service request. Only after sufficient funds to cover the particular service request. Only after
skipping to change at page 5, line 6 skipping to change at page 5, line 6
- Ability to rate service requests in real-time; - Ability to rate service requests in real-time;
- Ability to check that the end userÆs account for coverage for the - Ability to check that the end userÆs account for coverage for the
requested service charge prior to execution of that service; requested service charge prior to execution of that service;
- Protect against revenue loss, i.e., prevent an end user from - Protect against revenue loss, i.e., prevent an end user from
generating chargeable events when the credit of that account is generating chargeable events when the credit of that account is
exhausted or expired; exhausted or expired;
- Protect against fraud; - Protect against fraud;
- Be as widely deployable over Dialup, Wireless and WLAN networks. - Be as widely deployable over Dialup, Wireless and WLAN networks.
The protocol described in this document maximizes existing The protocol described in this document maximizes existing
infrastructure as much as possible hence the use of the RADIUS infrastructure as much as possible û hence the use of the RADIUS
protocol. The protocol is used in ways to protect against revenue protocol. The protocol is used in ways to protect against revenue
loss or revenue leakage. This is achieved by defining procedures loss or revenue leakage. This is achieved by defining procedures
for the real-time delivery of service information to a pre-paid for the real-time delivery of service information to a pre-paid
enabled AAA server, to minimize the financial risk, for the pre-paid enabled AAA server, to minimize the financial risk, for the pre-paid
enabled AAA server to be able to allocate small quotas to each data enabled AAA server to be able to allocate small quotas to each data
session and having the ability to update the quotas from a central session and having the ability to update the quotas from a central
quota server dynamically during the lifetime of the PrePaid data quota server dynamically during the lifetime of the PrePaid data
session. As well, mechanisms have been designed to be able to session. As well, mechanisms have been designed to be able to
recover from errors that occur from time to time. recover from errors that occur from time to time.
skipping to change at page 6, line 5 skipping to change at page 6, line 5
available which, through co-ordination with the rating entity and available which, through co-ordination with the rating entity and
centralized balance manager is able to provide a quota response in centralized balance manager is able to provide a quota response in
response for prepaid data service. This quota server functionality response for prepaid data service. This quota server functionality
could be performed in the prepaid enabled AAA server or may exist in could be performed in the prepaid enabled AAA server or may exist in
an entity behind this AAA server. Finally, the details of the an entity behind this AAA server. Finally, the details of the
PrePaid System, such as its persistent store, how it maintains its PrePaid System, such as its persistent store, how it maintains its
accounts are not covered at all. However, in order to define the accounts are not covered at all. However, in order to define the
RADIUS protocol extensions it is necessary to discuss the functional RADIUS protocol extensions it is necessary to discuss the functional
behavior of the PrePaid System. behavior of the PrePaid System.
1.1 Terminology 1.1
Terminology
Service Access Device Service Access Device
PrePaid Client(PPC) The Prepaid Client (PPC) is the entity which PrePaid Client(PPC) The Prepaid Client (PPC) is the entity which
triggers the RADIUS message exchange triggers the RADIUS message exchange
including prepaid extensions defined in this including prepaid extensions defined in this
document. Typically the Prepaid Client document. Typically the Prepaid Client
Resides in the NAS. Resides in the NAS.
PrePaid Server(PPS) The Prepaid Server is the entity that PrePaid Server(PPS) The Prepaid Server is the entity that
interacts with the Prepaid Client using the interacts with the Prepaid Client using the
RADIUS prepaid extensions defined in this RADIUS prepaid extensions defined in this
skipping to change at page 6, line 34 skipping to change at page 6, line 35
used to differentiate between authorization used to differentiate between authorization
of services that are explicitly identified of services that are explicitly identified
by a Service Identifier. Example of Access by a Service Identifier. Example of Access
Service would be the Main Service instance Service would be the Main Service instance
of 3GPP2. of 3GPP2.
Furthermore, we use the following Mobile IP and AAA terminology: Furthermore, we use the following Mobile IP and AAA terminology:
Home agent (HA), Home network, Home AAA (HAAA), Broker AAA (BAAA), Home agent (HA), Home network, Home AAA (HAAA), Broker AAA (BAAA),
Visited AAA (VAAA) and Foreign Agent (FA) Visited AAA (VAAA) and Foreign Agent (FA)
1.2 Requirements language 1.2
Requirements language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
2. Overview 2.
Overview
This section gives a concise overview of the Prepaid Charging models This section gives a concise overview of the Prepaid Charging models
that is supported by this document, and the Architectural model that is supported by this document, and the Architectural model
relevant to this draft. relevant to this draft.
2.1 PrePaid Charging Model 2.1
PrePaid Charging Model
There are several PrePaid Charging models of how to charge customers There are several PrePaid Charging models of how to charge customers
for availing data services: for availing data services:
. Volume-based charging (VBC): (e.g., 2 Cents/KiloByte); . Volume-based charging (VBC): (e.g., 2 Cents/KiloByte);
. Duration-based charging (DBC): (e.g., 3 Cents/minute); . Duration-based charging (DBC): (e.g., 3 Cents/minute);
. Subscription-based charging (SBC): (e.g., . Subscription-based charging (SBC): (e.g.,
Dollars/month+service);), Dollars/month+service);),
. Event-based charging (EBC): (e.g., 7 Cents/URL or email). . Event-based charging (EBC): (e.g., 7 Cents/URL or email).
Charging models can be further divided into those with debiting of Charging models can be further divided into those with debiting of
prepaid user accounts and those with debiting of non-prepaid prepaid user accounts and those with debiting of non-prepaid
accounts (such as current accounts at banks). From the perspective accounts (such as current accounts at banks). From the perspective
of this document all userÆs as treated as userÆs having a prepaid of this document all userÆs as treated as userÆs having a prepaid
accounts. accounts.
2.2 Architectural Model 2.2
Architectural Model
The architectural model supports prepaid clients on a service access The architectural model supports prepaid clients on a service access
device. A SAD (e.g. a NAS) typically provides a access to data device. A SAD (e.g. a NAS) typically provides a access to data
service to end-users. A SAD is a network entity on the data path service to end-users. A SAD is a network entity on the data path
that includes a RADIUS client and a PrePaid Client. that includes a RADIUS client and a PrePaid Client.
When prepaid service is used the SAD collects service event When prepaid service is used the SAD collects service event
information and reports it while and/or after services are provided information and reports it while and/or after services are provided
to the prepaid user. This event information is sent to a prepaid to the prepaid user. This event information is sent to a prepaid
server by using the prepaid RADIUS extensions. server by using the prepaid RADIUS extensions.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
As well, notice that if the SADs could communicate with each other As well, notice that if the SADs could communicate with each other
then there could be a way to accelerate a faster handoff procedure. then there could be a way to accelerate a faster handoff procedure.
In particular, it could accelerate the return of the unused portion In particular, it could accelerate the return of the unused portion
of the quotas from the old Access Device. of the quotas from the old Access Device.
Unfortunately, standards with regards to handoff are evolving with Unfortunately, standards with regards to handoff are evolving with
each network technology creating their own scheme to make the each network technology creating their own scheme to make the
handoff procedures more efficient. handoff procedures more efficient.
2.3 Why not existing RADIUS attributes? 2.3
Why not existing RADIUS attributes?
It has been asked "Why not use existing RADIUS attributes to build a It has been asked ôWhy not use existing RADIUS attributes to build a
prepaid solution? This will allow us to have a solution with prepaid solution? This will allow us to have a solution with
existing devices without code modification." existing devices without code modification.ö
It is possible to build a prepaid solution using existing RADIUS It is possible to build a prepaid solution using existing RADIUS
attributes. The RADIUS server can simply send an Access-Accept attributes. The RADIUS server can simply send an Access-Accept
message containing Session-Timeout(27) and set Termination- message containing Session-Timeout(27) and set Termination-
Action(29) to RADIUS-request. Upon receiving the Access-Accept Action(29) to RADIUS-request. Upon receiving the Access-Accept
message, the NAS will meter the duration of the session and upon message, the NAS will meter the duration of the session and upon
termination of the session the NAS generate an Access-Request termination of the session the NAS generate an Access-Request
message again. The RADIUS server would re-authenticate the session message again. The RADIUS server would re-authenticate the session
and reply with an Access-Accept message with additional time in and reply with an Access-Accept message with additional time in
Session-Timeout(27) or an Access-Reject message if there were no Session-Timeout(27) or an Access-Reject message if there were no
skipping to change at page 15, line 21 skipping to change at page 15, line 21
generate an Access-Request Authorize-Only packet to obtain more generate an Access-Request Authorize-Only packet to obtain more
quota at or before the quota is used up. It also requires that the quota at or before the quota is used up. It also requires that the
NAS send an Access-Request with Authorize-Only when the session NAS send an Access-Request with Authorize-Only when the session
terminates to return any unused quota to the prepaid system. terminates to return any unused quota to the prepaid system.
Lastly the solution provided in this document is extensible. This Lastly the solution provided in this document is extensible. This
document defines the basic exchanges between a prepaid capable NAS document defines the basic exchanges between a prepaid capable NAS
and a RADIUS server. The protocol can easily be extended to support and a RADIUS server. The protocol can easily be extended to support
tariff switching and other prepaid business models. tariff switching and other prepaid business models.
3. Use-cases 3.
Use-cases
In this section we present a set of use cases that help establish In this section we present a set of use cases that help establish
the requirements needed to deliver PrePaid data services. These the requirements needed to deliver PrePaid data services. These
use-cases donÆt address how the PrePaid account is established or use-cases donÆt address how the PrePaid account is established or
maintained. It is assumed that the PrePaid subscriber has obtained maintained. It is assumed that the PrePaid subscriber has obtained
a valid account from a service provider such as a wireless operator a valid account from a service provider such as a wireless operator
or a WLAN operator. or a WLAN operator.
To make the document as general as possible, the use cases cover the To make the document as general as possible, the use cases cover the
experience from the SAD and not from the UserÆs Device. The experience from the SAD and not from the UserÆs Device. The
connection between the UserÆs Device, which typically involves connection between the UserÆs Device, which typically involves
setting up a layer 2 session, e.g., PPP session or GPRS PDP Context, setting up a layer 2 session, e.g., PPP session or GPRS PDP Context,
is specific to a given network technology and the details are not is specific to a given network technology and the details are not
required to deliver a PrePaid service. required to deliver a PrePaid service.
3.1 Simple pre-paid access use-case 3.1
Simple pre-paid access use-case
A PrePaid subscriber connects to his home network. As usual, the A PrePaid subscriber connects to his home network. As usual, the
Access Device that is servicing the subscriber will use the AAA Access Device that is servicing the subscriber will use the AAA
infrastructure to authenticate and authorize the subscriber. infrastructure to authenticate and authorize the subscriber.
The SAD sends a RADIUS Access-Request to the AAA system to The SAD sends a RADIUS Access-Request to the AAA system to
authenticate the subscriber, and identify and authorize the service. authenticate the subscriber, and identify and authorize the service.
The Access-Request includes the subscriberÆs credentials and may The Access-Request includes the subscriberÆs credentials and may
include the PrePaid capabilities of the SAD. PrePaid capabilities include the PrePaid capabilities of the SAD. PrePaid capabilities
MUST be included if the SAD supports PrePaid functionality. MUST be included if the SAD supports PrePaid functionality.
skipping to change at page 17, line 38 skipping to change at page 17, line 38
Service. Service.
Should the subscriber terminate the session before the quota is used Should the subscriber terminate the session before the quota is used
up, the remaining balance allotted to the session must be credited up, the remaining balance allotted to the session must be credited
back to the subscriberÆs account. back to the subscriberÆs account.
As well, while the Access Device is waiting for the initial quota, As well, while the Access Device is waiting for the initial quota,
the subscriber may have dropped the session. The initial quota must the subscriber may have dropped the session. The initial quota must
be credited back to the subscribers account. be credited back to the subscribers account.
3.2 Support for Multi-Services 3.2
Support for Multi-Services
Up to now we were looking at session that consisted of a single Up to now we were looking at session that consisted of a single
service, "Access Service". An "Access Service" is the basic service service, ôAccess Serviceö. An ôAccess Serviceö is the basic service
that is provided to the user by the SAD after successful that is provided to the user by the SAD after successful
authentication and authorization. When we donÆt differentiate authentication and authorization. When we donÆt differentiate
between different types of services the "Access Service" aggregates between different types of services the ôAccess Serviceö aggregates
all the services that the user my be engaged in on a particular SAD. all the services that the user my be engaged in on a particular SAD.
For example, the user may be browsing the web, and participating in For example, the user may be browsing the web, and participating in
a VoIP conversation, watching streaming video and downloading a a VoIP conversation, watching streaming video and downloading a
file. file.
Some operators may want to distinguish between these services. Some Some operators may want to distinguish between these services. Some
services are billed at different rates and services maybe metered services are billed at different rates and services maybe metered
differently. Therefore, the prepaid solution needs to be able to differently. Therefore, the prepaid solution needs to be able to
distinguish services, and allocate quotas to the services using distinguish services, and allocate quotas to the services using
skipping to change at page 18, line 33 skipping to change at page 18, line 33
| (service-Id) | +-------+ | (service-Id) | +-------+
+--------------+ +--------------+
As shown in the above diagram, a Session can have N Services. Each As shown in the above diagram, a Session can have N Services. Each
service is identified by a Service-Id. The format of the Service-Id service is identified by a Service-Id. The format of the Service-Id
is not in the scope of this document but the Service-Id could be is not in the scope of this document but the Service-Id could be
expressed as an IP flow using the stand 5-tuple (Source-IP and Port, expressed as an IP flow using the stand 5-tuple (Source-IP and Port,
the Destination-IP and Port, and the protocol type). Each service the Destination-IP and Port, and the protocol type). Each service
is allocated an appropriate quota. is allocated an appropriate quota.
3.3 Resource Pools 3.3
Resource Pools
When working with multiple services that results in multiple quota When working with multiple services that results in multiple quota
allocation another problem arises. Even though quotas are portioned allocation another problem arises. Even though quotas are portioned
out in fractional parts of the userÆs prepaid account, there could out in fractional parts of the userÆs prepaid account, there could
be a situation where one Service utilizes its quota faster then be a situation where one Service utilizes its quota faster then
another Service. When the userÆs account is used up, there could be another Service. When the userÆs account is used up, there could be
a situation where one Service is unable to obtain additional quota a situation where one Service is unable to obtain additional quota
while another Service has plenty of quota remaining. Unless the while another Service has plenty of quota remaining. Unless the
quotas can be rebalanced, the SAD would then have to terminate that quotas can be rebalanced, the SAD would then have to terminate that
Service. As well, even before that happens, the existence of Service. As well, even before that happens, the existence of
skipping to change at page 20, line 11 skipping to change at page 20, line 11
is, Service-A can be rated at $1 per Mbyte and Service-B can rated is, Service-A can be rated at $1 per Mbyte and Service-B can rated
at $0.10 per Minute. In this case if we allocate $5 worth of at $0.10 per Minute. In this case if we allocate $5 worth of
resources on behalf of service-A to the pool we would set Ma = 10 resources on behalf of service-A to the pool we would set Ma = 10
and place 50 units into the pool. If we allocate $5 on behalf of and place 50 units into the pool. If we allocate $5 on behalf of
Service-B to the Pool, then M=1 and place 50 units into the Pool. Service-B to the Pool, then M=1 and place 50 units into the Pool.
The pool would have a total sum of 100 units to be shared between The pool would have a total sum of 100 units to be shared between
the two services. Each Mbyte used by Service-A will draw 10 units the two services. Each Mbyte used by Service-A will draw 10 units
from the pool and each minute used by Service-B will draw 1 unit from the pool and each minute used by Service-B will draw 1 unit
from the pool. from the pool.
3.4 Support for Complex Rating Functions 3.4
Support for Complex Rating Functions
The rate of use of a resource by a service can be very complex. The rate of use of a resource by a service can be very complex.
Some services use resources (e.g. time, volume) linearly. For Some services use resources (e.g. time, volume) linearly. For
example, a service maybe consuming resources at a rate of $1 per example, a service maybe consuming resources at a rate of $1 per
Mbyte. Mbyte.
In some cases an operator may wish to apply a much more complex In some cases an operator may wish to apply a much more complex
rating function. For example, a service provider may wish to rate a rating function. For example, a service provider may wish to rate a
service such that the first N Mbytes are free, then the next M service such that the first N Mbytes are free, then the next M
Mbytes are rated at $1 per Mbyte and volume above M bytes be rated Mbytes are rated at $1 per Mbyte and volume above M bytes be rated
skipping to change at page 21, line 10 skipping to change at page 21, line 10
associated with a Rating Group, the Prepaid Client sends the Rating associated with a Rating Group, the Prepaid Client sends the Rating
Group to the Prepaid Server. The prepaid service authorizes the Group to the Prepaid Server. The prepaid service authorizes the
Rating Group by assigning it a Quota and optionally assigning it to Rating Group by assigning it a Quota and optionally assigning it to
a Resource Pool. a Resource Pool.
When service that belongs to an authorized Rating Group is When service that belongs to an authorized Rating Group is
instantiated, then the Prepaid Client does not need to authorize instantiated, then the Prepaid Client does not need to authorize
that service. This could greatly reduce the amount of traffic that service. This could greatly reduce the amount of traffic
between the Prepaid Client and the Prepaid Server. between the Prepaid Client and the Prepaid Server.
3.5 One-Time-based Prepaid Charging 3.5
One-Time-based Prepaid Charging
One-Time-based Prepaid Charging is used for charging of Service One-Time-based Prepaid Charging is used for charging of Service
Events where there is no session. That is, the Service Event does Events where there is no session. That is, the Service Event does
not have a start or an end. An example of a one-time service event not have a start or an end. An example of a one-time service event
is the purchase of a ring-tone. The one-time event in this case is is the purchase of a ring-tone. The one-time event in this case is
the userÆs purchasing the right to use a ring-tone. The actual the userÆs purchasing the right to use a ring-tone. The actual
downloading of the tone is a separate service event totally distinct downloading of the tone is a separate service event totally distinct
from the right to use the ring tone. For example, the user may have from the right to use the ring tone. For example, the user may have
already downloaded the tone and then after being totally satisfied already downloaded the tone and then after being totally satisfied
with the quality, decides to purchase the right to use the tone. with the quality, decides to purchase the right to use the tone.
skipping to change at page 22, line 19 skipping to change at page 22, line 19
the subscription server may not have access to the authentication the subscription server may not have access to the authentication
context of the subscriber and thus will have to authenticate the context of the subscriber and thus will have to authenticate the
subscriber. Authentication of the subscriber and the generation of subscriber. Authentication of the subscriber and the generation of
the one-time charging event will happen at the same time. the one-time charging event will happen at the same time.
Note that one-time-based charging can be used to credit the prepaid Note that one-time-based charging can be used to credit the prepaid
userÆs account. For example, the SAD can return resources back to userÆs account. For example, the SAD can return resources back to
the prepaid subscriber by making a one-time charge request that the prepaid subscriber by making a one-time charge request that
includes the amount of resource to be credited back to the user. includes the amount of resource to be credited back to the user.
3.6 Support for Roaming 3.6
Support for Tariff Switching
The PPC and the PPS may support tariff switching for volume based
prepaid packet service. Tariff switching allows the PPS to signal
the PPC when a change of rating or tariff switch is to occur. For
example as shown in the figure below, traffic before 18:00 hours is
rated at ær1Æ or business rates and traffic after 18:00 hours is
rated at ær2Æ or non-business rates. The PPC will then be able to
report usage before the tariff switch point and usage after the
tariff switch point. Since time is measured in seconds, tariff
switching only makes sense for volume based prepaid service where
the volume is billed at different rates: one rate before the tariff
switch period and another rate after the tariff switch period.
18:00
------------------+-----------------
r1 | r2
------------------+-----------------
^ ^
|<----TSI---> |
| |
Access-Accept Access-Request
When tariff switching is supported by the PPC it indicates support
for tariff switching by setting the appropriate bit in the PPAC. If
the PPS requires to signal a tariff switch time it will send a PTS
attribute which will indicate when the tariff switch period is to
occur as a number of seconds from the current time
(TarrifSwitchInterval TSI).
Sometime after the tariff switch period the PPC will send another
online Access-Request. Either the user has logged off or the volume
threshold has been reached. The PPC will report how much volume was
used using the PPAQ and how much volume was used after the tariff
switch using the PTSÆs VUATS subtype.
If the PPC will send and event before the tariff switch time, say
the Volume threshold has been reached, the PPS will respond with
another PTS with the TSI indicating how many seconds until the
tariff switch time.
In situations where there is going to be another tariff switch
period, as shown below, the PPS MUST specify the length of the
tariff switch period using the TimeIntervalAfterTariffSwitchUpdate
(TITSU) in the PTS attribute.
18:00 23:30
------------------+---------------------+--------------
r1 | r2 | r3
------------------+---------------------+--------------
^ ^ ^
|<----TSI---><-----------|-------->|TITSU
| |
Access-Accept Access-Request
When TITSU is specified in the PTS, the PPC MUST generate an online
Access-Request within the time after TSI and before TITSU expires.
Normally the PPC will be triggered by the Volume Threshold, but
there is no guarantee that the user session will generate any volume
during the period between 18:00 and 23:30 hours. If TITSU was not
specified in this case, then if there was some volume generated
during r2 but not enough to trigger a prepaid update before the next
tariff switch at 23:30. Then the PPC will not be able to report how
much volume was generated during r1, r2, and r3.
When prepaid for multiple flows is supported, then each flow could
have it own tariff switch period. For example, best effort flow may
not have a tariff switch associated with it, yet a voice over IP
call may have a tariff switch period. The Voice over IP call may
bill at one rate for the first 5 minutes and another rate for the
rest of the call.
[EDITORÆS NOTE: Need to consider tariff switching with pools. Is it
worthwhile?]
3.7
Support for Roaming
For some networks it is essential that PrePaid Data Services be For some networks it is essential that PrePaid Data Services be
offered to roaming subscribers. Support for static and dynamic offered to roaming subscribers. Support for static and dynamic
roaming models are needed. Static roaming is where the subscriber roaming models are needed. Static roaming is where the subscriber
logs onto a foreign network. The foreign network has a roaming logs onto a foreign network. The foreign network has a roaming
agreement directly with the home network or through a broker network agreement directly with the home network or through a broker network
or networks. The subscriber remains logged into the network until or networks. The subscriber remains logged into the network until
the subscriber changes location. When changing location a new the subscriber changes location. When changing location a new
connection and a new login procedure is required. connection and a new login procedure is required.
skipping to change at page 23, line 5 skipping to change at page 24, line 37
In both roaming scenarios, the subscriber always authenticates with In both roaming scenarios, the subscriber always authenticates with
the home network. PrePaid authorization and quota replenishing for the home network. PrePaid authorization and quota replenishing for
the session need to be received at the home network and more the session need to be received at the home network and more
specifically at the PrePaid System where state is being maintained. specifically at the PrePaid System where state is being maintained.
Dynamic roaming is particularly challenging. A subscriber that Dynamic roaming is particularly challenging. A subscriber that
established a PrePaid Data Session may roam to another Access Device established a PrePaid Data Session may roam to another Access Device
that doesnÆt not support PrePaid functionality. The system should that doesnÆt not support PrePaid functionality. The system should
be capable to continue the PrePaid session. be capable to continue the PrePaid session.
3.7 PrePaid termination 3.8
PrePaid termination
When fraud is detected by the PrePaid System, or when an error is When fraud is detected by the PrePaid System, or when an error is
detected, it may be beneficial for the PrePaid system to terminate a detected, it may be beneficial for the PrePaid system to terminate a
specific session for the subscriber or all the sessions of a specific session for the subscriber or all the sessions of a
subscriber. subscriber.
Some errors can occur such that the PrePaid System is in a state Some errors can occur such that the PrePaid System is in a state
where it is not sure whether the session is in progress or not. where it is not sure whether the session is in progress or not.
Under conditions such as this, the PrePaid system may wish to Under conditions such as this, the PrePaid system may wish to
terminate the PrePaid data session to make sure that resources are terminate the PrePaid data session to make sure that resources are
not being utilized for which it canÆt charge for reliably. not being utilized for which it canÆt charge for reliably.
Some handoff procedure used during dynamic roaming may require that Some handoff procedure used during dynamic roaming may require that
the PrePaid system explicitly terminate the subscribers PrePaid data the PrePaid system explicitly terminate the subscribers PrePaid data
session at an SAD. For example, if time based PrePaid service is session at an SAD. For example, if time based PrePaid service is
being used and the mobile subscriber performs a dormant handoff, the being used and the mobile subscriber performs a dormant handoff, the
PrePaid System needs to explicitly terminate the PrePaid session at PrePaid System needs to explicitly terminate the PrePaid session at
the old SAD. the old SAD.
3.8 Querying and Rebalancing Prepaid Resources 3.9
Querying and Rebalancing Prepaid Resources
It should be possible to allow the Prepaid Server to Query the It should be possible to allow the Prepaid Server to Query the
current uses state of a prepaid balance at a SAD and adjust the current uses state of a prepaid balance at a SAD and adjust the
prepaid resources. prepaid resources.
For example, a request to the PPS is made (e.g., a one-time charging For example, a request to the PPS is made (e.g., a one-time charging
event) but the userÆs account is depleted but resources have been event) but the userÆs account is depleted but resources have been
allocated to the SAD. The PPS should have a the capability to query allocated to the SAD. The PPS should have a the capability to query
the SAD and if it has the spare resources to reassign the quotas to the SAD and if it has the spare resources to reassign the quotas to
the SAD and to the pending request. Note that the PPS doesnÆt know the SAD and to the pending request. Note that the PPS doesnÆt know
resource usage until the SAD request for more resources. This can resource usage until the SAD request for more resources. This can
be a long time. be a long time.
In the absence of this capability the PPS can minimize the occurance In the absence of this capability the PPS can minimize the
of this scenario by allocated smaller quotas. But the result will occurrence of this scenario by allocated smaller quotas. But the
be many more transactions. The ability to query and to rebalance result will be many more transactions. The ability to query and to
resources provides a good trade-off. rebalance resources provides a good trade-off.
4. Operations 4.
Operations
4.1 General Requirements 4.1
General Requirements
4.1.1 Broker AAA Requirements 4.1.1
Broker AAA Requirements
Broker AAA servers MUST support the Message-Authenticator(80) Broker AAA servers MUST support the Message-Authenticator(80)
attribute as defined in [RFC2869]. If BAAA servers are used, the attribute as defined in [RFC2869]. If BAAA servers are used, the
BAAA servers function is to forward the RADIUS packets as usual to BAAA servers function is to forward the RADIUS packets as usual to
the appropriate RADIUS servers. the appropriate RADIUS servers.
Accounting messages are not needed to deliver a PrePaid service. Accounting messages are not needed to deliver a PrePaid service.
However, accounting messages can be used to keep the PrePaid Server However, accounting messages can be used to keep the PrePaid Server
current as to what is happening with the PrePaid data session. current as to what is happening with the PrePaid data session.
Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the
pass through mode described in [RFC2866]. pass through mode described in [RFC2866].
4.2 Authentication and Authorization for Prepaid Enabled SADs 4.2
Authentication and Authorization for Prepaid Enabled SADs
The SAD initiates the authentication and authorization procedure by The SAD initiates the authentication and authorization procedure by
sending a RADIUS Access-Request to the HAAA. sending a RADIUS Access-Request to the HAAA.
If the SAD has PrePaid Client capabilities, it MUST include the If the SAD has PrePaid Client capabilities, it MUST include the
PPAC(TBD) attribute in the RADIUS Access-Request. The PPAC(TBD) PPAC(TBD) attribute in the RADIUS Access-Request. The PPAC(TBD)
attribute indicates to the PrePaid server the PrePaid capabilities attribute indicates to the PrePaid server the PrePaid capabilities
possessed by the SAD. These are required in order to complete the possessed by the SAD. These are required in order to complete the
PrePaid authorization procedures. PrePaid authorization procedures.
skipping to change at page 26, line 27 skipping to change at page 28, line 16
termination of a pre-paid service following subscriber inactivity. termination of a pre-paid service following subscriber inactivity.
Depending on site policies, upon unsuccessful authorization, the Depending on site policies, upon unsuccessful authorization, the
PrePaid server will generate an Access-Reject to terminate the PrePaid server will generate an Access-Reject to terminate the
session immediately. Alternatively, the PrePaid server may generate session immediately. Alternatively, the PrePaid server may generate
an Access-Accept blocking some or all of the traffic and/or redirect an Access-Accept blocking some or all of the traffic and/or redirect
some or all of the traffic to a location where the subscriber can some or all of the traffic to a location where the subscriber can
replenish their account for a period of time. Blocking of traffic replenish their account for a period of time. Blocking of traffic
is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect is achieved by either Filter-Id(11) or NAS-Filter-Rule(see Redirect
I-d). Redirection is achieved by sending Redirect-Id or Redirect- I-d). Redirection is achieved by sending Redirect-Id or Redirect-
Rule defined in the Redirect I-d. The period of time before the Rule, HTTP Redirection defined in the Redirect I-d. The period of
blocked/redirected session last can be specified by Session- time before the blocked/redirected session last can be specified by
Timeout(27) attribute. Session-Timeout(27) attribute.
Upon receiving the Access-Accept from the PrePaid Server, the HAAA Upon receiving the Access-Accept from the PrePaid Server, the HAAA
will append the usual service attributes and forward the packet to will append the usual service attributes and forward the packet to
the SAD. The HAAA SHOULD NOT overwrite any attributes already set the SAD. The HAAA SHOULD NOT overwrite any attributes already set
by the PrePaid server. If the HAAA, receives an Access-Reject by the PrePaid server. If the HAAA, receives an Access-Reject
message, it will simply forward the packet to its client. Depending message, it will simply forward the packet to its client. Depending
on site policies, if the HAAA fails to receive an Access-Accept or on site policies, if the HAAA fails to receive an Access-Accept or
Access-Reject message from the PrePaid server it MAY do nothing or Access-Reject message from the PrePaid server it MAY do nothing or
send an Access-Reject or an Access-Accept message back to its send an Access-Reject or an Access-Accept message back to its
client. client.
4.3 Session Start Operation 4.3
Session Start Operation
The real start of the session is indicated by the arrival of The real start of the session is indicated by the arrival of
Accounting-Request(Start) packet. The Accounting-Request (Start) Accounting-Request(Start) packet. The Accounting-Request (Start)
MAY be routed to the PrePaid Server so that it can confirm the MAY be routed to the PrePaid Server so that it can confirm the
initial quota allocation. initial quota allocation.
Note that the PrePaid Server role is not to record accounting Note that the PrePaid Server role is not to record accounting
messages and therefore it SHOULD not respond with an Accounting messages and therefore it SHOULD not respond with an Accounting
Response packet. Response packet.
skipping to change at page 27, line 20 skipping to change at page 29, line 12
message it will only know that the session has started upon the message it will only know that the session has started upon the
first reception of a quota replenishment operation. first reception of a quota replenishment operation.
If the Prepaid server does not receive indication directly (via If the Prepaid server does not receive indication directly (via
Accounting-Request(start)) or indirectly, it SHOULD after some Accounting-Request(start)) or indirectly, it SHOULD after some
configurable time, deduce that the Session has not started. If the configurable time, deduce that the Session has not started. If the
SAD supports termination capabilities, the PPS SHOULD send a SAD supports termination capabilities, the PPS SHOULD send a
Disconnect Message to the SAD to ensure that the session is indeed Disconnect Message to the SAD to ensure that the session is indeed
dead. dead.
4.4 Mid-Session Operation 4.4
Mid-Session Operation
During the lifetime of a PrePaid data session the SAD will request During the lifetime of a PrePaid data session the SAD will request
to replenish the quotas using Authorize-Only Access-Request to replenish the quotas using Authorize-Only Access-Request
messages. messages.
Once the allocated quota has been reached or the threshold has been Once the allocated quota has been reached or the threshold has been
reached, the SAD MUST send an Access-Request with Service-Type(6) reached, the SAD MUST send an Access-Request with Service-Type(6)
set to a value of "Authorize Only" and the PPAQ(TBD) attribute. set to a value of ôAuthorize Onlyö and the PPAQ(TBD) attribute.
The SAD MUST also include NAS identifiers, and Session identifier The SAD MUST also include NAS identifiers, and Session identifier
attributes in the Authorize Only Access-Request. The Session attributes in the Authorize Only Access-Request. The Session
Identifier should be the same as those used during the Access- Identifier should be the same as those used during the Access-
Request. For example, if the User-Name(1) attribute was used in the Request. For example, if the User-Name(1) attribute was used in the
Access-Request it MUST be included in the Authorize Only Access- Access-Request it MUST be included in the Authorize Only Access-
Request especially if the User-Name(1) attribute is used to route Request especially if the User-Name(1) attribute is used to route
the Access-Request to the Home AAA server. the Access-Request to the Home AAA server.
The Authorize Only Access-Request MUST not include either User The Authorize Only Access-Request MUST not include either User
skipping to change at page 29, line 25 skipping to change at page 31, line 17
Upon receiving an Access-Accept, the SAD SHALL update its quotas and Upon receiving an Access-Accept, the SAD SHALL update its quotas and
threshold parameters with the values contained in the PPAQ(TBD) threshold parameters with the values contained in the PPAQ(TBD)
attribute. Note that the PrePaid server MAY update the attribute. Note that the PrePaid server MAY update the
PrePaidServer attribute(s) and these may have to be saved as well. PrePaidServer attribute(s) and these may have to be saved as well.
Upon receiving an Access-Accept message containing either Filter- Upon receiving an Access-Accept message containing either Filter-
Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27). Id(11) or Ascend-Data-Filter attributes, and or Session Timeout(27).
The SAD SHALL restrict the subscriber session accordingly. The SAD SHALL restrict the subscriber session accordingly.
4.5 Dynamic Operations 4.5
Dynamic Operations
The PrePaid server may want to take advantage of the dynamic The PrePaid server may want to take advantage of the dynamic
capabilities that are supported by the SAD as advertised in the capabilities that are supported by the SAD as advertised in the
Dynamic-Capabilities attribute during the initial Access-Request. Dynamic-Capabilities attribute during the initial Access-Request.
There are two types of actions that the PrePaid server can perform: There are two types of actions that the PrePaid server can perform:
it can request that the session be terminated; or it can request it can request that the session be terminated; or it can request
that attributes associated with the session be modified. More that attributes associated with the session be modified. More
specifically, it can modify previously sent PPAQ(TBD) specifically, it can modify previously sent PPAQ(TBD)
skipping to change at page 30, line 8 skipping to change at page 31, line 42
-MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32) -MUST provide either the NAS-IP-Address(4) or NAS-Identifier(32)
-MUST provide at least one session identifier such as User-Name(1), -MUST provide at least one session identifier such as User-Name(1),
Framed-IP-Address(), the Accounting-Session-Id(44). Framed-IP-Address(), the Accounting-Session-Id(44).
Other attributes could be used to uniquely identify a PrePaid data Other attributes could be used to uniquely identify a PrePaid data
session. session.
For a discussion on Dynamic Operations as they related Mutli-Service For a discussion on Dynamic Operations as they related Mutli-Service
operations see further on. operations see further on.
4.5.1 Unsolicited Session Termination Operation 4.5.1
Unsolicited Session Termination Operation
At anytime during a session the Prepaid Server may send a Disconnect At anytime during a session the Prepaid Server may send a Disconnect
Message to terminate a session. This capability is described in Message to terminate a session. This capability is described in
detail in [RFC3576]. The PrePaid server sends a Disconnect Message detail in [RFC3576]. The PrePaid server sends a Disconnect Message
that MUST contain identifiers that uniquely identify the that MUST contain identifiers that uniquely identify the
subscriberÆs data session and the SAD servicing that session. subscriberÆs data session and the SAD servicing that session.
If the SAD receives a Disconnect-Message, it will respond with If the SAD receives a Disconnect-Message, it will respond with
either a Disconnect-ACK packet if it was able to terminate the either a Disconnect-ACK packet if it was able to terminate the
session or else it will respond with a Disconnect-NAK packet. session or else it will respond with a Disconnect-NAK packet.
Upon successful termination of a session the SAD MUST return any Upon successful termination of a session the SAD MUST return any
unused quota to the Prepaid Server by issuing an Authorize Only unused quota to the Prepaid Server by issuing an Authorize Only
Access-Request containing the PPAQ which contains any unused Quota Access-Request containing the PPAQ which contains any unused Quota
and the Update-Reason set to "Remote Forced Disconnect". and the Update-Reason set to ôRemote Forced Disconnectö.
4.5.2 Unsolicited Change of Authorization Operation 4.5.2
Unsolicited Change of Authorization Operation
At anytime during the prepaid session the Prepaid Client may receive At anytime during the prepaid session the Prepaid Client may receive
a Change of Authorization (CoA) message. A Prepaid Server may send a Change of Authorization (CoA) message. A Prepaid Server may send
a new Quota to either add additional quota or to remove quota a new Quota to either add additional quota or to remove quota
already allocated for the service. already allocated for the service.
If the Change of Authorization contains a PPAQ then that PPAQ will If the Change of Authorization contains a PPAQ then that PPAQ will
override a previously received PPAQ. The PPAQ may contain more override a previously received PPAQ. The PPAQ may contain more
allocated Quota or less allocated quota. The PPS MUST NOT change allocated Quota or less allocated quota. The PPS MUST NOT change
the units used in the PPAQ. the units used in the PPAQ.
If the newly received PPAQ reduces the amount of allocated quota If the newly received PPAQ reduces the amount of allocated quota
beyond what is currently used then the SAD will accept the new PPAQ beyond what is currently used then the SAD will accept the new PPAQ
and act as it normally would when the quota is used up. For and act as it normally would when the quota is used up. For
example, if the threshold is reached then is request a quota update; example, if the threshold is reached then is request a quota update;
if the quota received is less then the currently used level then the if the quota received is less then the currently used level then the
SAD would follow the normal procedures followed when a quota is used SAD would follow the normal procedures followed when a quota is used
up. up.
4.6 Termination Operation 4.6
Termination Operation
The termination phase is initiated when either: the Subscriber logs The termination phase is initiated when either: the Subscriber logs
off; the quotas have been consumed, or when the SAD receives a off; the quotas have been consumed, or when the SAD receives a
Disconnect Message. Disconnect Message.
In the case where the user logged off, or the SAD receives a In the case where the user logged off, or the SAD receives a
Disconnect Message, the SAD will send an Authorize-Only Access- Disconnect Message, the SAD will send an Authorize-Only Access-
Request message with a PPAQ(TBD) and Update-Reason attribute set to Request message with a PPAQ(TBD) and Update-Reason attribute set to
either "Client Service termination" or "Remote Forced disconnect" either ôClient Service terminationö or ôRemote Forced disconnectö
and the currently used quota. and the currently used quota.
In the case where the quota has been reached, if the PPAQ(TBD) In the case where the quota has been reached, if the PPAQ(TBD)
contained Termination-Action field, the SAD will follow the contained Termination-Action field, the SAD will follow the
specified action which would be to immediately terminate the specified action which would be to immediately terminate the
service, to request more quota, or to Redirect/Filter the service. service, to request more quota, or to Redirect/Filter the service.
4.7 Mobile IP Operations 4.7
Mobile IP Operations
In roaming scenarios using Mobile-IP, as the mobile subscriber roams In roaming scenarios using Mobile-IP, as the mobile subscriber roams
between networks, or between different types of networks such as between networks, or between different types of networks such as
between WLAN and CDMA2000 networks, the PrePaid data session should between WLAN and CDMA2000 networks, the PrePaid data session should
be maintained transparently if the HA is acting as the SAD. be maintained transparently if the HA is acting as the SAD.
As the subscriber device associates with the new SAD (AP or PDSN As the subscriber device associates with the new SAD (AP or PDSN
that supports prepaid client capability), the SAD sends a RADIUS that supports prepaid client capability), the SAD sends a RADIUS
Access-Request and the subscriber is re-authenticated and Access-Request and the subscriber is re-authenticated and
reauthorized. The SAD MUST include the PPAC(TBD) attribute in the reauthorized. The SAD MUST include the PPAC(TBD) attribute in the
skipping to change at page 32, line 9 skipping to change at page 33, line 44
ongoing prepaid session will have some impact. In the case the SAD ongoing prepaid session will have some impact. In the case the SAD
shall send an Access-Request. shall send an Access-Request.
The Access-Request message is routed to the home network and MUST The Access-Request message is routed to the home network and MUST
reach the PrePaid System that is serving the PrePaid session. The reach the PrePaid System that is serving the PrePaid session. The
PrePaid system will then correlate the new authorization request PrePaid system will then correlate the new authorization request
with the existing active session and will assign a quota to the new with the existing active session and will assign a quota to the new
request. Any outstanding quota at the old SAD MUST be returned to request. Any outstanding quota at the old SAD MUST be returned to
the PrePaid system. If the Mobile-IP nodes (HA and FA) supports the PrePaid system. If the Mobile-IP nodes (HA and FA) supports
registration revocation (Mobile IPv4 only). Specifically, the quota registration revocation (Mobile IPv4 only). Specifically, the quota
SHOULD be returned when the SAD sends the Authorize Only Access- SHOULD be returned when the SAD sends the Authorize Only Access-
Request with PPAQ(TBD) Update-Reason set to either "Remote Forced Request with PPAQ(TBD) Update-Reason set to either ôRemote Forced
disconnect" or "Client Service termination". In order to trigger disconnectö or ôClient Service terminationö. In order to trigger
the sending of this last Authorize Only Access-Request, the PrePaid the sending of this last Authorize Only Access-Request, the PrePaid
system may issue a Disconnect Message [3576] to the SAD. system may issue a Disconnect Message [3576] to the SAD.
If the subscriber has roamed to an SAD that does not have any If the subscriber has roamed to an SAD that does not have any
PrePaid Capabilities, PrePaid data service may still be possible by PrePaid Capabilities, PrePaid data service may still be possible by
requesting the Home Agent (providing it has PrePaid Capabilities) to requesting the Home Agent (providing it has PrePaid Capabilities) to
assume responsibilities for metering the service. The procedure for assume responsibilities for metering the service. The procedure for
this scenario will be given in the next release of this draft. this scenario will be given in the next release of this draft.
4.8 Operation consideration for Multi-Services 4.8
Operation consideration for Multi-Services
This section describes the operation for supporting Prepaid for This section describes the operation for supporting Prepaid for
multi-services on the same SAD. The operations for multi-services multi-services on the same SAD. The operations for multi-services
are very similar to operations for single service. Message flows are very similar to operations for single service. Message flows
illustrating the various interactions are presented at the end of illustrating the various interactions are presented at the end of
this document. this document.
A SAD that supports prepaid operations for multi-services SHOULD set A SAD that supports prepaid operations for multi-services SHOULD set
the "Multi-Services Supported" bit in the PPAC. the ôMulti-Services Supportedö bit in the PPAC.
When working with multi-services, we need to differentiate between When working with multi-services, we need to differentiate between
the services. A Service-Id attribute is used in the PPAQ(TBD) to the services. A Service-Id attribute is used in the PPAQ(TBD) to
uniquely differentiate between the services. The exact definition uniquely differentiate between the services. The exact definition
of the Service-Id attribute is out of scope for this document. of the Service-Id attribute is out of scope for this document.
A PPAQ that contains a Service-Id is associated with that Service. A PPAQ that contains a Service-Id is associated with that Service.
A PPAQ that contains a Rating-Group-Id is associated with that 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 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. A PPAQ that contains neither a Rating-Group-Id or a
Service-Id applies to the "Access Service". Service-Id applies to the ôAccess Serviceö.
4.8.1 Initial Quota Request 4.8.1
Initial Quota Request
When operations with multi-services is desired, the SAD will request When operations with multi-services is desired, the SAD will request
the initial quota for the Service by sending a PPAQ containing the the initial quota for the Service by sending a PPAQ containing the
Service-Id for that Service in an Authorize-Only Access-Request Service-Id for that Service in an Authorize-Only Access-Request
packet. Similarly, if the SAD supports Rating-Groups then it may packet. Similarly, if the SAD supports Rating-Groups then it may
request a prepaid quota for the Rating-Group by sending a PPAQ request a prepaid quota for the Rating-Group by sending a PPAQ
containing the Rating-Group-Id. In both cases the Update-Reason containing the Rating-Group-Id. In both cases the Update-Reason
will be set to "Initial-Request". will be set to ôInitial-Requestö.
The Authorize-Only Access-Request packet may contain more than one The Authorize-Only Access-Request packet may contain more than one
PPAQ. The Authorize-Only Access-Request MUST include one or more PPAQ. The Authorize-Only Access-Request MUST include one or more
attributes that serve to identify the session so that it can be attributes that serve to identify the session so that it can be
linked to the original authentication. Which Session Identifier(s) linked to the original authentication. Which Session Identifier(s)
is included is up to specific deployments. The Authorize-Only is included is up to specific deployments. The Authorize-Only
message must contain the Message-Authenticator(80) attribute for message must contain the Message-Authenticator(80) attribute for
integrity protection of the Authorize-Only Access-Request message. integrity protection of the Authorize-Only Access-Request message.
Upon receiving an Authorize-Only Access-Accept message containing Upon receiving an Authorize-Only Access-Accept message containing
one or more PPAQs the Prepaid System will allocate resources to each one or more PPAQs the Prepaid System will allocate resources to each
PPAQ. The resources, can be in units of time, volume as before. PPAQ. The resources, can be in units of time, volume as before.
Each PPAQ will be assigned a unique QID that MUST appear in a Each PPAQ will be assigned a unique QID that MUST appear in a
subsequent PPAQ update for that service or rating-group. As well, subsequent PPAQ update for that service or rating-group. As well,
the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if the PPAQ MUST contain the Service-ID; or Group-ID; or neither, if
the PPAQ applies to the "Access Service". the PPAQ applies to the ôAccess Serviceö.
4.8.2 Quota Update 4.8.2
Quota Update
Once the services start to utilize their allotted quota they will Once the services start to utilize their allotted quota they will
eventually need to replenish their quotas (either the threshold is eventually need to replenish their quotas (either the threshold is
reached or no more quota remains). To replenish the quota the reached or no more quota remains). To replenish the quota the
Prepaid Client will send an Authorize-Only Access-Request message Prepaid Client will send an Authorize-Only Access-Request message
containing one or more PPAQs. Each PPAQ MUST contain the containing one or more PPAQs. Each PPAQ MUST contain the
appropriate QID, Service-ID or Group-ID (or neither the Service-ID appropriate QID, Service-ID or Group-ID (or neither the Service-ID
or Group-Id if the quota replenishment is for the "Access Service"). or Group-Id if the quota replenishment is for the ôAccess Serviceö).
The Update-Reason filed will indicate either "Threshold reached"(3), The Update-Reason filed will indicate either ôThreshold reachedö(3),
or "Quota reached"(4). The Authorize-Only message must contain or ôQuota reachedö(4). The Authorize-Only message must contain
identifiers to identify the session. identifiers to identify the session.
Upon receiving an Authorize-Only Access-Request packet with one or Upon receiving an Authorize-Only Access-Request packet with one or
more PPAQs the Prepaid Server will respond with a new PPAQ for that more PPAQs the Prepaid Server will respond with a new PPAQ for that
service. The PPAQ will contain a new QID, the Service-Id or Rating- service. The PPAQ will contain a new QID, the Service-Id or Rating-
Group-Id, a new Quota. If the Prepaid Server does not want to grant Group-Id, a new Quota. If the Prepaid Server does not want to grant
additional quota to the Service it MUST include the Termination- additional quota to the Service it MUST include the Termination-
Action subfield in the PPAQ that will instruct the SAD what to do Action subfield in the PPAQ that will instruct the SAD what to do
with the service. with the service.
4.8.3 Termination 4.8.3
Termination
When an allotted quota for the service is used up the SAD shall act When an allotted quota for the service is used up the SAD shall act
in accordance to the Termination-Action field set in the Quota. If in accordance to the Termination-Action field set in the Quota. If
the Termination-Action field is absent then the Service MUST be the Termination-Action field is absent then the Service MUST be
terminated. terminated.
If the Service is to be terminated then the SAD shall send a PPAQ If the Service is to be terminated then the SAD shall send a PPAQ
with the appropriate QID, the Service-Id, the used quota, and with the appropriate QID, the Service-Id, the used quota, and
Update-Reason set to "Client Service Termination". Update-Reason set to ôClient Service Terminationö.
If the "Access Service" has terminated, then all other services must If the ôAccess Serviceö has terminated, then all other services must
be terminated as well. In this case the SAD must report on all be terminated as well. In this case the SAD must report on all
issued quotas for the various services. The Update-Reason field issued quotas for the various services. The Update-Reason field
should be set to "Access Service Terminated". should be set to ôAccess Service Terminatedö.
Note when sending more then on PPAQ it may be required to send Note when sending more then on PPAQ it may be required to send
multiple Authorize Only Access-Requests. multiple Authorize Only Access-Requests.
4.8.4 Dynamic Operations 4.8.4
Dynamic Operations
Dynamic operations for multi-services are similar to dynamic Dynamic operations for multi-services are similar to dynamic
operations described for single service operations. The prepaid operations described for single service operations. The prepaid
system may send a COA message containing a PPAQ for an existing system may send a COA message containing a PPAQ for an existing
service instance. The SAD will match the PPAQ to the service using service instance. The SAD will match the PPAQ to the service using
the Service-ID attribute. The new quota could be higher then the the Service-ID attribute. The new quota could be higher then the
last allocated value or it could be lower. The SAD must react to last allocated value or it could be lower. The SAD must react to
the new quota accordingly. the new quota accordingly.
A Disconnect message may not be send for a specific service. A A Disconnect message may not be send for a specific service. A
disconnect message terminates the "Access Service". As such the SAD disconnect message terminates the ôAccess Serviceö. As such the SAD
must report back all unused quotas by sending an Authorize Only must report back all unused quotas by sending an Authorize Only
Access Request message containing a PPAQ for each active service. Access Request message containing a PPAQ for each active service.
The Update-Reason shall indicate that the reason for the update The Update-Reason shall indicate that the reason for the update
reason. reason.
4.8.5 Support for Resource Pools 4.8.5
Support for Resource Pools
If the Prepaid Client supports pools as indicated by setting the If the Prepaid Client supports pools as indicated by setting the
"Pools supported" bit in the PPAC(TBD) then the Prepaid Server may ôPools supportedö bit in the PPAC(TBD) then the Prepaid Server may
associate a Quota with a Pool by including the Pool-Id and the Pool- associate a Quota with a Pool by including the Pool-Id and the Pool-
Multiplier in the PPAQ(TBD). Multiplier in the PPAQ(TBD).
When Resource Pools are used, the PPAQ must not use the threshold When Resource Pools are used, the PPAQ must not use the threshold
field. field.
4.8.6 One-Time-Charging 4.8.6
One-Time-Charging
To initiate a One-Time charge the PPC include the PPAQ attribute in To initiate a One-Time charge the PPC include the PPAQ attribute in
an Access-Request packet. The Access Request packet MUST include an Access-Request packet. The Access Request packet MUST include
the Message-Authenticator(80) and Event-Timestamp(55) attributes. the Message-Authenticator(80) and Event-Timestamp(55) attributes.
The Service Id field of the PPAQ identifies the Service that is be The Service Id field of the PPAQ identifies the Service that is be
charged for. The amount of to be charged is specified using the charged for. The amount of to be charged is specified using the
Resource Quota and Resource Quota overflow subtypes. If the value Resource Quota and Resource Quota overflow subtypes. If the value
specified is negative then the resources will be credited to the specified is negative then the resources will be credited to the
userÆs account. userÆs account.
skipping to change at page 36, line 8 skipping to change at page 37, line 40
should include in the Access-Accept a Session-Timeout set to 0. The should include in the Access-Accept a Session-Timeout set to 0. The
Upon receiving an Access-Accept response the SAD shall generate an Upon receiving an Access-Accept response the SAD shall generate an
Accounting Stop message. Accounting Stop message.
A PPAQ used for One-Time charging may appear in an Authorize-Only A PPAQ used for One-Time charging may appear in an Authorize-Only
Access Request. This is the case where a session already exists for Access Request. This is the case where a session already exists for
the user. The PPS shall respond back with an Access-Accept to the user. The PPS shall respond back with an Access-Accept to
indicate that the userÆs account has been debited or an Access- indicate that the userÆs account has been debited or an Access-
Reject indicating that the account could not be debited. Reject indicating that the account could not be debited.
4.8.7 Error Handling 4.8.7
Error Handling
If the Prepaid Server receives a PPAQ with an invalid QID it MUST If the Prepaid Server receives a PPAQ with an invalid QID it MUST
ignore that PPAQ. ignore that PPAQ.
If the Prepaid Server receives a PPAQ containing a Service-Id, or a If the Prepaid Server receives a PPAQ containing a Service-Id, or a
Rating-Group-Id that it does not recognize, then it MUST ignore that Rating-Group-Id that it does not recognize, then it MUST ignore that
PPAQ. PPAQ.
If the Prepaid Client receives a PPAQ containing a Service-Id, or a If the Prepaid Client receives a PPAQ containing a Service-Id, or a
Rating-Group-Id that it does not recognize, then it must ignore that Rating-Group-Id that it does not recognize, then it must ignore that
PPAQ. PPAQ.
If the Prepaid Client receives a PPAQ that contains a Pool-Id If the Prepaid Client receives a PPAQ that contains a Pool-Id
without a Pool-Multiplier; or a Pool-Multiplier without a Pool-Id it without a Pool-Multiplier; or a Pool-Multiplier without a Pool-Id it
must ignore that PPAQ. must ignore that PPAQ.
4.9 Accounting Considerations 4.9
Accounting Considerations
Accounting messages are not required to deliver PrePaid Data Accounting messages are not required to deliver PrePaid Data
Service. Accounting message will typically be generated for PrePaid Service. Accounting message will typically be generated for PrePaid
Data Service. This because accounting message are used for auditing Data Service. This because accounting message are used for auditing
purposes as well as for bill generation. purposes as well as for bill generation.
Accounting messages associated with PrePaid Data Sessions should Accounting messages associated with PrePaid Data Sessions should
include the PPAQ(TBD) attribute. include the PPAQ(TBD) attribute.
4.10 SAD Operation 4.10
SAD Operation
To be completed To be completed
4.11 Interoperability with Diameter Credit Control Application 4.11
Interoperability with Diameter Credit Control Application
RADIUS PrePaid solutions need to interoperate with Diameter RADIUS PrePaid solutions need to interoperate with Diameter
protocol. Two possibilities exist: The AAA infrastructure is protocol. Two possibilities exist: The AAA infrastructure is
Diameter based and the SAD are RADIUS based; or the SAD is Diameter Diameter based and the SAD are RADIUS based; or the SAD is Diameter
based and the AAA infrastructure is RADIUS based. based and the AAA infrastructure is RADIUS based.
The Diameter Credit Control Application [DIAMETERCC] describes how The Diameter Credit Control Application [DIAMETERCC] describes how
to implement a PrePaid using an all Diameter based infrastructure. to implement a PrePaid using an all Diameter based infrastructure.
<This section to be completed.> <This section to be completed.>
5. Attributes 5.
Attributes
This draft is using the RADIUS [RFC2865] namespace. This draft is using the RADIUS [RFC2865] namespace.
5.1 PPAC Attribute 5.1
PPAC Attribute
The PrepaidAccountingCapability (PPAC) attribute is sent in the The PrepaidAccountingCapability (PPAC) attribute is sent in the
Access-Request message by a Prepaid Capable NAS and is used to Access-Request message by a Prepaid Capable NAS and is used to
describe the PrePaid capabilities of the NAS. The PPAC is available describe the PrePaid capabilities of the NAS. The PPAC is available
to be sent in an Access-Accept message by the Prepaid server to to be sent in an Access-Accept message by the Prepaid server to
indicate the type of prepaid metering that is to be applied to this indicate the type of prepaid metering that is to be applied to this
session. session.
0 1 2 3 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 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
skipping to change at page 38, line 11 skipping to change at page 39, line 44
The optional AvailableInClient Sub-Type, generated by the PrePaid The optional AvailableInClient Sub-Type, generated by the PrePaid
client, indicates the PrePaid Accounting capabilities of the NAS and client, indicates the PrePaid Accounting capabilities of the NAS and
shall be bitmap encoded. The possible values are: shall be bitmap encoded. The possible values are:
0x00000001 Volume metering supported. 0x00000001 Volume metering supported.
0x00000002 Duration metering supported. 0x00000002 Duration metering supported.
0x00000004 Resource metering supported. 0x00000004 Resource metering supported.
0x00000008 Pools supported 0x00000008 Pools supported
0x00000010 Rating groups supported 0x00000010 Rating groups supported
0x00000020 Multi-Services supported. 0x00000020 Multi-Services supported.
0x00000040 Tariff Switch supported.
Others Reserved Others Reserved
5.2 Session Termination Capability 5.2
Session Termination Capability
The value shall be bitmap encoded rather than a raw integer. This The value shall be bitmap encoded rather than a raw integer. This
attribute shall be included RADIUS Access-Request message to the attribute shall be included RADIUS Access-Request message to the
RADIUS server and indicates whether or not the NAS supports Dynamic RADIUS server and indicates whether or not the NAS supports Dynamic
Authorization. Authorization.
0 1 2 3 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 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 | String | | TYPE | LENGTH | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : value of Session Termination Capability Type : value of Session Termination Capability
Length: = 4 Length: = 4
String encoded as follows: String encoded as follows:
0x00000001 Dynamic Authorization Extensions (rfc3576) is 0x00000001 Dynamic Authorization Extensions (rfc3576) is
supported. supported.
5.3 PPAQ Attribute 5.3
PPAQ Attribute
One or more PPAQ(TBD) attributes are available to be sent in an One or more PPAQ(TBD) attributes are available to be sent in an
Access Request, Authorize Only Access-Request and Access-Accept Access Request, Authorize Only Access-Request and Access-Accept
messages. In an Access Request message, it is used to One-Time messages. In an Access Request message, it is used to One-Time
charging transactions; in Authorize Only Access-Request messages it charging transactions; in Authorize Only Access-Request messages it
is used to for One-Time charging, report usage and request further is used to for One-Time charging, report usage and request further
quota or request prepaid quota for a new service instance; in an quota or request prepaid quota for a new service instance; in an
Access-Accept message it is used to allocate the quotas (initial Access-Accept message it is used to allocate the quotas (initial
quota and subsequent quotas). quota and subsequent quotas).
When concurrent service are supported a PPAQ is associated with a When concurrent service are supported a PPAQ is associated with a
specific service as indicated by the presence of Service-Id; or a specific service as indicated by the presence of Service-Id; or a
Rating Group, as indicated by the presence of a Rating-Group-Id; or Rating Group, as indicated by the presence of a Rating-Group-Id; or
the "Access Service" as indicated by the absence of a Service-Id or the ôAccess Serviceö as indicated by the absence of a Service-Id or
a Rating-Group-Id. a Rating-Group-Id.
The attribute consists of a number of subtypes. Subtypes not used The attribute consists of a number of subtypes. Subtypes not used
are omitted in the message. are omitted in the message.
0 1 2 3 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 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 | SUB-TYPE 1 | LENGTH | | TYPE | LENGTH | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIdentifier (QID) | | QuotaIdentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Volume Quota | | SUB-TYPE 2 | LENGTH | Volume Quota |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Volume Quota | SUB-TYPE 3 | LENGTH | | Volume Quota | SUB-TYPE 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 42, line 18 skipping to change at page 44, line 8
reasons 4, 5, 6, 7 and 8 indicate that the associated resources reasons 4, 5, 6, 7 and 8 indicate that the associated resources
are released at the client side, and therefore the PPS shall not are released at the client side, and therefore the PPS shall not
allocate a new quota in the RADIUS Access_Accept message. allocate a new quota in the RADIUS Access_Accept message.
1. Pre-initialization 1. Pre-initialization
2. Initial Request 2. Initial Request
3. Threshold Reached 3. Threshold Reached
4. Quota Reached 4. Quota Reached
5. Remote Forced Disconnect 5. Remote Forced Disconnect
6. Client Service Termination 6. Client Service Termination
7. "Access Service" Terminated 7. ôAccess Serviceö Terminated
8. Service not established 8. Service not established
9. One-Time Charging 9. One-Time Charging
Sub-Type (=9) : Sub-Type for PrePaidServer attribute Sub-Type (=9) : Sub-Type for PrePaidServer attribute
Length : Length of PrePaidServer Length : Length of PrePaidServer
(IPv4 = 6 octets, IPv6= 18 octets (IPv4 = 6 octets, IPv6= 18 octets
PrePaidServer: PrePaidServer:
The optional, multi-value PrePaidServer indicates the address of The optional, multi-value PrePaidServer indicates the address of
skipping to change at page 44, line 11 skipping to change at page 46, line 4
In RADIUS Access-Accept message (PPS to SAD direction), it In RADIUS Access-Accept message (PPS to SAD direction), it
indicates the Resources allocated for the session by the PrePaid indicates the Resources allocated for the session by the PrePaid
server. In RADIUS Authorize Only Access-Request message (SAD to server. In RADIUS Authorize Only Access-Request message (SAD to
PPS direction), it indicates the total used resource for both PPS direction), it indicates the total used resource for both
forward and reverse traffic applicable to PrePaid accounting. In forward and reverse traffic applicable to PrePaid accounting. In
one-time charging scenarios, the subtype represents the number of one-time charging scenarios, the subtype represents the number of
units to charge the user or to credit the user (negative values). units to charge the user or to credit the user (negative values).
Sub-Type (=14) : Sub-Type for Resource Quota Overflow Sub-Type (=14) : Sub-Type for Resource Quota Overflow
Length : 6 Length : 6
Sub-Type (=15) : Sub-Type for ResourceThreshold Sub-Type (=15) : Sub-Type for ResourceThreshold
Length : 6 Length : 6
NOTES: NOTES:
Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear in Either Volume-Quota, Time-Quota, or Resource-Quota MUST appear in
the attribute. the attribute.
Volume Threshold may only appear if Volume Quota appears Volume Threshold may only appear if Volume Quota appears
A PPAQ MUST NOT CONTAIN both a Service-Id and a Rating-Group-Id. A PPAQ MUST NOT CONTAIN both a Service-Id and a Rating-Group-Id.
A PPAQ that does not contain a Service-ID or a Rating-Group-Id A PPAQ that does not contain a Service-ID or a Rating-Group-Id
applies to the "Access Service". applies to the ôAccess Serviceö.
When the PPAQ contains a Pool-Id it MUST also contain the Pool- When the PPAQ contains a Pool-Id it MUST also contain the Pool-
Multiplier. Multiplier.
5.4 Table of Attributes 5.4
Prepaid Tariff Switching (PTS)
This specification defines the PTS attribute to allow for
changeovers from one service charge to another during service
execution.
Support for tariff switching is OPTIONAL for both PPC and PPS. PPCs
use the flag "Tariff Switching supported" of the AvailableInClient
subtype of the PPAC attribute to indicate support for tariff
switching; PPSs employ the PTS attribute to announce their support
for tariff switching. Details of this issue are specified later on,
when the format of the PTS attribute has been defined.
If a RADIUS message contains a PTS attribute, it MUST also contain
at least one PPAQ attribute. This requirement is related to the
identification of the service to which tariff switching applies. If
a RADIUS Access-Request message contains a PTS attribute or if it
contains a "Tariff Switching supported" flag, it MUST also contain
an Event-Timestamp RADIUS attribute (see [RFC2869]). This
requirement is related to the TariffSwitchInterval subtype of the
PTS attribute (see below).
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 | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QuotaIDentifier (QID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | VolumeUsedAfter- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitch (VUATS) | SUB-TYPE 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VUATSOverflow (VUATSO) | SUB-TYPE 4 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitchInterval (TSI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 5 | LENGTH | TimeIntervalAfter- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TariffSwitchUpdate (TITSU) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of PTS
Length: variable, greater than 8
Subtype (=1): QuotaIDentifier (QID)
Length : Length of QuotaIDentifier Subtype (= 6 octets)
The QID subtype MUST be present in each PTS attribute. In an
online RADIUS Access-Request message sent from the PPC to the
PPS, its value MUST be a quota identifier received previously
from the PPS and MUST be the same as a quota identifier of one of
the PPAQ attributes included the same RADIUS message.
A PPAQ attribute that is transported along with a PTS attribute
and has the same quota identifier value as the PTS attribute in
its own QID subfield shall be referred to as "accompanying PPAQ
attribute". If a PPS receives an Access-Request message from a
PPC, it associates a unique quota identifier to this service
access request. Thus, a quota identifier also identifies a
particular service.
Subtype (=2): VolumeUsedAfterTariffSwitch (VUATS)
Length : Length of VolumeUsedAfterTariffSwitch Subtype
(= 6 octets)
The VolumeUsedAfterTariffSwitch subtype SHALL be used in online
RADIUS Access-Request messages (PPC to PPS direction). It
indicates the volume (in octets) used during a session after the
last tariff switch for the service specified via the QID subfield
and the accompanying PPAQ attribute (see the remarks under
"Subtype 1: QID").
Subtype (=3): VUATSOverflow (VUATSO)
Length : Length of VUATSOverflow Subtype (= 4 octets)
If an online RADIUS Access-Request message contains a VUATS
subfield and if the VolumeUsedAfterTariffSwitch has wrapped
around 2^32 over the course of provisioning the service
identified via the QID subfield, then the VUATSO subfield MUST be
present in the PTS attribute. In this case, it indicates how
many times the VolumeUsedAfterTariffSwitch has wrapped around
2^32. In all other cases, the VUATSO subfield MUST NOT be
present in the PTS attribute.
Subtype (=4): TariffSwitchInterval (TSI)
Length : Length of TSI Subtype (= 6 octets)
The TSI subtype MUST be present in each PTS attribute that is
part of a RADIUS Access-Accept message (PPS to PPC direction).
It indicates the interval (in seconds) between the value of
Event-Timestamp RADIUS attribute (see [RFC2869]) of the
corresponding RADIUS Access-Request message and the next tariff
switch condition.
Subtype (=5): TimeIntervalafterTariffSwitchUpdate (TITSU)
Length : Length of TITSU Subtype
(= 6 octets)
The PPS MUST include the TITSU subtype if there is another tarrif
switch period after this period. TITSU represents the length of
the tariff switch period in seconds. If this attribute is
omitted or is zero, the tariff period that commences in TSI
seconds will last indefinitely or until a new PTS is received
with new information. If TITSU is specified, the prepaid client
must send a quota update before the end of the tariff switch
period as specified by TITSU.
If a RADIUS message contains a PTS attribute, it MUST also contain
at least one PPAQ attribute. The PTS will be associated to the PPAQ
by the QID. If multiple services are supported and if the PPAQ is
associated with a service as indicated by the Service-Id sub-
atrribute of the PPAQ, then the PTS will specify the tarrif switch
for that service. If the PPAQ does not have a Service-Id, then the
PTS will be the tarrif switch of the Access-Service.
If a PPC supports tariff switching then it MUST set the 0x00000040
(Tariff switching supported) flag of the AvailableInClient subtype
of the PPAC attribute that is contained in the Access-Request packet
starting the prepaid session.
5.5
Table of Attributes
TO BE COMPLETED. TO BE COMPLETED.
Request Accept Reject Challenge # Attribute Request Accept Reject Challenge # Attribute
Authorize_Only Request Accept Reject Authorize_Only Request Accept Reject
6. Security Considerations 6.
Security Considerations
The protocol exchanges described are susceptible to the same The protocol exchanges described are susceptible to the same
vulnerabilities as RADIUS and it is recommended that IPsec be vulnerabilities as RADIUS and it is recommended that IPsec be
employed to afford better security. employed to afford better security.
If IPsec is not available the protocol in this draft improves the If IPsec is not available the protocol in this draft improves the
security of RADIUS. The various security enhancements are explained security of RADIUS. The various security enhancements are explained
in the following sections. in the following sections.
6.1 Authentication and Authorization 6.1
Authentication and Authorization
RADIUS is susceptible to replay attacks during the Authentication RADIUS is susceptible to replay attacks during the Authentication
and Authorization procedures. A successful replay of the initial and Authorization procedures. A successful replay of the initial
Access-Request could result in an allocation of an initial quota. Access-Request could result in an allocation of an initial quota.
To thwart such an attack... To thwart such an attack...
6.2 Replenishing Procedure 6.2
Replenishing Procedure
A successful replay attacks of the Authorize Only Access-Request A successful replay attacks of the Authorize Only Access-Request
could deplete the subscribers prepaid account. could deplete the subscribers prepaid account.
To be completed. To be completed.
7. IANA Considerations 7.
IANA Considerations
This document requires the assignment of new Radius attributes type This document requires the assignment of new Radius attributes type
numbers for the following attributes: numbers for the following attributes:
1) Prepaid-Accounting-Capability (PPAC) 1) Prepaid-Accounting-Capability (PPAC)
with subtype: with subtype:
AvailableInClient AvailableInClient
2) Prepaid-Accounting-Operation (PPAQ) 2) Prepaid-Accounting-Operation (PPAQ)
with subtypes: with subtypes:
skipping to change at page 46, line 9 skipping to change at page 50, line 47
UpdateReason (UR) UpdateReason (UR)
PrePaidServer (PPS) PrePaidServer (PPS)
ServiceID (SID) ServiceID (SID)
RatingGroupId (RGID) RatingGroupId (RGID)
TerminationAction (TA) TerminationAction (TA)
PoolID (PID) PoolID (PID)
PoolMultiplier (PM) PoolMultiplier (PM)
Cost (COST) Cost (COST)
TariffChangeTime (TCT) TariffChangeTime (TCT)
3) Session-Termination-Capability (STC) 3) Prepaid-Tariff-Switch (PTS)
4) Session-Termination-Capability (STC)
4) International-Mobile-Subscriber-Identity (IMSI) 5) International-Mobile-Subscriber-Identity (IMSI)
8. Normative References 8.
Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", RFC 2026, October 1996. Revision 3", RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens,
"Remote Authentication Dial In User Server "Remote Authentication Dial In User Server
(RADIUS)", RFC 2865, June 2000. (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June
skipping to change at page 46, line 40 skipping to change at page 51, line 36
Holdrege, M., Goyret, I., "RADIUS Attributes for Holdrege, M., Goyret, I., "RADIUS Attributes for
Tunnel Protocol Support" , RFC 2868, June 2000. Tunnel Protocol Support" , RFC 2868, June 2000.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D.,
Aboba, B., "Dynamic Authorization Extensions to Aboba, B., "Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service Remote Authentication Dial-In User Service
(RADIUS)", RFC 3576, February 2003. (RADIUS)", RFC 3576, February 2003.
[RFC3748] Aboba, B., et al., "Extensible Authentication [RFC3748] Aboba, B., et al., "Extensible Authentication
Protocol", RFC 3748, June 2004. Protocol", RFC 3748, June 2004.
9. Informative References 9.
Informative References
[DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control [DIAMETERCC] Hakkala, H., et al., "Diamter Credit-Control
Application", Internet Draft, AAA WG, April 2004, Application", Internet Draft, AAA WG, April 2004,
Work in Progress. Work in Progress.
[REDIRECT] "RADIUS Redirection", Internet Draft, Work in [REDIRECT] "RADIUS Redirection", Internet Draft, Work in
progress. progress.
10. Call Flows 10.
Call Flows
This section includes call flows illustrating various scenarios This section includes call flows illustrating various scenarios
enabled by this specification. enabled by this specification.
The following are used in the call flows: The following are used in the call flows:
RADIUS packets: RADIUS packets:
AR Access Request AR Access Request
ARA Access Accept ARA Access Accept
AC Accounting Requests AC Accounting Requests
skipping to change at page 48, line 5 skipping to change at page 53, line 5
RADIUS RADIUS
MSID Acct-Multi-Session-Id as define MSID Acct-Multi-Session-Id as define
by RADIUS by RADIUS
PPAQ fields: PPAQ fields:
SRVID Service-Id SRVID Service-Id
Reason Update-Reason Reason Update-Reason
QID Quota-Id QID Quota-Id
10.1 Simple Concurrent Services 10.1
Simple Concurrent Services
In this scenario the Prepaid Client authenticates and authorizes the In this scenario the Prepaid Client authenticates and authorizes the
user. The Prepaid Server responds back with Prepaid Quota for the user. The Prepaid Server responds back with Prepaid Quota for the
"Access Service" instance. The NAS then request quota for Service- ôAccess Serviceö instance. The NAS then request quota for Service-
A. A.
Accounting is turned on. Accounting is turned on.
NAS/ RADIUS/ NAS/ RADIUS/
PPC PPS PPC PPS
=== === === ===
| | | |
| AR{SID,PPAC} | | AR{SID,PPAC} |
A |-------------------------------------------------->| A |-------------------------------------------------->|
skipping to change at page 49, line 19 skipping to change at page 54, line 17
A This is the initial Access-Request that indicates the Prepaid A This is the initial Access-Request that indicates the Prepaid
Capabilities of the NAS. In this scenario it will indicate Capabilities of the NAS. In this scenario it will indicate
that Concurrent Session are supported. Access-Request also that Concurrent Session are supported. Access-Request also
includes SID (Session Id) which is the Session Identifier includes SID (Session Id) which is the Session Identifier
assigned by this NAS to session. Session Identifier is out of assigned by this NAS to session. Session Identifier is out of
scope in this document. It can be a single attribute such as scope in this document. It can be a single attribute such as
3GPP2 Correlation ID or it could be a set of attributes that 3GPP2 Correlation ID or it could be a set of attributes that
define a session. define a session.
B RADIUS authenticates the user and determines that the user is B RADIUS authenticates the user and determines that the user is
prepaid. RADIUS responds with a PPAQ for the "Access Service" prepaid. RADIUS responds with a PPAQ for the ôAccess Serviceö
(PPAQ does not contain a Service-ID or Rating-Group-ID). The (PPAQ does not contain a Service-ID or Rating-Group-ID). The
PPAQ has a QID=1 assigned by the Prepaid System and Quota of PPAQ has a QID=1 assigned by the Prepaid System and Quota of
Q=100. The quota could be time or volume and may or may not Q=100. The quota could be time or volume and may or may not
have a threshold associated with it. have a threshold associated with it.
C NAS starts the Access Service and generates an Accounting- C NAS starts the Access Service and generates an Accounting-
Request (Start) message as normal. It will include the Acct- Request (Start) message as normal. It will include the Acct-
Session-Id and may include the Acct-Multi-Session-Id. Session-Id and may include the Acct-Multi-Session-Id.
D The NAS wants to start a new Service, call it Service-A. It D The NAS wants to start a new Service, call it Service-A. It
sends an Authorize-Only access request to RADIUS. The SID sends an Authorize-Only access request to RADIUS. The SID
links this Authorize-Only access request to the initial links this Authorize-Only access request to the initial
skipping to change at page 50, line 10 skipping to change at page 55, line 8
completely used). An Authorize-Only message is sent completely used). An Authorize-Only message is sent
containing a PPAQ with QID = 200 which corresponds to the containing a PPAQ with QID = 200 which corresponds to the
prior QID received for this service. Note QID is sufficient prior QID received for this service. Note QID is sufficient
for the PPS server to link this request to the previous for the PPS server to link this request to the previous
request and hence to the original authentication steps. request and hence to the original authentication steps.
Therefore SID is not really required. The PPAQ will report the Therefore SID is not really required. The PPAQ will report the
used part of the quota (50 units). used part of the quota (50 units).
H RADIUS deducts the used quota from the users accounts and H RADIUS deducts the used quota from the users accounts and
reserves 50 more additional units for a total quota of 100 reserves 50 more additional units for a total quota of 100
(Q=100) for Service-A. It sends back a PPAQ with QID=300. (Q=100) for Service-A. It sends back a PPAQ with QID=300.
I NAS needs to refresh both the "Access Service" and Service-A. I NAS needs to refresh both the ôAccess Serviceö and Service-A.
It sends an Authorize Only message contain two PPAQs, one for It sends an Authorize Only message contain two PPAQs, one for
the Main Service with QID=1 and one for Service-A with the Main Service with QID=1 and one for Service-A with
QID=300. Each PPAQ reports the used resources so far and the QID=300. Each PPAQ reports the used resources so far and the
reason why the update is being sent. reason why the update is being sent.
J RADIUS responds back with two PPAQs. The PPAQ without the J RADIUS responds back with two PPAQs. The PPAQ without the
Service-Id grants an additional 100 units for a total of 200 Service-Id grants an additional 100 units for a total of 200
units to the "Access Service" QID=3; the other PPAQ, units to the ôAccess Serviceö û QID=3; the other PPAQ,
containing SRVID=SA grants an additional 50 units for a total containing SRVID=SA grants an additional 50 units for a total
quota to service-a of 150 units QID=303. quota to service-a of 150 units û QID=303.
This step illustrates why SRVID needs to be specified in the This step illustrates why SRVID needs to be specified in the
PPAQ. If it were not, then the NAS would not be able to PPAQ. If it were not, then the NAS would not be able to
differentiate between the PPAQs. QIDs are not sufficient to differentiate between the PPAQs. QIDs are not sufficient to
correlate the PPAQ to a service since they are changed (and correlate the PPAQ to a service since they are changed (and
not necessarily sequentially) by the PPS at every transaction. not necessarily sequentially) by the PPS at every transaction.
In this scenario, notice how each PPAQ attribute represents a In this scenario, notice how each PPAQ attribute represents a
sequential conversation about a service between the Prepaid Client sequential conversation about a service between the Prepaid Client
and the Prepaid Server. The links between the messages are the QIDs and the Prepaid Server. The links between the messages are the QIDs
and the Service-Ids. and the Service-Ids.
As well, notice how a SID is needed to tie the Authorize-Only As well, notice how a SID is needed to tie the Authorize-Only
messages to the Authentication steps. This SID is only really messages to the Authentication steps. This SID is only really
needed the first time a PPAQ is sent since the PPAQ does not have needed the first time a PPAQ is sent û since the PPAQ does not have
a QID. a QID.
Accounting messages have an Accounting-Session-ID. But that is not Accounting messages have an Accounting-Session-ID. But that is not
enough to allow the back end system to associate that accounting enough to allow the back end system to associate that accounting
message with a particular Service. We therefore need the PPAQ in message with a particular Service. We therefore need the PPAQ in
the accounting message. the accounting message.
10.2 One-time Charging 10.2
One-time Charging
In this One-time charging scenario, the Prepaid Client (PPC) In this One-time charging scenario, the Prepaid Client (PPC)
authenticates and authorizes the user and requests charging for a authenticates and authorizes the user and requests charging for a
service event requested by the user. The PPC already knows the service event requested by the user. The PPC already knows the
price to charge for the service event identified by SRVID=SA. price to charge for the service event identified by SRVID=SA.
Contributor Contributor
We would like to thank Hannes Tschofenig for his contributions to We would like to thank Hannes Tschofenig for his contributions to
this draft. this draft.
Acknowledgments Acknowledgments
The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala The authors would like to thank Mark Grayson (Cisco), Nagi Jonnala
and Tseno Tsenov for their contribution to this draft. and Tseno Tsenov for their contribution to this draft.
Author's Addresses Author's Addresses
Avi Lior Parviz Yegani, Ph.D. Avi Lior Parviz Yegani, Ph.D.
Bridgewater Systems Mobile Wireless Group Bridgewater Systems Mobile Wireless Group
303 Terry Fox Drive Cisco Systems 303 Terry Fox Drive Cisco Systems
Suite 100 3625 Cisco Way Suite 100 3625 Cisco Way
Ottawa Ontario San Jose, CA 95134 Ottawa Ontario San Jose, CA 95134
Canada USA Canada USA
avi@bridgewatersystems.com pyegani@cisco.com avi@bridgewatersystems.com pyegani@cisco.com
Kuntal Chowdhury Yong Li Kuntal Chowdhury Yong Li
Nortel Networks Bridgewater Systems Starent Networks Bridgewater Systems
2221, Lakeside Blvd, 303 Terry Fox Drive 30 International Place, 3rd Flr 303 Terry Fox Drive
Richardson, TX-75082 Suite 100 Tewksbury, MA 01876 Suite 100
chowdury@nortelnetworks.com Ottawa Ontario kchowdhury@starentnetworks.com Ottawa Ontario
Canada Canada
Yong.li@bridgewatersystems.com Yong.li@bridgewatersystems.com
Christian Guenther Christian Guenther
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
82739 Munich 81739 Munich
Germany Germany
Christian.guenther@siemens.com christian.guenther@siemens.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the IETF's procedures with respect to rights in IETF Information on the IETF's procedures with respect to rights in IETF
skipping to change at page 52, line 28 skipping to change at page 57, line 28
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an ôAS ISö basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright ¨ The Internet Society (2004). This document is subject to Copyright ¨ The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Expiration Date Expiration Date
This memo is filed as draft-lior-radius-extensions-for-prepaid- This memo is filed as draft-lior-radius-extensions-for-prepaid-
06.txt, and will expire 24 March, 2005. 07.txt, and will expire 20 July, 2005.
 End of changes. 101 change blocks. 
157 lines changed or deleted 409 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/