< draft-lior-radius-prepaid-extensions-04.txt   draft-lior-radius-prepaid-extensions-05.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-04.txt Cisco draft-lior-radius-prepaid-extensions-05.txt Cisco
Expires: 14 January, 2005 K. Chowdhury Expires: 17 January, 2005 K. Chowdhury
Nortel Nortel
Y. Li Y. Li
Bridgewater Systems Bridgewater Systems
July 14, 2004 July 19, 2004
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 38 skipping to change at page 1, line 39
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 January 14, 2005 This Internet-Draft will expire on January 17, 2005
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
RADIUS Extensions for PrePaid February 2004
The draft presents an extension to the Remote Authentication Dial-In The draft presents an extension to the Remote Authentication Dial-In
User Service (RADIUS) protocol to support PrePaid data services for User Service (RADIUS) protocol to support PrePaid data services for
a wide range of deployments such as Dial, Wireless, WLAN. a wide range of deployments such as Dial, Wireless, WLAN.
Consideration for roaming using mobile-ip is also given. Consideration for roaming using mobile-ip is also given.
Table of Contents Table of Contents
1. Introduction...................................................4 1. Introduction...................................................4
1.1 Terminology................................................6 1.1 Terminology................................................6
1.2 Requirements language......................................6 1.2 Requirements language......................................6
2. Architectural Model............................................6 2. Architectural Model............................................6
2.1 Why not existing RADIUS attributes?.......................12 2.1 Why not existing RADIUS attributes?.......................12
3. Use-cases.....................................................14 3. Use-cases.....................................................14
3.1 Simple pre-paid access use-case...........................15 3.1 Simple pre-paid access use-case...........................15
3.2 Support for concurrent PrePaid sessions...................17 3.2 Support for Multi-Services................................17
3.3 Support for Roaming.......................................18 3.3 Resource Pools............................................18
3.4 PrePaid termination.......................................19 3.4 Support for Complex Rating Functions......................19
4. Operations....................................................19 3.5 Support for Roaming.......................................20
4.1 General Requirements......................................19 3.6 PrePaid termination.......................................21
4.1.1 Broker AAA Requirements..............................19 4. Operations....................................................21
4.1 General Requirements......................................21
4.1.1 Broker AAA Requirements..............................21
4.2 Authentication and Authorization for Prepaid Enabled Service 4.2 Authentication and Authorization for Prepaid Enabled Service
Access Devices................................................20 Access Devices................................................22
4.2.1 Multiple-Session Pre-paid............................22 4.3 Session Start Operation...................................24
4.3 Session Start Operation...................................22 4.4 Mid-Session Operation.....................................25
4.4 Mid-Session Operation.....................................23 4.5 Dynamic Operations........................................27
4.5 Dynamic Operations........................................25 4.5.1 Unsolicited Session Termination Operation............27
4.5.1 Unsolicited Session Termination Operation............25 4.5.2 Unsolicited Change of Authorization Operation........28
4.5.2 Unsolicited Change of Authorization Operation........26 4.6 Termination Operation.....................................28
4.6 Termination Operation.....................................27 4.7 Mobile IP Operations......................................29
4.7 Mobile IP Operations......................................27 4.8 Operation consideration for Multi-Services................30
4.8 Accounting Considerations.................................28 4.8.1 Initial Quota Request................................31
4.9 Service Device Operation..................................29 4.8.2 Quota Update.........................................31
4.10 Interoperability with Diameter Credit Control Application29 4.8.3 Termination..........................................32
5. Attributes....................................................29 4.8.4 Dynamic Operations...................................32
5.1 PPAC Attribute............................................29 4.8.5 Support for Resource Pools...........................32
5.2 Session Termination Capability............................31 4.8.6 Error Handling.......................................33
5.3 PPAQ Attribute............................................31 4.9 Accounting Considerations.................................33
5.4 Table of Attributes.......................................36 4.10 Service Access Device Operation..........................33
6. Security Considerations.......................................36 4.11 Interoperability with Diameter Credit Control Application33
6.1 Authentication and Authorization..........................36 5. Attributes....................................................34
6.2 Replenishing Procedure....................................36 5.1 PPAC Attribute............................................34
7. IANA Considerations...........................................36 5.2 Session Termination Capability............................35
8. Normative References..........................................37 5.3 PPAQ Attribute............................................35
5.4 Table of Attributes.......................................41
RADIUS Extensions for PrePaid February 2004 6. Security Considerations.......................................41
6.1 Authentication and Authorization..........................41
Acknowledgments..................................................37 6.2 Replenishing Procedure....................................41
Author's Addresses...............................................38 7. IANA Considerations...........................................42
Intellectual Property Statement..................................38 8. Normative References..........................................42
Disclaimer of Validity...........................................39 9. Call Flows....................................................42
Copyright Statement..............................................39 9.1 Simple Concurrent Services................................43
Expiration Date..................................................39 Acknowledgments..................................................46
Author's Addresses...............................................46
RADIUS Extensions for PrePaid February 2004 Intellectual Property Statement..................................47
Disclaimer of Validity...........................................47
Copyright Statement..............................................48
Expiration Date..................................................48
1. Introduction 1. Introduction
This draft describes RADIUS protocol extensions supporting PrePaid This draft describes RADIUS protocol extensions supporting PrePaid
Data Services. 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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
expenditures typically required when rolling out a new service; expenditures typically required when rolling out a new service;
- 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.
RADIUS Extensions for PrePaid February 2004
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.
RADIUS Extensions for PrePaid February 2004
1.1 Terminology 1.1 Terminology
Service Access Device Service Access Device
PrePaid Client PrePaid Client(PPC)
PrePaid Server PrePaid Server(PPS)
Home agent (HA) Home agent (HA)
Home network Home network
Home AAA (HAAA) Home AAA (HAAA)
Broker AAA (BAAA) Broker AAA (BAAA)
Visited AAA (VAAA) Visited AAA (VAAA)
Foreign Agent (FA) Foreign Agent (FA)
WLAN WLAN
Service Device Service Event
Service Event Access Service The service that is provided to the user
when the user is authenticated and
authorized. In this document the term is
used to differentiate between authorization
of services that are explicitly identified
by a Service Id. Example of Access Service
would be the Main Service instance of 3GPP2.
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. Architectural Model 2. Architectural Model
skipping to change at page 7, line 4 skipping to change at page 7, line 10
a prepaid server by using the prepaid RADIUS extensions. a prepaid server by using the prepaid RADIUS extensions.
If real-time credit control is required, the service access device If real-time credit control is required, the service access device
(prepaid client) contacts the prepaid server with service event (prepaid client) contacts the prepaid server with service event
information included before the service is provided. The prepaid information included before the service is provided. The prepaid
server, depending on the service event information, performs credit server, depending on the service event information, performs credit
check and allocates a portion of available credit to the service check and allocates a portion of available credit to the service
event. The rating entity converts this credit value into a time event. The rating entity converts this credit value into a time
and/or volume amount, which is then returned to the requesting and/or volume amount, which is then returned to the requesting
service access device. The rating entity may determine that during service access device. The rating entity may determine that during
RADIUS Extensions for PrePaid February 2004
the allocated quota, a tariff switch will occur in which case the the allocated quota, a tariff switch will occur in which case the
rating entity will include details of the quota allocated prior to rating entity will include details of the quota allocated prior to
the tariff switch, details of the quota allocated after the tariff the tariff switch, details of the quota allocated after the tariff
switch together with details of when the tariff switch will occur. switch together with details of when the tariff switch will occur.
The requesting service access device then monitors service execution The requesting service access device then monitors service execution
according to the instructions returned by the prepaid server. After according to the instructions returned by the prepaid server. After
service completion or on a subsequent request for service, the service completion or on a subsequent request for service, the
prepaid server deducts the reserved allocation of credit from the prepaid server deducts the reserved allocation of credit from the
prepaid userÆs account. prepaid userÆs account.
skipping to change at page 8, line 5 skipping to change at page 8, line 24
+------>| PrePaid | +------>| PrePaid |
prepaid | Server | prepaid | Server |
protocol +--------------+ protocol +--------------+
Figure 1 Basic Prepaid Architecture Figure 1 Basic Prepaid Architecture
The prepaid server and accounting server in this architecture model The prepaid server and accounting server in this architecture model
are logical entities. The real configuration MAY combine them into a are logical entities. The real configuration MAY combine them into a
single host. single host.
RADIUS Extensions for PrePaid February 2004
There MAY exist protocol transparent RADIUS Proxies between prepaid There MAY exist protocol transparent RADIUS Proxies between prepaid
client and prepaid server. These proxies transparently support the client and prepaid server. These proxies transparently support the
prepaid RADIUS extensions. prepaid RADIUS extensions.
In order to generalize the solution, in this paper we generalize the In order to generalize the solution, in this paper we generalize the
Service Access Devices, which in reality may be a NAS in Dialup Service Access Devices, which in reality may be a NAS in Dialup
deployments, PDSN (Packet Data Serving Node) or HA (Home Agent) in deployments, PDSN (Packet Data Serving Node) or HA (Home Agent) in
CDMA2000 deployments, an 802.11 WLAN Access Points or GGSN (Gateway CDMA2000 deployments, an 802.11 WLAN Access Points or GGSN (Gateway
GPRS Serving Node) in GPRS/UMTS deployments. To actively participate GPRS Serving Node) in GPRS/UMTS deployments. To actively participate
in Prepaid procedures outlined here, the Service Access Device MUST in Prepaid procedures outlined here, the Service Access Device MUST
skipping to change at page 9, line 5 skipping to change at page 9, line 21
HAAA communicates with the Prepaid servers using the RADIUS protocol HAAA communicates with the Prepaid servers using the RADIUS protocol
to authorize prepaid subscribers. In AAA based roaming deployments to authorize prepaid subscribers. In AAA based roaming deployments
the AAA server in the visited network, the VAAA, is responsible for the AAA server in the visited network, the VAAA, is responsible for
forwarding the RADIUS messages to the HAAA. The VAAA may also forwarding the RADIUS messages to the HAAA. The VAAA may also
modify the messages. In roaming deployments, the visited network modify the messages. In roaming deployments, the visited network
may be separated from the home network by one or more broker may be separated from the home network by one or more broker
networks. The AAA servers in the broker networks, BAAA are networks. The AAA servers in the broker networks, BAAA are
responsible to route the RADIUS packets transparently and hence responsible to route the RADIUS packets transparently and hence
donÆt play an active roll in the Prepaid Data Service delivery. donÆt play an active roll in the Prepaid Data Service delivery.
RADIUS Extensions for PrePaid February 2004
In this document the Prepaid Server is described in functional terms In this document the Prepaid Server is described in functional terms
related to their interface with the HAAA. The Prepaid Server related to their interface with the HAAA. The Prepaid Server
interfaces to entities which: interfaces to entities which:
i) Keep the accounting state of the prepaid subscribers (balance i) Keep the accounting state of the prepaid subscribers (balance
manager); manager);
ii) Allow access service requests to be rated in real-time (Rating ii) Allow access service requests to be rated in real-time (Rating
Engine); and Engine); and
iii) Allow quota to be managed for a particular pre-paid service iii) Allow quota to be managed for a particular pre-paid service
(Quota Server). (Quota Server).
skipping to change at page 10, line 5 skipping to change at page 10, line 9
Service Access Device. Service Access Device.
The network will have one or more Prepaid Servers. Multiple Prepaid The network will have one or more Prepaid Servers. Multiple Prepaid
Servers may be used to provide redundancy and load sharing. The Servers may be used to provide redundancy and load sharing. The
interface between the HAAA and the PPS is implemented using the interface between the HAAA and the PPS is implemented using the
RADIUS protocol in this specification. However, in cases where the RADIUS protocol in this specification. However, in cases where the
PPS does not implement the RADIUS protocol, the implementation would PPS does not implement the RADIUS protocol, the implementation would
have to map the requirements defined in this document to whatever have to map the requirements defined in this document to whatever
protocol is used between the HAAA and the PPS. protocol is used between the HAAA and the PPS.
RADIUS Extensions for PrePaid February 2004
+------+ +-----+ +------+ +-----+
| | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | | | | | | | | | | | | | |
| Sub | | Service| | +------+ | +-----+ | Sub | | Service| | +------+ | +-----+
| |---| Access |--+ | | |---| Access |--+ |
| Device | | Device | | +------+ | +-----+ | Device | | Device | | +------+ | +-----+
| | | | | | | | | | | | | | | | | | | |
+--------+ +--------+ +--| HAAA |--+--| PPS | +--------+ +--------+ +--| HAAA |--+--| PPS |
| | | | | | | |
skipping to change at page 10, line 37 skipping to change at page 10, line 39
+------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|Sub | |Service| | +----+ | +----+ | +----+ | +-----+ |Sub | |Service| | +----+ | +----+ | +----+ | +-----+
| |--|Access |-+ | | | | |--|Access |-+ | | |
|Device| |Device | | +----+ | +----+ | +----+ | +-----+ |Device| |Device | | +----+ | +----+ | +----+ | +-----+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS | +------+ +-------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
| | | | | | | | | | | | | | | |
+----+ +----+ +----+ +-----+ +----+ +----+ +----+ +-----+
| Visited | |Broker | | Home | | Visited | |Broker | | Home |
| Network | |Network| | Network | | Network | |Network| | Network |
Figure 3 Static Roaming Prepaid Architecture Figure 3 Static Roaming Prepaid Architecture
As in the basic prepaid architecture the subscriberÆs device As in the basic prepaid architecture the subscriberÆs device
establishes a connection with the Service Access Device (NAS, WLAN establishes a connection with the Service Access Device (NAS, WLAN
Access Point). The Service Access Device communicates with the Access Point). The Service Access Device communicates with the
Visiting AAA server (VAAA) using the RADIUS protocol. Again for Visiting AAA server (VAAA) using the RADIUS protocol. Again for
redundancy there maybe more then one VAAA. The VAAA communicate redundancy there maybe more then one VAAA. The VAAA communicate
using the RADIUS protocol with AAA servers in the broker network using the RADIUS protocol with AAA servers in the broker network
(BAAA). There maybe more then one Broker Network between the (BAAA). There maybe more then one Broker Network between the
RADIUS Extensions for PrePaid February 2004
Visited Network and the Home Network. The Home Network is the same Visited Network and the Home Network. The Home Network is the same
as in the simple architecture. as in the simple architecture.
To support dynamic roaming the network will utilize Mobile-Ip as To support dynamic roaming the network will utilize Mobile-Ip as
illustrated in Figure 4. Note that typically the mobile device illustrated in Figure 4. Note that typically the mobile device
would be moving between networks that use the same technology such would be moving between networks that use the same technology such
as Wireless or WLAN. Increasingly, device will be able to roam as Wireless or WLAN. Increasingly, device will be able to roam
between networks that use different technology such as between WLAN between networks that use different technology such as between WLAN
and Wireless and Broadband. Fortunately, Mobile-Ip can address this and Wireless and Broadband. Fortunately, Mobile-Ip can address this
type of roaming and therefore we need not be concerned with the type of roaming and therefore we need not be concerned with the
skipping to change at page 12, line 4 skipping to change at page 12, line 8
Figure 4 Roaming using Mobile-IP and pre-paid enabled Service Figure 4 Roaming using Mobile-IP and pre-paid enabled Service
Access Devices Access Devices
In figure 4, the Subscriber device establishes a prepaid session In figure 4, the Subscriber device establishes a prepaid session
between the Service Access Device in the foreign network, which has between the Service Access Device in the foreign network, which has
prepaid capabilities. The subscriberÆs home address will be prepaid capabilities. The subscriberÆs home address will be
anchored at the Home Agent (HA) in the home network. The setup for anchored at the Home Agent (HA) in the home network. The setup for
this access service is identical to the cases covered above. Notice this access service is identical to the cases covered above. Notice
that the Service Access Device may be collocated with the Foreign that the Service Access Device may be collocated with the Foreign
RADIUS Extensions for PrePaid February 2004
Agent (FA) in case of Mobile-IPv4. As the subscriber device moves Agent (FA) in case of Mobile-IPv4. As the subscriber device moves
it establishes a connection with another Service Access Device in it establishes a connection with another Service Access Device in
the same foreign network or in another foreign network. The prepaid the same foreign network or in another foreign network. The prepaid
data service should continue to be available. When a device data service should continue to be available. When a device
associates to another Service Access Device it MUST re-authenticate associates to another Service Access Device it MUST re-authenticate
at the new Service Access Device and de-associate or logoff from the at the new Service Access Device and de-associate or logoff from the
old Service Access Device. Furthermore, any unused quota at the old old Service Access Device. Furthermore, any unused quota at the old
Service Access Device MUST be promptly credited back to the Service Access Device MUST be promptly credited back to the
subscribers account. The reason we say promptly, is because if the subscribers account. The reason we say promptly, is because if the
subscriber is very low on resources to start with, the subscriber subscriber is very low on resources to start with, the subscriber
skipping to change at page 13, line 5 skipping to change at page 13, line 8
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
more resources in the userÆs account. more resources in the userÆs account.
RADIUS Extensions for PrePaid February 2004
If the user terminates the session before the time expressed in If the user terminates the session before the time expressed in
Session-Timeout(27). The NAS will recover any unused time from the Session-Timeout(27). The NAS will recover any unused time from the
accounting stream. accounting stream.
There are several problems with such a solution: There are several problems with such a solution:
-It only allows for time-based prepaid. The solution presented in -It only allows for time-based prepaid. The solution presented in
this document allows for both time and volume based prepaid. As this document allows for both time and volume based prepaid. As
well as extensibility for other features such as tarified based well as extensibility for other features such as tarified based
solutions. solutions.
skipping to change at page 14, line 4 skipping to change at page 14, line 9
was generated. The RADIUS server will have to wait for the was generated. The RADIUS server will have to wait for the
corresponding accounting packet to determine the reason for this corresponding accounting packet to determine the reason for this
Access-Request message. Lastly re-authenticating the subscriber may Access-Request message. Lastly re-authenticating the subscriber may
take far too long. The solution presented in this document allows take far too long. The solution presented in this document allows
quota replenishing to occur in an undisruptive manner from the quota replenishing to occur in an undisruptive manner from the
perspective of the user. No re-authentication is required and perspective of the user. No re-authentication is required and
quotas can be negotiated prior to the quotas running out. quotas can be negotiated prior to the quotas running out.
-Prepaid ambiguity. Implementing prepaid using existing RADIUS -Prepaid ambiguity. Implementing prepaid using existing RADIUS
attributes presents another problem. Due to the fact that the attributes presents another problem. Due to the fact that the
RADIUS Extensions for PrePaid February 2004
standard RADIUS attributes are not mandatory, then the correct standard RADIUS attributes are not mandatory, then the correct
prepaid operation is really an act of faith on the part of the prepaid operation is really an act of faith on the part of the
RADIUS server. If Session-Timeout(27) and/or Termination-Action(29) RADIUS server. If Session-Timeout(27) and/or Termination-Action(29)
are not supported, the prepaid subscriber will get free access. The are not supported, the prepaid subscriber will get free access. The
solution described in this document, requires that a prepaid capable solution described in this document, requires that a prepaid capable
Service Access Device inform the RADIUS server whether or not it Service Access Device inform the RADIUS server whether or not it
supports prepaid capabilities. The RADIUS server can now determine supports prepaid capabilities. The RADIUS server can now determine
whether service should be granted or not. For example, if a prepaid whether service should be granted or not. For example, if a prepaid
subscriber is connected to a NAS that does not support prepaid, the subscriber is connected to a NAS that does not support prepaid, the
RADIUS server can either instruct the NAS to tunnel the traffic to RADIUS server can either instruct the NAS to tunnel the traffic to
skipping to change at page 15, line 4 skipping to change at page 15, line 9
establish the requirements needed to deliver PrePaid data services. establish the requirements needed to deliver PrePaid data services.
These use cases donÆt address how the PrePaid account is established These use cases donÆt address how the PrePaid account is established
or maintained. It is assumed that the PrePaid subscriber has or maintained. It is assumed that the PrePaid subscriber has
obtained a valid account from a service provider such as a wireless obtained a valid account from a service provider such as a wireless
operator or a WLAN operator. 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 Service Access Device and not from the UserÆs experience from the Service Access Device and not from the UserÆs
Device. The connection between the UserÆs Device, which typically Device. The connection between the UserÆs Device, which typically
involves setting up a layer 2 session, e.g., PPP session or GPRS PDP involves setting up a layer 2 session, e.g., PPP session or GPRS PDP
RADIUS Extensions for PrePaid February 2004
Context, is specific to a given network technology and the details Context, is specific to a given network technology and the details
are not required to deliver a PrePaid service. are not 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 Service Access Device sends a RADIUS Access-Request to the AAA The Service Access Device sends a RADIUS Access-Request to the AAA
skipping to change at page 15, line 40 skipping to change at page 15, line 42
The PrePaid System will validate that the subscriber has a PrePaid The PrePaid System will validate that the subscriber has a PrePaid
Account; it will validate that the account is active; and will Account; it will validate that the account is active; and will
validate that the Service Access Device has the appropriate PrePaid validate that the Service Access Device has the appropriate PrePaid
capabilities. If all is in order, the PrePaid System will authorize capabilities. If all is in order, the PrePaid System will authorize
the subscriber to use the network. Otherwise it will reject the the subscriber to use the network. Otherwise it will reject the
request. The response is sent back to the AAA System. The response request. The response is sent back to the AAA System. The response
includes attributes to indicate the allocation of a portion of the includes attributes to indicate the allocation of a portion of the
subscriberÆs account called the initial quota (in units of time or subscriberÆs account called the initial quota (in units of time or
volume) and optionally a threshold value. volume) and optionally a threshold value.
[Editor comments: we should leave tariff switch issues to another The reason we allocate a portion of the userÆs account is that the
document. One way to deal with a tariff switch is to set the user may be engaged in other Services that may draw on the same
threshold or quota such that a new allocation is requested just Prepaid account. For example the user may be engaged in a data
before or at the tariff switch period.] session and a voice session. Although, these two services would
draw from the same account the involved separate parts of the
When the rating engine has determined that a tariff switch will system. If the entire quota was allocated to the data session then
shortly occur, the initial quota may be segmented into that which the user would have no more funds for a voice session.
SHOULD be used before the tariff switch, that which SHOULD be used
RADIUS Extensions for PrePaid February 2004
after the tariff switch together with details describing the tariff
switching instant.
The Access Device is responsible for requesting quota to be allocate
for a particular prepaid user.
[NEED A USE CASE FOR CONCURTENT PREPAID SESSIONS]
In order to support concurrent PrePaid sessions, at any time, the
PrePaid System allocates a portion of the subscribers account to a
given PrePaid session. For example, in a multi-service environment
it might happen that an end user with an already ongoing service
(e.g., browsing the Internet) issues a new service request (e.g.,
for downloading a ring-tone) towards the same account. Throughout
the lifetime of a session the Access Device will monitor usage
according to the quota(s) returned from the prepaid server and will
request further quota updates from the PrePaid System as previously
allocated quotas are consumed. Conditions may be included with
quotas, which indicate when an allocated quota should be returned to
the prepaid system. These conditions can include an Idle-Timeout(28)
associated with the provided quota. In this case, the Access device
monitors the service for activity. When a single inactivity period
exceeds that provided in the quota conditions, the unused quota is
returned to the prepaid server.
The AAA system incorporates the PrePaid attributes received from the The AAA system incorporates the PrePaid attributes received from the
PrePaid System into an Access-Accept message that it sends back to PrePaid System into an Access-Accept message that it sends back to
the Service Access Device. Note the AAA System is responsible for the Service Access Device. Note the AAA System is responsible for
authorizing the service whereas the PrePaid System is responsible authorizing the service whereas the PrePaid System is responsible
for PrePaid authorization. for PrePaid authorization.
Upon receiving the Access-Response, the Service Access Device allows Upon receiving the Access-Response, the Service Access Device allows
the PrePaid data session to start and it starts to meter the session the PrePaid data session to start and it starts to meter the session
based on time or volume, as indicated in the returned Quota based on time or volume, as indicated in the returned Quota
Once the usage for the session approaches the allotted quota (as Once the usage for the session approaches the allotted quota (as
expressed by the threshold), the Service Access Device will request expressed by the threshold), the Service Access Device will request
an additional quota. The re-authorization for additional quota an additional quota. The re-authorization for additional quota
flows through the AAA system to the PrePaid System. The PrePaid flows through the AAA system to the PrePaid System. The PrePaid
System revalidates the subscriberÆs account; it will subtract the System revalidates the subscriberÆs account; it will subtract the
previous quota allocation from the userÆs balance and if there is a previous quota allocation from the userÆs account balance and if
balance remaining it will reauthorize the request with an additional there is a balance remaining it will reauthorize the request with an
quota allotment. Otherwise, the PrePaid System will reject the additional quota allotment. Otherwise, the PrePaid System will
reject the request. Note the replenishing of the quotas is a re-
RADIUS Extensions for PrePaid February 2004 authorization procedure and does not involve re-authentication of
the subscriber.
request. Note the replenishing of the quotas is a re-authorization
procedure and does not involve re-authentication of the subscriber.
It is important to note that the PrePaid System is maintaining It is important to note that the PrePaid System is maintaining
session state for the subscriber. This state includes how much session state for the subscriber. This state includes how much
account balance was allocated during the last quota allocation for a account balance was allocated during the last quota allocation for a
particular session and how much is left in the account. Therefore, particular session and how much is left in the account. Therefore,
it is required that all subsequent messages about the PrePaid it is required that all subsequent messages about the PrePaid
session reach the correct PrePaid System. session reach the correct PrePaid System.
Upon receiving a re-allotment of the quota, the Service Access Upon receiving a re-allotment of the quota, the Service Access
Device will, continue the data service session until the new Device will, continue the data service session until the new
skipping to change at page 17, line 38 skipping to change at page 17, line 15
their initial PrePaid Service. their initial PrePaid 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 concurrent PrePaid sessions 3.2 Support for Multi-Services
[REPLACE THIS TEXT WITH TOKEN BASED PREPAID] Up to now we were looking at session that consisted of a single
service, ôAccess Serviceö. An ôAccess Serviceö is the basic service
that is provided to the user by the Service Access Device after
successful authentication and authorization. When we donÆt
differentiate between different types of services the ôAccess
Serviceö aggregates all the services that the user my be engaged in
on a particular Service Access Device. For example, the user may be
browsing the web, and participating in a VoIP conversation, watching
streaming video and downloading a file.
Both prepaid support using Access Devices and prepaid support using Some operators may want to distinguish these Services. Some
Service Devices can be configured to support a prepaid multi-service services are billed at different rates and Services maybe metered
environment. In such circumstances, the prepaid client capabilities differently. Therefore, the prepaid solution needs to be able to
will indicate that the Access or Service Device supports a multi- distinguish Services, and allocate quotas to the Services using
service environment [Editor: need to add this to the PPAC]. [Editor: different units (e.g. time, volume) and allow for those quotas to be
This needs to be reworked. DonÆt believe that this step is required. utilized at different rates.
The Service Ids should be known a priori ¡ the Access Request should
RADIUS Extensions for PrePaid February 2004 +---------+
| Session |
+---------+
|
V N
+--------------+ +-------+
| Service |------>| Quota |
| (service-Id) | +-------+
+--------------+
include the Service Key being requested.] In such circumstances, As shown in the above diagram, a Session can have N Services. Each
instead of returning a quota, the prepaid service provides a list of service is identified by a Service-Id. The format of the Service-Id
authorized services corresponding to a list of service keys to the is not in the scope of this document but the Service-Id could be
prepaid client. The Access/Service device then uses these service expressed as an IP flow using the IP 5-tuple (Source-IP and Port,
keys to request prepaid authorization to the corresponding services. the Destination-IP and Port, and the protocol). Each Service is
The prepaid server responds with an individual quota for the allocated a Quota appropriate to the service.
requested service key [Editor: add service key to PPAQ]. The
Access/Service Device may in parallel request prepaid authorization
to a second service key. In which case a separate authorization
exchange is used to provide an independent quota for this second
service.
Each session is treated independently. 3.3 Resource Pools
The method by which a prepaid user activates a service and the When working with multiple services which results in multiple quota
method for signalling this information to the Access/Service Device allocation another problem arises. Even though quotas are portioned
is out of scope of this draft. out in fractional parts of the users prepaid account, there could be
a situation where one Service utilizes its quota faster then another
Service. When the userÆs account is used up, there could be a
situation where one Service is unable to obtain additional quota
while another Service has plenty of quota remaining. Unless the
quotas can be rebalanced, the Service Access Device would then have
to terminate that Service. As well, even before that happens, the
existence of several Services could generate an excessive amount of
traffic as the services update their quotas.
The method by which a granular service is defined is out of scope of One method to solve these problems is to utilize resource pools.
this draft. Only service key correlation information is required to Resource pools allow us to allocate resources to several services of
enable the prepaid server to authorize and rate a particular a session by allocating resources to a pool and have services draw
request. their quota from the pool at a rate appropriate to that service.
When the quota allocated to the pool runs out, we replenish the
pool.
+-----------+
| Service-A |-----+ +--------+
+-----------+ | Ma | |
+-------->| |
| Pool |
+-------->| (1) |
+-----------+ | Mb | |
| Service-B |-----+ +--------+
+-----------+
3.3 Support for Roaming As the above figure shows, Service-A and Service-B is bound to
Pool(1). Ma and Mb are the pool multipliers (that are associated
with Service-A and Service-B respectively) that determines the rate
at which Service-A and Service-B draw from the pool.
The pool is initialized by taking the quota allocated to each
service and multiplying it by Mn. Therefore, the amount of
resources allocated to a pool is given by:
Poolr = Ma*Qa + Mb*Qb + . . .
A Pool is empty if:
Poolr <= Ca*Ma + Cb*Mb + . . .
where:
Ca,Cb are the consumed resources of Service-A and Service-B
respectively.
Note that the resources assigned to the pool are unit less. That
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
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
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 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.
3.4 Support for Complex Rating Functions
The rate of use of a resource by a service can be very complex.
Some services use resources (e.g. time, volume) linearly. For
example, a service maybe consuming resources at a rate of $1 per
Mbyte.
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
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
at $0.50 per Mbyte. This rating function could be achieved by
repeated message exchanges with the Prepaid System.
To avert the need to exchange many messages and to support even more
complex rating functions we support Rating Groups. A Rating Group
is provisioned at the Service Access Device. As illustrated in the
figure below, a Rating Group is associated with one or more Services
and defines the rate that the services associated with the Rating
Group consume the quota.
+-----------+
| Service-A |------+
+-----------+ | +--------------+ +-------+
+---->| | | Quota |
| Rating Group |------>| or |
+-----------+ +---->| | | Pool |
| Service-B |------+ +--------------+ +-------+
+-----------+
During authorization of the of a service, if the service is
associated with a Rating Group, the Prepaid Client sends the Rating
Group to the Prepaid Server. The prepaid service authorizes the
Rating Group by assigning it a Quota and optionally assigning it to
a Resource Pool.
When service that belongs to an authorized Rating Group is
instantiated, then the Prepaid Client does not need to authorize
that service. This could greatly reduce the amount of traffic
between the Prepaid Client and the Prepaid Server.
3.5 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.
Dynamic roaming allows to subscriber to move between networks while Dynamic roaming allows to subscriber to move between networks while
maintaining a connection with the home network seamlessly. As the maintaining a connection with the home network seamlessly. As the
subscriber moves between networks, the data session is handed off subscriber moves between networks, the data session is handed off
between the networks. between the networks.
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.
RADIUS Extensions for PrePaid February 2004
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.4 PrePaid termination 3.6 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
skipping to change at page 20, line 5 skipping to change at page 22, line 11
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].
RADIUS Extensions for PrePaid February 2004
4.2 Authentication and Authorization for Prepaid Enabled Service Access 4.2 Authentication and Authorization for Prepaid Enabled Service Access
Devices Devices
The Service Access Device initiates the authentication and The Service Access Device initiates the authentication and
authorization procedure by sending a RADIUS Access-Request to the authorization procedure by sending a RADIUS Access-Request to the
HAAA. HAAA.
If the Service Access Device has PrePaid Client capabilities, it If the Service Access Device has PrePaid Client capabilities, it
MUST include the PPAC(TBD) attribute in the RADIUS Access-Request. MUST include the PPAC(TBD) attribute in the RADIUS Access-Request.
The PPAC(TBD) attribute indicates to the PrePaid server the PrePaid The PPAC(TBD) attribute indicates to the PrePaid server the PrePaid
skipping to change at page 21, line 4 skipping to change at page 23, line 9
may be proxied through zero or more BAAA. may be proxied through zero or more BAAA.
Once the Access-Request arrives at the HAAA, the HAAA will Once the Access-Request arrives at the HAAA, the HAAA will
authenticate the subscriber. If the subscriber is cannot be authenticate the subscriber. If the subscriber is cannot be
authenticated, the HAAA will send an Access-Reject message back to authenticated, the HAAA will send an Access-Reject message back to
the client. If the subscriber is authenticated, the HAAA will the client. If the subscriber is authenticated, the HAAA will
determine whether or not the subscriber is a PrePaid subscriber. determine whether or not the subscriber is a PrePaid subscriber.
The techniques used to determine whether or not a subscriber is a The techniques used to determine whether or not a subscriber is a
PrePaid subscriber is beyond the scope of this document. If the PrePaid subscriber is beyond the scope of this document. If the
subscriber is not a PrePaid subscriber, then the HAAA will respond subscriber is not a PrePaid subscriber, then the HAAA will respond
RADIUS Extensions for PrePaid February 2004
as usual with an Access-Accept or Access-Reject message. If the as usual with an Access-Accept or Access-Reject message. If the
subscriber is a PrePaid Subscriber the HAAA SHALL forward the subscriber is a PrePaid Subscriber the HAAA SHALL forward the
Access-Request to a PrePaid server for further authorization. Access-Request to a PrePaid server for further authorization.
The Access-Request will contain the PPAC(TBD) attribute, the The Access-Request will contain the PPAC(TBD) attribute, the
Dynamic-Capabilities attribute if one was included; the User-Name(1) Dynamic-Capabilities attribute if one was included; the User-Name(1)
attribute MAY be set to a value that would represent the attribute MAY be set to a value that would represent the
SubscriberÆs PrePaid Identity. This attribute is used by the SubscriberÆs PrePaid Identity. This attribute is used by the
PrePaid server to locate the PrePaid SubscriberÆs account. For PrePaid server to locate the PrePaid SubscriberÆs account. For
added security, the HAAA MAY also set the User-Password(2) attribute added security, the HAAA MAY also set the User-Password(2) attribute
skipping to change at page 22, line 4 skipping to change at page 24, line 10
- The IP address of the Serving PrePaid Server and one or more - The IP address of the Serving PrePaid Server and one or more
alternative PrePaid Servers. This is used by the HAAA to route alternative PrePaid Servers. This is used by the HAAA to route
subsequent quota replenishing messages to the appropriate PrePaid subsequent quota replenishing messages to the appropriate PrePaid
server(s). server(s).
Note: Idle-Timeout(28) can be used to trigger the premature Note: Idle-Timeout(28) can be used to trigger the premature
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
RADIUS Extensions for PrePaid February 2004
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 defined in the Redirect I-d. The period of time before the
blocked/redirected session last can be specified by Session- blocked/redirected session last can be specified by Session-
Timeout(27) attribute. 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 Service Access Device. The HAAA SHALL NOT append or overwrite the Service Access Device. The HAAA SHOULD NOT overwrite any
any attributes already set by the PrePaid server. If the HAAA, attributes already set by the PrePaid server. If the HAAA, receives
receives an Access-Reject message, it will simply forward the packet an Access-Reject message, it will simply forward the packet to its
to its client. Depending on site policies, if the HAAA fails to client. Depending on site policies, if the HAAA fails to receive an
receive an Access-Accept or Access-Reject message from the PrePaid Access-Accept or Access-Reject message from the PrePaid server it
server it MAY do nothing or send an Access-Reject or an Access- MAY do nothing or send an Access-Reject or an Access-Accept message
Accept message back to its client. back to its client.
4.2.1 Multiple-Session Pre-paid
To be completed in the next release.
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.
If the Prepaid server does not receive the Accounting-Request(start) If the Prepaid server does not receive the Accounting-Request(start)
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
RADIUS Extensions for PrePaid February 2004
Service Access Device supports termination capabilities, the PPS Service Access Device supports termination capabilities, the PPS
SHOULD send a Disconnect Message to the Service Access Device to SHOULD send a Disconnect Message to the Service Access Device to
ensure that the session is indeed dead. ensure that the session is indeed dead.
4.4 Mid-Session Operation 4.4 Mid-Session Operation
During the lifetime of a PrePaid data session the Service Access During the lifetime of a PrePaid data session the Service Access
Device will request to replenish the quotas using Authorize-Only Device will request to replenish the quotas using Authorize-Only
Access-Request messages. Access-Request messages.
skipping to change at page 24, line 4 skipping to change at page 26, line 5
Message-Authenticator(80) it SHALL silently discard the message. An Message-Authenticator(80) it SHALL silently discard the message. An
Authorize Only Access-Request message that does not contain a Authorize Only Access-Request message that does not contain a
PPAQ(TBD) is either in error or belongs to another application (for PPAQ(TBD) is either in error or belongs to another application (for
example, a Change of Authorization message [RFC3576]). In this case example, a Change of Authorization message [RFC3576]). In this case
the Authorize Only Access-Request will either be silently discarded the Authorize Only Access-Request will either be silently discarded
or handled by another application (not in scope of this document). or handled by another application (not in scope of this document).
Once the Authorize Only Access-Request message is validated, the Once the Authorize Only Access-Request message is validated, the
HAAA SHALL forward the Authorize Only Access-Request to the HAAA SHALL forward the Authorize Only Access-Request to the
appropriate PrePaid Server. The HAAA MUST forward the Authorize appropriate PrePaid Server. The HAAA MUST forward the Authorize
RADIUS Extensions for PrePaid February 2004
Only Access-Request to the PrePaid server specified in the Only Access-Request to the PrePaid server specified in the
PPAQ(TBD). The HAAA MUST sign the message using the Message- PPAQ(TBD). The HAAA MUST sign the message using the Message-
Authenticator(80) and the procedures in [RFC2869]. As with the Authenticator(80) and the procedures in [RFC2869]. As with the
Access-Request message, the HAAA MAY modify the User-Name(1) Access-Request message, the HAAA MAY modify the User-Name(1)
attribute to a value that represents the userÆs internal PrePaid attribute to a value that represents the userÆs internal PrePaid
account in the PrePaid server. Note the PrePaid server could use account in the PrePaid server. Note the PrePaid server could use
the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate the Quota-ID sub-attribute contained within the PPAQ(TBD) to locate
the user account. the user account.
Upon receiving the Authorize Only Access-Request containing a Upon receiving the Authorize Only Access-Request containing a
skipping to change at page 25, line 5 skipping to change at page 27, line 7
short duration to allow them to replenish their account, or create short duration to allow them to replenish their account, or create
an account; or to browse free content. an account; or to browse free content.
Upon receiving the Access-Accept from the PrePaid server, the HAAA Upon receiving the Access-Accept from the PrePaid server, the HAAA
SHALL return the packet to its client. If the HAAA, receives an SHALL return the packet to its client. If the HAAA, receives an
Access-Reject message, it will forward the packet. Depending on Access-Reject message, it will forward the packet. Depending on
site policies, if the HAAA fails to receive an Access-Accept or an site policies, if the HAAA fails to receive an Access-Accept or an
Access-Reject message from the PrePaid server it MAY do nothing or Access-Reject message from the PrePaid server it MAY do nothing or
it MAY send an Access-Reject message back to its client. it MAY send an Access-Reject message back to its client.
RADIUS Extensions for PrePaid February 2004
Upon receiving an Access-Accept, the Service Access Device SHALL Upon receiving an Access-Accept, the Service Access Device SHALL
update its quotas and threshold parameters with the values contained update its quotas and threshold parameters with the values contained
in the PPAQ(TBD) attribute. Note that the PrePaid server MAY update in the PPAQ(TBD) attribute. Note that the PrePaid server MAY update
the PrePaidServer attribute(s) and these may have to be saved as the PrePaidServer attribute(s) and these may have to be saved as
well. 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 Service Access Device SHALL restrict the subscriber session The Service Access Device SHALL restrict the subscriber session
accordingly. 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 Service Access Device as capabilities that are supported by the Service Access Device as
advertised in the Dynamic-Capabilities attribute during the initial advertised in the Dynamic-Capabilities attribute during the initial
Access-Request. 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 the filters associated with the session be modified. that attributes associated with the session be modified. More
specifically, it can modify previously sent PPAQ(TBD)
Both of these actions require that the session be uniquely Both of these actions require that the session be uniquely
identified at the Service Access Device. As a minimum the PrePaid identified at the Service Access Device. As a minimum the PrePaid
server: server:
-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.
4.5.1 Unsolicited Session Termination Operation For a discussion on Dynamic Operations as they related Mutli-Service
operations see further on.
This capability is described in detail in [RFC3576]. The PrePaid
server sends a Disconnect Request packet that MUST contain
identifiers that uniquely identify the subscriberÆs data session and
the Service Access Device servicing that session.
Upon receiving the Disconnect Request packet the HAAA will either
act on it or will proxy it to another AAA server until it is
RADIUS Extensions for PrePaid February 2004
received by the a AAA that is in the same network as the serving
Service Access Device.
Each AAA MUST route the Disconnect Request packet to the AAA that is
in the same network as the serving Service Access Device (as per
[RFC3576]).
If the Service Access Device receives a Disconnect-Request packet, 4.5.1 Unsolicited Session Termination Operation
it will respond with either a Disconnect-ACK packet if it was able At anytime during a session the Prepaid Server may send a Disconnect
to terminate the session or else it will respond with a Disconnect- Message to terminate a session. This capability is described in
NAK packet. detail in [RFC3576]. The PrePaid server sends a Disconnect Message
that MUST contain identifiers that uniquely identify the
subscriberÆs data session and the Service Access Device servicing
that session.
If the AAA server is performing the disconnect operation, it MUST If the Service Access Device receives a Disconnect-Message, it will
respond with a Disconnect-ACK message if it successfully terminated respond with either a Disconnect-ACK packet if it was able to
the session or a Disconnect-NAK message if it failed to terminate terminate the session or else it will respond with a Disconnect-NAK
the session with the appropriate Error-Cause(101) set. packet.
If any AAA server is unable to route the Disconnect-Request it MUST Upon successful termination of a session the Service Access Device
respond with a Disconnect-NAK packet with Error-Cause(101) set to MUST return any unused quota to the Prepaid Server by issuing an
ôRequest Not Routableö(502). Authorize Only Access-Request containing the PPAQ which contains any
unused Quota 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
The PrePaid Server MAY send a Change-of-Authorization message as At anytime during the prepaid session the Prepaid Client may receive
described in [RFC3576] to restrict Internet access when the a Change of Authorization (CoA) message. A Prepaid Server may send
subscriber has no more balance. The COA packet may contain Filter- a new Quota to either add additional quota or to remove quota
Id(11) and or attributes defined in Redirect I-d. already allocated for the service.
The PrePaid server sends a Change-of-Authorization packet it MUST
contain identifiers that will uniquely identify the subscriber
session and the Service Access Device serving that session.
Upon receiving the Change-of-Authorization packet the HAAA will
either act on it or proxy it to another AAA server until it is
received by a AAA server that is in the same network as the serving
Service Access Device.
Each AAA must route the packet to the serving network. How the
routing decision is made is an implementation detail.
Once the Change-of-Authorization packet reaches a AAA that is in the
same network as the serving Service Access Device, if the Service
RADIUS Extensions for PrePaid February 2004
Access Device supports Change-of-Authorization message, it will If the Change of Authorization contains a PPAQ then that PPAQ will
forward the message to the Service Access Device. override a previously received PPAQ. The PPAQ may contain more
allocated Quota or less allocated quota. The PPS MUST NOT change
the units used in the PPAQ.
If the Service Access Device receives a Change-of-Authorization If the newly received PPAQ reduces the amount of allocated quota
packet, it will respond with either a Change-of-Authorization-ACK beyond what is currently used then the Service Access Device will
packet if it was able to change the filter or else it will respond accept the new PPAQ and act as it normally would when the quota is
with a Change-of-Authorization-NAK packet. used up. For 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 Service Access Device would follow the normal
procedures followed when a quota is used 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 Service Access off; the quotas have been consumed, or when the Service Access
Device receives a Disconnect Message. In all of these instances, if Device receives a Disconnect Message.
the session is a PrePaid data session, the Service Access Device
will send an Authorize-Only Access-Request message with a PPAQ(TBD) In the case where the user logged off, or the Service Access Device
receives a Disconnect Message, the Service Access Device will send
an Authorize-Only Access-Request message with a PPAQ(TBD) and
Update-Reason attribute set to either ôClient Service terminationö Update-Reason attribute set to either ôClient Service terminationö
or ôRemote Forced disconnectö and the currently used quota. or ôRemote Forced disconnectö and the currently used quota.
The BAAA MUST forward this packet to the next BAAA or the HAAA. In the case where the quota has been reached, if the PPAQ(TBD)
contained Termination-Action field, the Service Access Device will
The HAAA MUST validate the Authorize Only Access-Request using the follow the specified action which would be to immediately terminate
Message-Authenticator(80) as per [RFC2869] and if valid, use the the service, to request more quota, or to Redirect/Filter the
PrePaidServer subtype in the PPAQ(TBD) to forward the Authorize Only service.
Access-Request packet to the serving PrePaid Server or if needed,
its alternate.
The PrePaid Server MUST validate the Authorize Only Access Request
and use the information contained in the PPAQ(TBD) attribute to
adjust the subscriberÆs balance and to close the session. The
PrePaid Server SHALL respond back with an Access-Accept message.
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 Service be maintained transparently if the HA is acting as the Service
Access Device. Access Device.
As the subscriber device associates with the new Service Access As the subscriber device associates with the new Service Access
Device (AP or PDSN that supports prepaid client capability), the Device (AP or PDSN that supports prepaid client capability), the
Service Access Device sends a RADIUS Access-Request and the Service Access Device sends a RADIUS Access-Request and the
RADIUS Extensions for PrePaid February 2004
subscriber is re-authenticated and reauthorized. The Service Access subscriber is re-authenticated and reauthorized. The Service Access
Device MUST include the PPAC(TBD) attribute in the RADIUS Access- Device MUST include the PPAC(TBD) attribute in the RADIUS Access-
Request. In this manner the procedure follows the Authentication Request. In this manner the procedure follows the Authentication
and Authorization procedure described earlier. and Authorization procedure described earlier.
If the HA was acting as the Service Access Device before handoff, If the HA was acting as the Service Access Device before handoff,
the userÆs prepaid session does not undergo any change after the the userÆs prepaid session does not undergo any change after the
handoff because the Mobile IP session is anchored at the HA and the handoff because the Mobile IP session is anchored at the HA and the
userÆs Home IP address remains the same. userÆs Home IP address remains the same.
skipping to change at page 28, line 33 skipping to change at page 30, line 14
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 Service Access Device request. Any outstanding quota at the old Service Access Device
MUST be returned to the PrePaid system. If the Mobile-IP nodes (HA MUST be returned to the PrePaid system. If the Mobile-IP nodes (HA
and FA) supports registration revocation (Mobile IPv4 only). and FA) supports registration revocation (Mobile IPv4 only).
Specifically, the quota SHOULD be returned when the Service Access Specifically, the quota SHOULD be returned when the Service Access
Device sends the Authorize Only Access-Request with PPAQ(TBD) Device sends the Authorize Only Access-Request with PPAQ(TBD)
Update-Reason set to either ôRemote Forced disconnectö or ôClient Update-Reason set to either ôRemote Forced disconnectö or ôClient
Service terminationö. In order to trigger the sending of this last Service terminationö. In order to trigger the sending of this last
Authorize Only Access-Request, the PrePaid system may issue a Authorize Only Access-Request, the PrePaid system may issue a
Disconnect Message [CHIBA] to the Service Access Device. Disconnect Message [3576] to the Service Access Device.
If the subscriber has roamed to a Service Access Device that does If the subscriber has roamed to an Service Access Device that does
not have any PrePaid Capabilities, PrePaid data service may still be not have any PrePaid Capabilities, PrePaid data service may still be
possible by requesting the Home Agent (providing it has PrePaid possible by requesting the Home Agent (providing it has PrePaid
Capabilities) to assume responsibilities for metering the service. Capabilities) to assume responsibilities for metering the service.
The procedure for this scenario will be given in the next release of The procedure for this scenario will be given in the next release of
this draft. this draft.
4.8 Accounting Considerations 4.8 Operation consideration for Multi-Services
This section describes the operation for supporting Prepaid for
multi-services on the same Service Access Device. The operations
for multi-services are very similar to operations for single
service. Message flows illustrating the various interactions are
presented at the end of this document.
A Service Access Device that supports prepaid operations for multi-
services SHOULD set the ôMulti-Services Supportedö bit in the PPAC.
When working with multi-services, we need to differentiate between
the services. A Service-Id attribute is used in the PPAQ(TBD) to
uniquely differentiate between the services. The exact definition
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 Rating-Group-Id is associated with that
Rating-Group. A PPAQ MUST not contain both a Rating-Group-Id and a
Service-Id. A PPAQ that contains neither a Rating-Group-Id or a
Service-Id applies to the ôAccess Serviceö.
4.8.1 Initial Quota Request
When operations with multi-services is desired, the Service Access
Device will request the initial quota for the Service by sending a
PPAQ containing the Service-Id for that Service in an Authorize-Only
Access-Request packet. Similarly, if the Service Access Device
supports Rating-Groups then it may request a prepaid quota for the
Rating-Group by sending a PPAQ containing the Rating-Group-Id. In
both cases the Update-Reason will be set to ôInitial-Requestö.
The Authorize-Only Access-Request packet may contain more than one
PPAQ. The Authorize-Only Access-Request MUST include one or more
attributes that serve to identify the session so that it can be
linked to the original authentication. Which Session Identifier(s)
is included is up to specific deployments. The Authorize-Only
message must contain the Message-Authenticator(80) attribute for
integrity protection of the Authorize-Only Access-Request message.
Upon receiving an Authorize-Only Access-Accept message containing
one or more PPAQs the Prepaid System will allocate resources to each
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
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 applies to the ôAccess Serviceö.
4.8.2 Quota Update
Once the services start to utilize their allotted quota they will
eventually need to replenish their quotas (either the threshold is
reached or no more quota remains). To replenish the quota the
Prepaid Client will send an Authorize-Only Access-Request message
containing one or more PPAQs. Each PPAQ MUST contain the
appropriate QID, Service-ID or Group-ID (or neither the Service-ID
or Group-Id if the quota replenishment is for the ôAccess Serviceö).
The Update-Reason filed will indicate either ôThreshold reachedö(3),
or ôQuota reachedö(4). The Authorize-Only message must contain
identifiers to identify the session.
Upon receiving an Authorize-Only Access-Request packet with one or
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-
Group-Id, a new Quota. If the Prepaid Server does not want to grant
additional quota to the Service it MUST include the Termination-
Action subfield in the PPAQ that will instruct the Service Access
Device what to do with the service.
4.8.3 Termination
When an allotted quota for the service is used up the Service Access
Device shall act in accordance to the Termination-Action field set
in the Quota. If the Termination-Action field is absent then the
Service MUST be terminated.
If the Service is to be terminated then the Service Access Device
shall send a PPAQ with the appropriate QID, the Service-Id, the used
quota, and Update-Reason set to ôClient Service Terminationö.
If the ôAccess Serviceö has terminated, then all other services must
be terminated as well. In this case the Service Access Device must
report on all issued quotas for the various services. The Update-
Reason field should be set to ôAccess Service Terminatedö.
Note when sending more then on PPAQ it may be required to send
multiple Authorize Only Access-Requests.
4.8.4 Dynamic Operations
Dynamic operations for multi-services are similar to dynamic
operations described for single service operations. The prepaid
system may send a COA message containing a PPAQ for an existing
service instance. The Service Access Device will match the PPAQ to
the service using the Service-ID attribute. The new quota could be
higher then the last allocated value or it could be lower. The
Service Access Device must react to the new quota accordingly.
A Disconnect message may not be send for a specific service. A
disconnect message terminates the ôAccess Serviceö. As such the
Service Access Device must report back all unused quotas by sending
an Authorize Only Access Request message containing a PPAQ for each
active service. The Update-Reason shall indicate that the reason
for the update reason.
4.8.5 Support for Resource Pools
If the Prepaid Client supports pools as indicated by setting the
ô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-
Multiplier in the PPAQ(TBD).
When Resource Pools are used, the PPAQ must not use the threshold
field.
4.8.6 Error Handling
If the Prepaid Server receives a PPAQ with an invalid QID it MUST
ignore that PPAQ.
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
PPAQ.
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
PPAQ.
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
must ignore that PPAQ.
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.
RADIUS Extensions for PrePaid February 2004
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.9 Service Device Operation 4.10 Service Access Device Operation
To be completed To be completed
4.10 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 Service Access Device are RADIUS based; or Diameter based and the Service Access Device are RADIUS based; or
the Service Access Device is Diameter based and the AAA the Service Access Device is Diameter based and the AAA
infrastructure is RADIUS based. 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.
skipping to change at page 30, line 5 skipping to change at page 34, line 26
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.
RADIUS Extensions for PrePaid February 2004
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) | | AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | SelectedForSession (SFS) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE : value of PPAC TYPE : value of PPAC
LENGTH: 14 LENGTH: 8
VALUE : String VALUE : String
The value MUST be encoded as follows: The value MUST be encoded as follows:
Sub-Type (=1) : Sub-Type for AvailableInClient attribute Sub-Type (=1) : Sub-Type for AvailableInClient attribute
Length : Length of AvailableInClient attribute Length : Length of AvailableInClient attribute
(= 6 octets) (= 6 octets)
AvailableInClient (AiC): AvailableInClient (AiC):
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 PrePaid Accounting for Volume supported 0x00000001 Volume metering supported.
0x00000010 PrePaid Accounting for Duration supported 0x00000002 Duration metering supported.
0x00000011 PrePaid Accounting for Volume and Duration supported 0x00000004 Resource metering supported.
(non concurrently) 0x00000008 Pools supported
Others Reserved, treat like Not Capable of PrePaid 0x00000010 Rating groups supported
Accounting (=0). 0x00000020 Multi-Services supported.
Sub-Type (=2) : Sub-Type for SelectedForSession attribute
Length : Length of SelectedForSession attribute
(= 6 octets)
SelectedForSession (SfS):
RADIUS Extensions for PrePaid February 2004
The optional SelectedForSession Sub-Type, generated by the PrePaid
server, indicates the PrePaid Accounting capability to be used for a
given session. The possible values are:
0x00000000 PrePaid Accounting not used Others Reserved
0x00000001 Usage of PrePaid Accounting for Volume.
(only possible if the AvailableInClient supports
PrePaid Accounting for Volume)
0x00000010 Usage of PrePaid Accounting for Duration.
(only possible if the AvailableInClient supports
PrePaid Accounting for Duration)
0x00000011 Usage of PrePaid Accounting for Volume and Duration
(non concurrent) (only possible if the
AvailableInClient supports PrePaid Accounting for
Volume and duration)
Others Reserved, treat like PrePaid Accounting not used(=0).
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 (rrfc3576) is 0x00000001 Dynamic Authorization Extensions (rfc3576) is
supported. supported.
5.3 PPAQ Attribute 5.3 PPAQ Attribute
RADIUS Extensions for PrePaid February 2004 One or more PPAQ(TBD) attributes are available to be sent in
Authorize Only Access-Request and Access-Accept messages. In
Authorize Only Access-Request messages it is used to report usage
and request further quota or request prepaid quota for a new service
instance; in an Access-Accept message it is used to allocate the
quotas (initial quota and subsequent quotas).
The PPAQ(TBD) attribute is sent in Authorize Only Access-Request and When concurrent service are supported a PPAQ is associated with a
Access-Accept messages. In Authorize Only Access-Request messages specific service as indicated by the presence of Service-Id; or a
it is used to report usage and request further quota; in an Access- Rating Group, as indicated by the presence of a Rating-Group-Id; or
Accept message it is used to allocate the quota (initial quota and the ôAccess Serviceö as indicated by the absence of a Service-Id or
subsequent quotas). 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) |
skipping to change at page 32, line 45 skipping to change at page 37, line 4
| DurationQuota (DQ) | SUB-TYPE 7 | LENGTH | | DurationQuota (DQ) | SUB-TYPE 7 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DurationThreshold (DT) | | DurationThreshold (DT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) | | SUB-TYPE 8 | LENGTH | Update-Reason attribute (UR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 9 | LENGTH | PrePaidServer | | SUB-TYPE 9 | LENGTH | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrePaidServer | | PrePaidServer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of PPAQ Type : Value of PPAQ
Length: variable, greater than 8 Length: variable, greater than 8
RADIUS Extensions for PrePaid February 2004
String: The String value MUST be encoded as follows: String: The String value MUST be encoded as follows:
Sub-Type (=1): Sub-Type for QuotaIDentifier attribute Sub-Type (=1): Sub-Type for QuotaIDentifier attribute
Length : Length of QuotaIDentifier attribute (= 6 octets) Length : Length of QuotaIDentifier attribute (= 6 octets)
QuotaIDentifier (QID): QuotaIDentifier (QID):
The QuotaIDentifier Sub-Type is generated by the PrePaid server The QuotaIDentifier Sub-Type is generated by the PrePaid server
at allocation of a Volume and/or Duration Quota. The on-line at allocation of a Volume and/or Duration Quota. The on-line
quota update RADIUS Access-Request message sent from the Service quota update RADIUS Access-Request message sent from the Service
skipping to change at page 34, line 4 skipping to change at page 38, line 7
many times the VolumeQuota counter has wrapped around 2^32 over many times the VolumeQuota counter has wrapped around 2^32 over
the course of the service being provided. the course of the service being provided.
Sub-Type (=4): Sub-Type for VolumeThreshold attribute Sub-Type (=4): Sub-Type for VolumeThreshold attribute
Length : length of VolumeThreshold attribute (= 6 octets) Length : length of VolumeThreshold attribute (= 6 octets)
VolumeThreshold (VT): VolumeThreshold (VT):
The VolumeThreshold Sub-Type shall always be present if The VolumeThreshold Sub-Type shall always be present if
VolumeQuota is present in a RADIUS Access-Accept message (PPS to VolumeQuota is present in a RADIUS Access-Accept message (PPS to
RADIUS Extensions for PrePaid February 2004
Service Access Device direction). It is generated by the PrePaid Service Access Device direction). It is generated by the PrePaid
server and indicates the volume (in octets) that shall be used server and indicates the volume (in octets) that shall be used
before requesting quota update. This threshold should not be before requesting quota update. This threshold should not be
larger than the VolumeQuota. larger than the VolumeQuota.
Sub-Type (=5): Sub-Type for VolumeThresholdOverflow Sub-Type (=5): Sub-Type for VolumeThresholdOverflow
Length : Length of VolumeThresholdOverflow attribute Length : Length of VolumeThresholdOverflow attribute
(= 4 octets) (= 4 octets)
VolumeThresholdOverflow (VTO): VolumeThresholdOverflow (VTO):
skipping to change at page 35, line 5 skipping to change at page 39, line 8
The DurationThreshold Sub-Type shall always be present if The DurationThreshold Sub-Type shall always be present if
DurationQuota is present in a RADIUS Access-Accept message (PPS DurationQuota is present in a RADIUS Access-Accept message (PPS
to Service Access Device direction). It represents the duration to Service Access Device direction). It represents the duration
(in seconds) that shall be used by the session before requesting (in seconds) that shall be used by the session before requesting
quota update. This threshold should not be larger than the quota update. This threshold should not be larger than the
DurationQuota and shall always be sent with the DurationQuota. DurationQuota and shall always be sent with the DurationQuota.
Sub-Type (=8): Sub-Type for Update-Reason attribute Sub-Type (=8): Sub-Type for Update-Reason attribute
Length : length of Update-Reason attribute (= 4 octets) Length : length of Update-Reason attribute (= 4 octets)
RADIUS Extensions for PrePaid February 2004
Update-Reason attribute (UR): Update-Reason attribute (UR):
The Update-Reason Sub-Type shall be present in the on-line RADIUS The Update-Reason Sub-Type shall be present in the on-line RADIUS
Access-Request message (Service Access Device to PPS direction). Access-Request message (Service Access Device to PPS direction).
It indicates the reason for initiating the on-line quota update It indicates the reason for initiating the on-line quota update
operation. Update reasons 4, 5, 6, 7 and 8 indicate that the operation. Update reasons 4, 5, 6, 7 and 8 indicate that the
associated resources are released at the client side, and associated resources are released at the client side, and
therefore the PPS shall not allocate a new quota in the RADIUS therefore the PPS shall not allocate a new quota in the RADIUS
Access_Accept message. 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. Main SI released 7. ôAccess Serviceö Terminated
8. Service Instance not established 8. Service not established
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
the serving PrePaid System. If present, the Home RADIUS server the serving PrePaid System. If present, the Home RADIUS server
uses this address to route the message to the serving PrePaid uses this address to route the message to the serving PrePaid
Server. The attribute may be sent by the Home RADIUS server. If Server. The attribute may be sent by the Home RADIUS server. If
present in the incoming RADIUS Access-Accept message, the PDSN present in the incoming RADIUS Access-Accept message, the PDSN
shall send this attribute back without modifying it in the shall send this attribute back without modifying it in the
subsequent RADIUS Access-Request message, except for the first subsequent RADIUS Access-Request message, except for the first
one. If multiple values are present, the PDSN shall not change one. If multiple values are present, the PDSN shall not change
the order of the attributes. the order of the attributes.
Sub-Type (=10) : Sub-Type for Service ID
Length : Length of Service ID
Service-Id:
Opaque string that uniquely describes a service instance for which
we want to apply prepaid metering to. A Service-Id could be an IP
5-tuple (source address, source port, destination address,
destination port, protocol). If Service-ID is present in the PPAQ
the PPAQ applies to that Service. If a PPAQ does not contain a
Service-Id then the PPAQ applies to the Access Service.
Sub-Type (=11) : Sub-Type for Rating-Group-Id
Length : 6
Rating-Group-Id
Identifies that this PPAQ is associated with resources allocated
to a Rating Group with the corresponding ID.
Sub-Type (=12) : Sub-Type for Termination-Action
Length : 6
This field is an enumeration of the action to take when the prepaid
server does not grant additional quota. Valid actions are as
follows:
0 Reserved
1 Terminate
2 Request More Quota
3 Redirect/Filter
Sub-Type (=13) : Pool-Id
Length : 6
Identifies the Pool that this quota is to be associated with.
Sub-Type (=14) : Pool-Multiplier
Length : 6
The pool-multiplier determines the weight that resources are
inserted into the pool and the rate at which resources are taken out
of the pool by this Service, or Rating-Group.
NOTES: NOTES:
Either Volume-Quota or Time-Quota MUST appear in the attribute. Either Volume-Quota or Time-Quota MUST appear in the attribute.
Volume Threshold may only appear if Volume Quota appears Volume Threshold may only appear if Volume Quota appears
If the Service Access Device can measure time, and if Time-Threshold
appears with Volume Quota, then the Service Access Device should
trigger a quota replenishment when the Current Time >= Time-
Threshold.
RADIUS Extensions for PrePaid February 2004 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
applies to the ôAccess Serviceö.
When the PPAQ contains a Pool-Id it MUST also contain the Pool-
Multiplier.
5.4 Table of Attributes 5.4 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
skipping to change at page 37, line 5 skipping to change at page 42, line 9
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
To be completed. To be completed.
RADIUS Extensions for PrePaid February 2004
This draft does create RADIUS attributes. However, the authors This draft does create RADIUS attributes. However, the authors
recognize that it may not be possible to obtain such attributes. recognize that it may not be possible to obtain such attributes.
Therefore, in subsequent drafts it will be proposed to use a Vendor Therefore, in subsequent drafts it will be proposed to use a Vendor
space as an Application Space. space as an Application Space.
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
skipping to change at page 37, line 40 skipping to change at page 42, line 42
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.
[DIAMETERCC] Work in Progress. [DIAMETERCC] Work in Progress.
[REDIRECT] RADIUS Redirection Internet Draft. Work in progress. [REDIRECT] RADIUS Redirection Internet Draft. Work in progress.
RFC 2284 EAP RFC 2284 EAP
Acknowledgments 9. Call Flows
This section includes call flows illustrating various scenarios
enabled by this specification.
The following are used in the call flows:
The authors would like to thank Mark Grayson, Nagi Jonnala and Joel RADIUS packets:
Halpern, for their contribution to this draft.
RADIUS Extensions for PrePaid February 2004 AR Access Request
ARA Access Accept
AC Accounting Requests
A Authorize-Only Access-Request
AA Access-Accept for Authorize-
Only Access-Request
RADIUS Attributes:
PPAQ PPAQ as defined in this
specification
SID One or more attributes
representing the Session that
the RADIUS packets is correlated
to.
PPAC PPAC as defined in this
specification
ASID Acct-Session-Id as defined by
RADIUS
MSID Acct-Multi-Session-Id as define
by RADIUS
PPAQ fields:
SRVID Service-Id
Reason Update-Reason
QID Quota-Id
9.1 Simple Concurrent Services
In this scenario the Prepaid Client authenticates and authorizes the
user. The Prepaid Server responds back with Prepaid Quota for the
ôAccess Serviceö instance. The NAS then request quota for Service-
A.
Accounting is turned on.
NAS/ RADIUS/
PPC PPS
=== ===
| |
| AR{SID,PPAC} |
A |-------------------------------------------------->|
| |
| ARA{SID,PPAQ(QID=1,Q=100)} |
B |<--------------------------------------------------|
| |
| AC(start){ASID=25,MSID=13} |
C |-------------------------------------------------->|
| |
| A{SID,PPAQ(SRVID=SA, Reason=Initial} |
D |-------------------------------------------------->|
| |
| AA{SID,PPAQ(QID=200,SRVID=SA, Q=50)} |
E |<--------------------------------------------------|
| |
| AC(start){ASID=30,MSID=13, PPAQ } |
F |-------------------------------------------------->|
| |
| A{SID, PPAQ(QID=200 SRVID=SA, Q=50 Reason=Quota)}|
G |-------------------------------------------------->|
| |
| AA{SID,PPAQ(QID=300,SRVID=SA, Q=100)} |
H |<--------------------------------------------------|
| |
| A{SID, |
| PPAQ(QID=1, Q=100 Reason=Quota), |
| PPAQ(QID=300, SRVID=SA Q=100 Reason=Quota)} |
I |-------------------------------------------------->|
| |
| AA{SID,
| PPAQ(QID=3, Q=200), |
| PPAQ(QID=303, SRVID=SA Q=150)} |
J |<--------------------------------------------------|
A This is the initial Access-Request that indicates the Prepaid
Capabilities of the NAS. In this scenario it will indicate
that Concurrent Session are supported. Access-Request also
includes SID (Session Id) which is the Session Identifier
assigned by this NAS to session. Session Identifier is out of
scope in this document. It can be a single attribute such as
3GPP2 Correlation ID or it could be a set of attributes that
define a session.
B RADIUS authenticates the user and determines that the user is
prepaid. RADIUS responds with a PPAQ for the ôAccess Serviceö
(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
Q=100. The quota could be time or volume and may or may not
have a threshold associated with it.
C NAS starts the Access Service and generates an Accounting-
Request (Start) message as normal. It will include the Acct-
Session-Id and may include the Acct-Multi-Session-Id.
D The NAS wants to start a new Service, call it Service-A. It
sends an Authorize-Only access request to RADIUS. The SID
links this Authorize-Only access request to the initial
Authentication & Authorization (Step-A and Step-B).The
Authorize-Only message contains a PPAQ requesting quota for
Service-A, Update-Reason = Initial-Request.
E PPS checks the resources available to the user and assigns 50
units (time/volume etc) to this service. RADIUS sends an
Access Accept message contain a PPAQ assigning quota Q=50 for
Service-A. The PPAQ contains a QID = 200.
F NAS starts Service-A and sends an Accounting-Request (Start)
message for that service. Acct-Multi-Session-Id can be used
to tie all of the sessions in the accounting streams together.
G Quota for Service-A requires refreshing, the quota was
completely used). An Authorize-Only message is sent
containing a PPAQ with QID = 200 which corresponds to the
prior QID received for this service. Note QID is sufficient
for the PPS server to link this request to the previous
request and hence to the original authentication steps.
Therefore SID is not really required. The PPAQ will report the
used part of the quota (50 units).
H RADIUS deducts the used quota from the users accounts and
reserves 50 more additional units for a total quota of 100
(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.
It sends an Authorize Only message contain two PPAQs, one for
the Main Service with QID=1 and one for Service-A with
QID=300. Each PPAQ reports the used resources so far and the
reason why the update is being sent.
J RADIUS responds back with two PPAQs. The PPAQ without the
Service-Id grants an additional 100 units for a total of 200
units to the ôAccess Serviceö û QID=3; the other PPAQ,
containing SRVID=SA grants an additional 50 units for a total
quota to service-a of 150 units û QID=303.
This step illustrates why SRVID needs to be specified in the
PPAQ. If it were not, then the NAS would not be able to
differentiate between the PPAQs. QIDs are not sufficient to
correlate the PPAQ to a service since they are changed (and
not necessarily sequentially) by the PPS at every transaction.
In this scenario, notice how each PPAQ attribute represents a
sequential conversation about a service between the Prepaid Client
and the Prepaid Server. The links between the messages are the QIDs
and the Service-Ids.
As well, notice how a SID is needed to tie the Authorize-Only
messages to the Authentication steps. This SID is only really
needed the first time a PPAQ is sent û since the PPAQ does not have
a QID.
Accounting messages have an Accounting-Session-ID. But that is not
enough to allow the back end system to associate that accounting
message with a particular Service. We therefore need the PPAQ in
the accounting message.
Acknowledgments
The authors would like to thank Mark Grayson (Cisco) and Nagi
Jonnala 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
skipping to change at page 39, line 4 skipping to change at page 47, line 39
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.
RADIUS Extensions for PrePaid February 2004
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 (2004). 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-
04.txt, and will expire 14 January, 2005. 05.txt, and will expire 17 January, 2005.
 End of changes. 83 change blocks. 
344 lines changed or deleted 638 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/