< draft-lior-radius-prepaid-extensions-01.txt		draft-lior-radius-prepaid-extensions-02.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-01.txt Cisco		draft-lior-radius-prepaid-extensions-02.txt Cisco
	Expires: 30 December 2003 K. Chowdhury		Expires: 27 March, 2004 K. Chowdhury
	Nortel		Nortel
	L. Madour		L. Madour
	Ericsson Canada		Ericsson Canada
	Y. Li		Y. Li
	Bridgewater Systems		Bridgewater Systems
	June 30, 2003		October 27, 2003
	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
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of [RFC2026].		all provisions of Section 10 of [RFC2026].
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	Abstract		Abstract
	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...................................................3		1. Introduction...................................................4
	1.1 Terminology................................................4		1.1 Terminology................................................6
	1.2 Requirements language......................................4		1.2 Requirements language......................................6
	2. Use-cases......................................................4		2. Architectural Model............................................6
	2.1 Simple use-case............................................5		3. Use-cases.....................................................14
	2.2 Quota Recovery.............................................6		3.1 Simple pre-paid access use-case...........................15
	2.3 Support for concurrent PrePaid sessions....................7		3.2 Simple Service Device use-case............................17
	2.4 Support for Roaming........................................7		3.3 Support for concurrent PrePaid sessions...................18
	2.5 PrePaid termination........................................8		3.4 Support for Roaming.......................................19
	3. Architecture...................................................8		3.5 PrePaid termination.......................................19
	4. Operations....................................................12		4. Operations....................................................20
	4.1 General Requirements......................................12		4.1 General Requirements......................................20
	4.1.1 Broker AAA Requirements..............................12		4.1.1 Broker AAA Requirements..............................20
	4.2 Authentication and Authorization..........................12		4.2 Authentication and Authorization for Prepaid Enabled Access
	4.3 Session Start Operation...................................15		Devices.......................................................20
	4.4 Mid-Session Operation.....................................15		4.2.1 Single Service Pre-paid..............................22
	4.5 Dynamic Operations........................................17		4.2.2 Multiple-Session Pre-paid............................23
	4.5.1 Unsolicited Session Termination Operation............17		4.3 Session Start Operation...................................24
	4.5.2 Unsolicited Change of Authorization Operation........18		4.4 Mid-Session Operation.....................................25
	4.6 Termination Operation.....................................19		4.5 Dynamic Operations........................................27
	4.7 Mobile IP Operations......................................20		4.5.1 Unsolicited Session Termination Operation............27
	4.8 Accounting Considerations.................................20		4.5.2 Unsolicited Change of Authorization Operation........28
	4.9 Interoperability with Diameter............................21		4.6 Termination Operation.....................................29
	5. Attributes....................................................21		4.7 Mobile IP Operations......................................30
	5.1 PPCC attribute............................................21		4.8 Accounting Considerations.................................30
	5.2 Dynamic-Capabilities attribute............................22		4.9 Service Device Operation..................................31
	5.3 PPAQ Attribute............................................23		4.10 Interoperability with Diameter Credit Control Application31
	5.4 Table of Attributes.......................................26		5. Attributes....................................................31
	6. Security Considerations.......................................26		5.1 PPCC attribute............................................32
	6.1 Authentication and Authorization..........................26		5.2 Dynamic-Capabilities attribute............................33
	6.2 Replenishing Procedure....................................27		5.3 PPAQ Attribute............................................33
	7. IANA Considerations...........................................27		5.4 Tarrif Switch.............................................36
	8. Normative References..........................................27		5.5 Table of Attributes.......................................36
	Acknowledgments..................................................28		6. Security Considerations.......................................36
	Author's Addresses...............................................28		6.1 Authentication and Authorization..........................37
	Intellectual Property Statement..................................28		6.2 Replenishing Procedure....................................37
	Full Copyright Statement.........................................29		7. IANA Considerations...........................................37
	Expiration Date..................................................29		8. Normative References..........................................37
			Acknowledgments..................................................38
			Author's Addresses...............................................38
			Intellectual Property Statement..................................39
			Full Copyright Statement.........................................39
			Expiration Date..................................................40
	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 deliver a data service for either a period		purchases a contract to deliver a data service for either a period
	of time, or a quantity of data. The subscriber purchases the Data		of time, or a quantity of data. Before providing a prepaid data
	Service using various means such as buying a PrePaid Card, or		service, the service provider checks that the prepaid subscriber has
	online. How the subscriber purchases his PrePaid Data Service		sufficient funds to cover the particular service request. Only after
	depends on the deployment and is not in scope for this document.		confirmation that funds are available is the service provided to the
			user.
			The subscriber purchases the Data Service using various means such
			as buying a PrePaid Card, or online. How the subscriber purchases
			their PrePaid Data Service depends on the deployment and is not in
			scope for this document.
	In some deployments, the PrePaid data service will be combined with		In some deployments, the PrePaid data service will be combined with
	a PrePaid voice service. This is not an issue for this document		other Prepaid services such as PrePaid voice service. This is not
	other than the fact that the PrePaid Data Services described in this		an issue for this document other than the fact that the PrePaid Data
	paper should work with other PrePaid data services.		Services described in this paper should work with other PrePaid data
			services.
	The fundamental business driver for a carrier to provide PrePaid		The fundamental business driver for a carrier to provide PrePaid
	data services is to increase participation (subscriber base) and		data services is to increase participation (subscriber base) and
	thus to increase revenues. Therefore, it makes sense that PrePaid		thus to increase revenues. Therefore, it makes sense that PrePaid
	services meet the following goals:		services meet the following goals:
	- Leverage existing infrastructure, hence reducing capital		- Leverage existing infrastructure, hence reducing capital
	expenditures typically required when rolling a new service;		expenditures typically required when rolling a new service;
	- Protect against revenue loss;		- Ability to rate service requests in real-time;
			- Ability to check that the end user’s account for coverage for the
			requested service charge prior to execution of that service;
			- Protect against revenue loss, i.e., prevent an end user from
			generating chargeable events when the credit of that account is
			exhausted or expired;
	- Protect against fraud;		- Protect against fraud;
	- Be as widely deployable over Dialup, Wireless and WLAN networks.		- Be as widely deployable over Dialup, Wireless and WLAN networks.
	The protocol described in this document maximizes existing		The protocol described in this document maximizes existing
	infrastructure as much as possible û hence the use of the RADIUS		infrastructure as much as possible – hence the use of the RADIUS
	protocol. The protocol is used in ways to protect against revenue		protocol. The protocol is used in ways to protect against revenue
	loss or revenue leakage. This is achieved by allocating small		loss or revenue leakage. This is achieved by defining procedures
	quotas to each data session and having the ability to update the		for the real-time delivery of service information to a pre-paid
	quotas dynamically during the lifetime of the PrePaid data session.		enabled AAA server, to minimize the financial risk, for the pre-paid
	As well, mechanisms have been designed to be able to recover from		enabled AAA server to be able to allocate small quotas to each data
	errors that occur from time to time.		session and having the ability to update the quotas from a central
			quota server dynamically during the lifetime of the PrePaid data
			session. As well, mechanisms have been designed to be able to
			recover from errors that occur from time to time.
	Protection against fraud is provided by recording of accounting		Protection against fraud is provided by recording of accounting
	records, by providing mechanisms to thwart replay attacks. As well,		records, by providing mechanisms to thwart replay attacks. As well,
	mechanisms have been provided to terminate data sessions when fraud		mechanisms have been provided to terminate data sessions when fraud
	is detected.		is detected.
	PrePaid System will become more prevalent and sophisticated as the		PrePaid System will become more prevalent and sophisticated as the
	various networks such as Dialup, Wireless and WLAN converge. This		various networks such as Dialup, Wireless and WLAN converge. This
	protocol extension is designed to meet the challenges of converged		protocol extension is designed to meet the challenges of converged
	networks.		networks. The draft mainly addresses how to use the RADIUS protocol
			to achieve a PrePaid Data Service. The prepaid architecture assumes
			that rating of chargeable events does not occur in the element
			providing the service. This rating could be performed in the prepaid
			enabled AAA server or may exist in an entity behind this AAA server.
			Business logic and service rules may define that tariffing of events
			vary in time, e.g., the particular price per megabyte download may
			be defined to switch at 8pm from a high tariff to a low tariff. The
			RADIUS extensions for prepaid support scenarios enable scalable
			implementation of tariff switched prepaid systems.
	The draft mainly addresses how to use the RADIUS protocol to achieve		Furthermore, the prepaid architecture assumes that a quota server is
	a PrePaid Data Service. The details of the PrePaid System, such as		available which, through co-ordination with the rating entity and
	its persistent store, its rating capabilities, how it maintains its		centralized balance manager is able to provide a quota response in
			response for prepaid data service. This quota server functionality
			could be performed in the prepaid enabled AAA server or may exist in
			an entity behind this AAA server. Finally, the details of the
			PrePaid System, such as its persistent store, how it maintains its
	accounts are not covered at all. However, in order to define the		accounts are not covered at all. However, in order to define the
	RADIUS protocol extensions it is necessary to discuss the functional		RADIUS protocol extensions it is necessary to discuss the functional
	behavior of the PrePaid System.		behavior of the PrePaid System.
	1.1 Terminology		1.1 Terminology
	Access Device		Access Device
	PrePaid Client		PrePaid Client
	PrePaid Server		PrePaid Server
	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
	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. Use-cases		2. Architectural Model
			The architectural model supports prepaid clients on either an access
			device or a service device. An access device (e.g. a NAS) typically
			provides a single service to end-users, corresponding to network
			access. The service device enables finer grain services to be
			defined. For example, a service may be defined for access to a
			particular destination network, which enables further segmentation
			of services within the network. An access device and service device
			may be combined into a single physical entity.
			When pre-paid service is used the access or service device collects
			service event information and reports it while and/or after services
			are provided to the prepaid user. This event information is sent to
			a prepaid server by using the prepaid RADIUS extensions.
			If real-time credit control is required, the access or service
			device (prepaid client) contacts the prepaid server with service
			event information included before the service is provided. The
			prepaid server, depending on the service event information, performs
			credit check and allocates a portion of available credit to the
			service event. The rating entity converts this credit value into a
			time and/or volume amount, which is then returned to the requesting
			device. The rating entity may determine that during the allocated
			quota, a tariff switch will occur in which case the rating entity
			will include details of the quota allocated prior to the tariff
			switch, details of the quota allocated after the tariff switch
			together with details of when the tariff switch will occur.
			The requesting device (either access or service device) then
			monitors service execution according to the instructions returned by
			the prepaid server. After service completion or on a subsequent
			request for service, the prepaid server deducts the reserved
			allocation of credit from the prepaid user’s account.
			Similarly, when a user terminates an on-going prepaid service, the
			prepaid client signals the prepaid server with the a value
			corresponding to the unused portion of the allocated quota. The
			prepaid server is then able to refund unused allocated funds into a
			user’s prepaid account.
			There MAY be multiple prepaid servers in the system for reasons of
			redundancy and load balancing. The system MAY also contain separate
			rating server(s) and accounts MAY locate in a centralized database.
			System internal interfaces can exist to relay messages between
			servers and an account manager. However the detailed architecture
			of prepaid system and its interfaces are implementation specific and
			are out of scope of this specification.
			accounting
			+------------+ +-----------+ protocol +--------------+
			| Access |<----->| Service |<------------>| Accounting |
			| Device | +-->| Device |<-----+ | Server |
			+------------+ | +-----------+ | +--------------+
			| |
			+------------+ | |
			| Access |<--+ | +--------------+
			| Device | +------>| PrePaid |
			+------------+ prepaid | Server |
			protocol +--------------+
			Figure 1 Basic Prepaid Architecture
			The prepaid server and accounting server in this architecture model
			are logical entities. The real configuration MAY combine them into a
			single host.
			There MAY exist protocol transparent RADIUS Proxies between prepaid
			client and prepaid server. These proxies transparently support the
			prepaid RADIUS extensions.
			In order to generalize the solution, in this paper we generalize the
			Access Devices, which in reality may be a NAS from in Dialup
			deployments, PDSN in CDMA2000 deployments,an 802.11 WLAN Access
			Points or GGSN in GSM deployments. To actively participate in
			Prepaid procedures outlined here, the Access Device MUST have
			Prepaid Client capabilities. Prepaid Client Capabilities include
			the ability to meter the usage for a prepaid data session; this
			usage includes time or volume usage.
			In circumstances when the Access Device does not support the Prepaid
			client capabilities, prepaid client functionality may be provided
			using either a stand alone service device or, in the case of roaming
			scenarios using mobile IP, the prepaid client functionality may be
			delegated to the Home Agent. It may also be possible to deliver
			limited prepaid services using RADIUS capabilities specified in
			RFC2865 and RFC2866.
			Furthermore, the device including the prepaid client functionality
			may also have Dynamic Session Capabilities that include the ability
			to terminate a data session and/or change the filters associated
			with a specific data session by processing Disconnect Messages and
			Change of Filter messages as per [RFC3576].
			In this document RADIUS is used as the AAA server. There are three
			kinds or categories of AAA servers. The AAA server in the home
			network, the HAAA, is responsible for authentication of the
			subscriber and also authorization of the service. In addition, the
			HAAA communicates with the Prepaid servers using the RADIUS protocol
			to authorize prepaid subscribers. In AAA based roaming deployments
			the AAA server in the visited network, the VAAA, is responsible for
			forwarding the RADIUS messages to the HAAA. The VAAA may also
			modify the messages. In roaming deployments, the visited network
			may be separated from the home network by one or more broker
			networks. The AAA servers in the broker networks, BAAA are
			responsible to route the RADIUS packets and hence don’t play an
			active roll in the Prepaid Data Service delivery.
			In this document the Prepaid Server is described in functional terms
			related to their interface with the HAAA. The Prepaid Server
			interfaces to entities which:
			i) Keep the accounting state of the prepaid subscribers (balance
			manager);
			ii) Allow service requests to be rated in real-time (Rating Engine);
			and
			iii) Allow quota to be managed for a particular pre-paid service
			(Quota Server).
			The various deployments for Prepaid are presented in the remainder
			of this section. The first deployment is the basic Prepaid data
			service and is depicted in figure 2. Here the Access Device which
			supports the prepaid client functionality, the HAAA and the Prepaid
			Server are collocated in the same provider network.
			The Subscriber Device establishes a connection with one of several
			Access Devices in the network. The Access Device communicates with
			one or more HAAA servers in the network. To provide redundancy more
			then one HAAA is available to use by an Access Device.
			The network will have one or more Prepaid Servers. Multiple Prepaid
			Servers will be used to provide redundancy and load sharing. The
			interface between the HAAA and the PPS is the RADIUS protocol in
			this specification. However, in cases where the PPS does not
			implement the RADIUS protocol, the implementation would have to map
			the requirements defined in this document to whatever protocol is
			used between the HAAA and the PPS.
			+------+ +-----+
			| | | |
			+--------+ +--------+ +--| HAAA |--+--| PPS |
			| | | | | | | | | |
			| Sub | | Access | | +------+ | +-----+
			| |---| |--+ |
			| Device | | Device | | +------+ | +-----+
			| | | | | | | | | |
			+--------+ +--------+ +--| HAAA |--+--| PPS |
			| | | |
			+------+ +-----+
			Figure 2 Basic Prepaid Access Architecture
			In the second deployment scenario, the Access Device does not
			support the prepaid client functionality. Instead an independent
			Service Device provides prepaid client functionality as depicted in
			figure 3. Here the Access Device which dose not supports the
			prepaid client functionality is configured as AAA client to the AAA
			proxy functionality in the Service Device. The Service device, which
			supports the prepaid client functionality then appends prepaid
			extensions in the AAA requests proxied to the HAAA.
			The Subscriber Device establishes a connection with one of several
			Access Devices in the network. The Authentication and Authorization
			requests from the Access Device are proxied through the Service
			Device which then appends prepaid extensions on to the requests. The
			Service Device communicates with one or more HAAA servers in the
			network. The Service Device is responsible for removing prepaid
			extensions from messages received from the HAAA before proxying them
			on to the Access Device. To provide redundancy more then one
			Service Devices are available to use by an Access Device and more
			than one HAAA is available for use by the Service Device. The
			Service Device is configured to be default gateway to the Access
			Device, enabling all traffic to be correctly metered.
			(AAA) +---------+ +------+ +-----+
			+------------| Service | | | | |
			+--------+ | | |--+--| HAAA |--+--| PPS |
			| | +--------+ +--| Device | | | | | | |
			| Sub | | Access | (IP)| +---------+ | +------+ | +-----+
			| |---| |-----+ | |
			| Device | | Device | | +---------+ | +------+ | +-----+
			| | +--------+ +--| Service | | | | | | |
			+--------+ | | |--+--| HAAA |--+--| PPS |
			+------------| Device | | | | |
			AAA) +---------+ +------+ +-----+
			Figure 3 Prepaid Service Architecture
			The following figure 4 shows a static roaming prepaid architecture
			that is typical of a wholesale scenario for Dial-Up users or a
			broker scenario used in Dial-Up or WLAN roaming scenarios.
			+----+ +----+ +----+ +-----+
			| | | | | | | |
			+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
			| | | | | | | | | | | | | | | |
			|Sub | |Access| | +----+ | +----+ | +----+ | +-----+
			| |--| |-+ | | |
			|Device| |Device| | +----+ | +----+ | +----+ | +-----+
			| | | | | | | | | | | | | | | |
			+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
			| | | | | | | |
			+----+ +----+ +----+ +-----+
			| Visited | |Broker | | Home |
			| Network | |Network| | Network |
			Figure 4 Static Roaming Prepaid Architecture
			As in the basic prepaid architecture the subscriber’s device
			establishes a connection with the Access Device (NAS, WLAN Access
			Point). The Access Device communicates with the Visiting AAA server
			(VAAA) using the RADIUS protocol. Again for redundancy there maybe
			more then one VAAA. The VAAA communicate using the RADIUS protocol
			with AAA servers in the broker network (BAAA). There maybe more
			then one Broker Network between the Visited Network and the Home
			Network. The Home Network is the same as in the simple
			architecture.
			To support dynamic roaming the network will utilize mobile-ip.
			Figure 5 illustrates a typical mobile-ip deployment. Note that
			typically the mobile device would be moving between networks that
			use the same technology such as Wireless or WLAN. Increasingly,
			device will be able to roam between networks that use different
			technology such as between WLAN and Wireless and Broadband.
			Fortunately, mobile-ip can address this type of roaming and
			therefore we need not be concerned with the underlying network
			technology.
			+------+ +------+ +----+ +----+ +----+ +-----+
			| | | | | | | | | | | |
			|Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS |
			| |--|Device| | | | | | | | |
			|Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+
			| | | | | |
			+------+ +------+ | |
			| | | +----+
			| | | | |
			|ROAMS +------------------+ HA |
			| | | |
			V +----+ | +----+
			+------+ +------+ | | | |
			| | | | +-|VAAA+------+ |
			|Sub | |Access| | | | |
			| |--|Device+-+ +----+ |
			|Device| | (FA) | |
			| | | +------------------------+
			+------+ +------+
			Figure 5 Roaming using mobile-ip and pre-paid enabled Access
			Devices
			In figure 5, the Subscriber device establishes a prepaid session
			between the Access Device in the foreign network, which has prepaid
			capabilities and the Home Agent (HA). The setup for this service is
			identical to the cases covered above. Notice that the Access Device
			is known as the Foreign Agent (FA). As the subscriber device moves
			to another network it establishes a connection with another Access
			Device in another foreign network. The prepaid data service should
			continue to be available. When a device associates to another
			Access Device it MUST re-authenticate at the new Access Device and
			de-associate or logoff the old Access Device. Furthermore, any
			unused quota at the old Access Device MUST be promptly credited back
			to the subscribers account. The reason we say promptly, is because
			if the subscriber is very low on resources to start with, the
			subscriber may not have enough resources to log on to the new Access
			Device. The speed at which resources can be returned depend on the
			type of handoff procedure that is used: dormant handoff vs. active
			handoff vs. fast handoff.
			As well, notice that if the Access Devices could communicate with
			each other then there could be a way to accelerate a faster handoff
			procedure. In particular, it could accelerate the return of the
			unused portion of the quotas from the old Access Device.
			Unfortunately, standards are evolving with each network technology
			creating their own scheme to make the handoff procedures more
			efficient.
			Finally, pre-paid service may be provided in a roaming scenario
			where the Access Devices do not support the prepaid client
			capabilities. In such a scenario, a Service Device is configured as
			AAA proxy to the Home Agent and also as default gateway for the home
			agent, see Figure 6.
			+------+ +------+ +----+ +----+ +----+
			| | | | | | | | | |
			|Sub | |Access+---|VAAA|-|BAAA|----------------| |
			| |-|Device| | | | | | |
			|Device| | (FA) +-+ +----+ +-+--+ (AAA) | |
			| | | | | | +---------+ |HAAA|
			+------+ +------+ | | | | | |
			| | | +----+ +---+ | | +-----+
			| | (IP) | | |(IP)|Ser| | | | |
			|ROAMS +-------------+ HA |----| |--| |--| PPS |
			| | | | |Dev| | | | |
			V +----+ | +----+ +---+ +----+ +-----+
			+------+ +------+ | | | |
			| | | | +-|VAAA+---+ |
			|Sub | |Access| | | | |
			| |-|Device+-+ +----+ |
			|Device| | (FA) | (IP) |
			| | | +-----------------+
			+------+ +------+
			Figure 6 Roaming using mobile-ip and prepaid enabled Service
			Device behind the Home Agent.
			3. Use-cases
	In this section we present a set of use cases that will help		In this section we present a set of use cases that will help
	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 Access Device and not from the UserÆs Device.		experience from the Access Device and not from the User’s Device.
	The connection between the UserÆs Device, which typically involves		The connection between the User’s Device, which typically involves
	setting up a PPP session is specific to a given network technology		setting up a layer 2 session, e.g., PPP session or GPRS PDP Context,
	and the details are not required to deliver a PrePaid service.		is specific to a given network technology and the details are not
			required to deliver a PrePaid service.
	2.1 Simple 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 Access Device sends a RADIUS Access-Request to the AAA system to		The Access Device sends a RADIUS Access-Request to the AAA system to
	authenticate the subscriber, and identify and authorize the service.		authenticate the subscriber, and identify and authorize the service.
	The Access-Request includes the subscriberÆs credentials and may		The Access-Request includes the subscriber’s credentials and may
	include the PrePaid capabilities of the Access Device. PrePaid		include the PrePaid capabilities of the Access Device. PrePaid
	capabilities will be included if the Access Device supports PrePaid		capabilities will be included if the Access Device supports PrePaid
	functionality..		functionality.
	The AAA System proceeds with the authentication procedure. This may		The AAA System proceeds with the authentication procedure. This may
	involve several transactions such as in EAP. Once the subscriber		involve several transactions such as in EAP. Once the subscriber
	has been validated, the AAA system determines that the subscriber is		has been validated, the AAA system determines that the subscriber is
	a PrePaid subscriber and requests that the PrePaid System authorize		a PrePaid subscriber and requests that the PrePaid System authorize
	the PrePaid subscriber. The request may include the PrePaid		the PrePaid subscriber. The request may include the PrePaid
	Capabilities of the serving Access Device.		Capabilities of the serving Access Device. These capabilities will
			include whether the Access Device support optional granular prepaid
			service. Granular prepaid service allows an Access Device to offer
			service differentiation above plain network access, for example
			discriminating between a prepaid service request for access to the
			public Internet from access to a particular application server
			hosted in the private domain of the home provider network. In the
			simple prepaid access scenario, such capabilities are not required
			to be supported by the Access Device.
	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 Access Device has the appropriate PrePaid		validate that the 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 such as, an allocation of a portion of the		includes attributes such as, definition of what services are
	subscriberÆs account called the initial quota (in units of time or		authorized. The exact definition of the service may define vanilla
	volume) and optionally a threshold value.		network access or more granular service definition. The exact
			definition of these services is not the focus of this draft. This
			definition MAY include a “service key” which can be used to
			correlate prepaid requests for access to a service with the service
			definition in the prepaid system. Such service key information MUST
			be included when the prepaid user has subscribed to more than one
			prepaid service. If a user has subscribed to only a single service,
			the response MAY also include an allocation of a portion of the
			subscriber’s account called the initial quota (in units of time or
			volume) and optionally a threshold value. When the rating engine
			has determined that a tariff switch will shortly occur, the initial
			quota may be segmented into that which SHOULD be used before the
			tariff switch, that which SHOULD be used 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.
	In order to support concurrent PrePaid sessions, at any time, the		In order to support concurrent PrePaid sessions, at any time, the
	PrePaid System allocates a portion of the subscribers account to a		PrePaid System allocates a portion of the subscribers account to a
	given PrePaid session. For example, the subscriber may be on a		given PrePaid session. For example, in a multi-service environment
	PrePaid voice call and may also have a concurrent PrePaid data		it might happen that an end user with an already ongoing service
	session. Throughout the lifetime of a session the Access Device		(e.g., browsing the Internet) issues a new service request (e.g.,
	will request quota updates from the PrePaid System.		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
			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 with the service attributes into an Access Response		PrePaid System with the service attributes into an Access Response
	message that it sends back to the Access Device. Note the AAA		message that it sends back to the Access Device. Note the AAA
	System is responsible for authorizing the service whereas the		System is responsible for authorizing the service whereas the
	PrePaid System is responsible for PrePaid authorization.		PrePaid System is responsible for PrePaid authorization.
	Upon receiving the Access Response, the Access Device allows the		Upon receiving the Access Response, the Access Device allows the
	PrePaid data session to start and it starts to meter the session		PrePaid data session to start and it starts to meter the session
	based on time or volume.		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 Access Device will, as instructed		expressed by the threshold), the Access Device will request an
	by the PrePaid System, request an additional quota. The re-		additional quota. The re-authorization for additional quota flows
	authorization for additional quota flows through the AAA system to		through the AAA system to the PrePaid System. The PrePaid System
	the PrePaid System. The PrePaid System revalidates the subscriberÆs		revalidates the subscriber’s account; it will subtract the previous
	account; it will subtract the previous quota allocation from the		quota allocation from the user’s balance and if there is a balance
	userÆs balance and if there is a balance remaining it will		remaining it will reauthorize the request with an additional quota
	reauthorize the request with an additional quota allotment.		allotment. Otherwise, the PrePaid System will reject the request.
	Otherwise, the PrePaid System will reject the request. Note the		Note the replenishing of the quotas is a re-authorization procedure
	replenishing of the quotas is a re-authorization procedure and does		and does not involve re-authentication of the subscriber.
	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 was		session state for the subscriber. This state includes how much was
	allocated during the last quota allocation for a particular session		allocated during the last quota allocation for a particular session
	and how much is left in the account. Therefore, it is required that		and how much is left in the account. Therefore, it is required that
	all subsequent messages about the PrePaid session reach the correct		all subsequent messages about the PrePaid session reach the correct
	PrePaid System.		PrePaid System.
	Upon receiving a re-allotment of the quota, the Access Device will,		Upon receiving a re-allotment of the quota, the Access Device will,
	continue the data service session until the new threshold is		continue the data service session until the new threshold is
	reached. If the Access Device receives a rejection, then it will		reached. If the Access Device receives a rejection, then it will
	let the subscriber use up the remaining quota and then terminate the		let the subscriber use up the remaining quota and then terminate the
	session.		session.
	Alternatively, instead of terminating the session, the Access Device		Alternatively, instead of terminating the session, the Access Device
	may restrict the data session such that the subscriber can only		may restrict the data session such that the subscriber can only
	reach a particular web server. This web server maybe used to allow		reach a particular web server. This web server maybe used to allow
	the subscriber to replenish their account. This restriction can		the subscriber to replenish their account. This restriction can
	also be used to allow new subscribers to purchase a PrePaid Service.		also be used to allow new subscribers to purchase their initial
			PrePaid Service.
	2.2 Quota Recovery		Should the subscriber terminate the session before the session the
	In the above scenario, should the subscriber terminate the session		quota is used up, the remaining balance allotted to the session must
	before the session the quota is used up, the remaining balance		be credited back to the subscriber’s account.
	allotted to the session must be credited 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.
	2.3 Support for concurrent PrePaid sessions		3.2 Simple Service Device use-case
	The subscriber at any given time may initiate more than one session.		When the Access Device does not support the prepaid extensions, an
	To support concurrent sessions the PrePaid System allocates a		operator may still offer prepaid services to subscribers by using a
	portion of the account to any given session at any given time.		service device configured as default IP gateway to the Access
			device.
			A Prepaid subscriber connects to his home network in the usual way.
			The non-prepaid enabled Access Device that is servicing the
			subscriber will use the AAA infrastructure to authenticate and
			authorize the subscriber. The Service device will be configured as
			AAA proxy to the Access Device.
			The Access Device sends an Access Request to the Service Device
			acting as AAA proxy to authenticate the subscriber, and identify and
			authorize the service. The Service Device will proxy the Access
			Request and append its own Prepaid capabilities to the Access
			Request message. These prepaid capabilities are defined identically
			to the simple access device user-case.
			The prepaid system performs functions as with prepaid support in the
			Access Device, e.g., the AAA system incorporates the prepaid
			attributes received from the Prepaid System with the service
			attributes into an Access Response message that it sends back to the
			Service Device. The Service device removes these attributes before
			forwarding the Access Response message to the Access Device.
			Upon receiving the Access Response with allocated quota, the Service
			Device allows the prepaid data service session to start and since it
			is configured as default gateway to the access device, it starts to
			meter the session based on time and/or volume.
			3.3 Support for concurrent PrePaid sessions
			Both prepaid support using Access Devices and prepaid support using
			Service Devices can be configured to support a prepaid multi-service
			environment. In such circumstances, the prepaid client capabilities
			will indicate that the Access or Service Device supports a multi-
			service environment. In such circumstances, instead of returning a
			quota, the prepaid service provides a list of authorized services
			corresponding to a list of service keys to the prepaid client. The
			Access/Service device then uses these service keys to request
			prepaid authorization to the corresponding services. The prepaid
			server responds with an individual quota for the requested service
			key. 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.		Each session is treated independently.
	2.4 Support for Roaming		The method by which a prepaid user activates a service and the
			method for signaling this information to the Access/Service Device
			is out of scope of this draft.
			The method by which a granular service is defined is out of scope of
			this draft. Only service key correlation information is required to
			enable the prepaid server to authorize and rate a particular
			request.
			3.4 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 foreign		Dynamic roaming allows to subscriber to move between foreign
	networks while maintaining a connection with the home network		networks while maintaining a connection with the home network
	seamlessly. As the subscriber moves between networks, the data		seamlessly. As the subscriber moves between networks, the data
	session is handed off between the networks.		session is handed off 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.
	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.
	2.5 PrePaid termination		3.5 PrePaid termination
	When fraud is detected by the PrePaid System, or when an error is		When fraud is detected by the PrePaid System, or when an error is
	detected, it may be beneficial for the PrePaid system to terminate a		detected, it may be beneficial for the PrePaid system to terminate a
	specific session for the subscriber or all the sessions of a		specific session for the subscriber or all the sessions of a
	subscriber.		subscriber.
	Some errors can occur such that the PrePaid System is in a state		Some errors can occur such that the PrePaid System is in a state
	where it is not sure whether the session is in progress or not.		where it is not sure whether the session is in progress or not.
	Under conditions such as this, the PrePaid system may wish to		Under conditions such as this, the PrePaid system may wish to
	terminate the PrePaid data session to make sure that resources are		terminate the PrePaid data session to make sure that resources are
	not being utilized for which it canÆt charge for reliably.		not being utilized for which it can’t charge for reliably.
	Some handoff procedure used during dynamic roaming may require that		Some handoff procedure used during dynamic roaming may require that
	the PrePaid system explicitly terminate the subscribers PrePaid data		the PrePaid system explicitly terminate the subscribers PrePaid data
	session at an Access Device. For example, if time based PrePaid		session at an Access Device. For example, if time based PrePaid
	service is being used and the mobile subscriber performs a dormant		service is being used and the mobile subscriber performs a dormant
	handoff, the PrePaid System needs to explicitly terminate the		handoff, the PrePaid System needs to explicitly terminate the
	PrePaid session at the old Access Device.		PrePaid session at the old Access Device.
	3. Architecture
	A PrePaid Data Service deployment consists of Access Devices, AAA
	servers, and PrePaid Servers. The subscriber device is not
	implicated in the delivery of PrePaid Data Services. In mobile-ip,
	the Home Agent may also be implicated in delivering a PrePaid Data
	Service.
	In order to be have as general a solution as possible, in this paper
	we generalize the Access Devices, which in reality may be a NAS from
	in Dialup deployments, PDSN in CDMA2000 deployments or an 802.11
	WLAN Access Point. To actively participate in PrePaid procedures
	outlined here, the Access Device MUST have PrePaid Client
	capabilities. PrePaid Client Capabilities include the ability to
	meter the usage for a PrePaid data session; this usage includes time
	or volume usage. An exception to this rule is during dynamic
	roaming scenarios, where the Access Device can relegate its PrePaid
	Client Capabilities to the Home Agent (HA). Furthermore, the Access
	Device may also have Dynamic Session Capabilities that include the
	ability to terminate a data session and/or change authorization
	attributes associated with a specific data session by processing
	Disconnect Messages and Change of Authorization messages as per
	[CHIBA].
	In this document the AAA server uses the RADIUS protocol. There are
	three kinds or categories of AAA servers. The AAA server in the
	home network, the HAAA, is responsible for authentication of the
	subscriber and also authorization of the service. In addition, the
	HAAA communicates with the PrePaid servers using the RADIUS protocol
	to authorize PrePaid subscribers. In roaming deployments the AAA
	server in the visited network, the VAAA, is responsible for
	forwarding the RADIUS messages to the HAAA. The VAAA may also
	modify the messages. In roaming deployments, the visited network
	may be separated from the home network by one or more broker
	networks. The AAA servers in the broker networks, BAAA are
	responsible for the routing of the RADIUS message to the HAAA.
	The PrePaid Server is described in functional terms related to itÆs
	interface with the HAAA. The PrePaid Server maintains the
	accounting state of the PrePaid subscribers. As well, the PrePaid
	Server maintains state for each active PrePaid data service session.
	This state includes, allocated quotas, the last known activity
	counters (time or volume) for the PrePaid subscriberÆs data session
	and the servicing Access Device. These counters are continuously
	being updated during the lifetime of the PrePaid data service.
	The various deployments scenarios for PrePaid are presented in the
	remainder of this section. The first deployment is the basic
	PrePaid data service and is depicted in figure 1. Here the Access
	Device and the HAAA and the PrePaid Server are collocated in the
	same operator network.
	The Subscriber Device establishes a connection with one of several
	Access Devices in the network. The Access Device communicates with
	one or more HAAA servers in the network. To provide redundancy more
	then one HAAA is available to use by an Access Device.
	The network will have one or more PrePaid Servers. Multiple PrePaid
	Servers will be used to provide redundancy and load sharing. The
	interface between the HAAA and the PPS is the RADIUS protocol in
	this specification. However, in cases where the PPS does not
	implement the RADIUS protocol, the implementation would have to map
	the requirements defined in this document to whatever protocol is
	used between the HAAA and the PPS.
	+------+ +-----+
	| | | |
	+--------+ +--------+ +--| HAAA |--+--| PPS |
	| | | | | | | | | |
	| Sub | | Access | | +------+ | +-----+
	| |---| |--+ |
	| Device | | Device | | +------+ | +-----+
	| | | | | | | | | |
	+--------+ +--------+ +--| HAAA |--+--| PPS |
	| | | |
	+------+ +-----+
	Figure 1 Basic PrePaid Architecture
	The following figure shows a static roaming PrePaid architecture
	that is typical of a wholesale scenario for Dial-Up users or a
	broker scenario used in Dial-Up or WLAN roaming scenarios.
	+----+ +----+ +----+ +-----+
	| | | | | | | |
	+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
	| | | | | | | | | | | | | | | |
	|Sub | |Access| | +----+ | +----+ | +----+ | +-----+
	| |--| |-+ | | |
	|Device| |Device| | +----+ | +----+ | +----+ | +-----+
	| | | | | | | | | | | | | | | |
	+------+ +------+ +-|VAAA|-+-|BAAA|-+-|HAAA|-+-| PPS |
	| | | | | | | |
	+----+ +----+ +----+ +-----+
	| Visited | |Broker | | Home |
	| Network | |Network| | Network |
	Figure 2 Static Roaming PrePaid Architecture
	As in the basic PrePaid architecture the subscriberÆs device
	establishes a connection with the Access Device (NAS, WLAN Access
	Point). The Access Device communicates with the Visiting AAA server
	(VAAA) using the RADIUS protocol. Again for redundancy there maybe
	more then one VAAA. The VAAA communicate using the RADIUS protocol
	with AAA servers in the broker network (BAAA). There maybe more
	then one Broker Network between the Visited Network and the Home
	Network. The Home Network is the same as in the simple
	architecture.
	To support dynamic roaming the network will most likely utilize
	mobile-ip. Figure 3 illustrates a typical mobile-ip deployment.
	Note that typically the mobile device would be moving between
	networks that use the same technology such as Wireless or WLAN.
	Increasingly, device will be able to roam between networks that use
	different technology such as between WLAN and Wireless and
	Broadband. Fortunately, mobile-ip can address this type of roaming
	and therefore we need not be concerned with the underlying network
	technology.
	+------+ +------+ +----+ +----+ +----+ +-----+
	| | | | | | | | | | | |
	|Sub | |Access+-----|VAAA|--|BAAA|--|HAAA|--| PPS |
	| |--|Device| | | | | | | | |
	|Device| | (FA) +--+ +----+ +-+--+ +----+ +-----+
	| | | | | |
	+------+ +------+ | |
	| | | +----+
	| | | | |
	|ROAMS +------------------+ HA |
	| | | |
	V +----+ | +----+
	+------+ +------+ | | | |
	| | | | +-|VAAA+------+ |
	|Sub | |Access| | | | |
	| |--|Device+-+ +----+ |
	|Device| | (FA) | |
	| | | +------------------------+
	+------+ +------+
	Figure 3 Roaming using mobile-ip
	In the figure 3, the Subscriber device establishes a PrePaid session
	between the Access Device in the foreign network, which has PrePaid
	capabilities and the Home Agent (HA). The setup for this service is
	identical to the cases covered above. Notice that the Access Device
	is known as the Foreign Agent (FA). As the subscriber device moves
	to another network it establishes a connection with another Access
	Device in another foreign network. The PrePaid data service should
	continue to be available. When a device associates to another
	Access Device it MUST re-authenticate at the new Access Device and
	de-associate or logoff the old Access Device. Furthermore, any
	unused quota at the old Access Device MUST be promptly credited back
	to the subscribers account. The reason we say promptly, is because
	if the subscriber is very low on resources to start with, the
	subscriber may not have enough resources to log on to the new Access
	Device. The speed at which resources can be returned depend on the
	type of handoff procedure that is used: dormant handoff vs. active
	handoff vs. fast handoff.
	As well, notice that if the Access Devices could communicate with
	each other then there could be a way to accelerate a faster handoff
	procedure. In particular, it could accelerate the return of the
	unused portion of the quotas from the old Access Device.
	Unfortunately, standards are evolving with each network technology
	creating their own scheme to make the handoff procedures more
	efficient.
	4. Operations		4. Operations
	4.1 General Requirements		4.1 General Requirements
	4.1.1 Broker AAA Requirements		4.1.1 Broker AAA Requirements
	Broker AAA servers MUST support the Message-Authenticator(80)		Broker AAA servers MUST support the Message-Authenticator(80)
	attribute as defined in [RFC2869]. If BAAA servers are used, the		attribute as defined in [RFC2869]. If BAAA servers are used, the
	BAAA servers function is to forward the RADIUS packets as usual to		BAAA servers function is to forward the RADIUS packets as usual to
	the appropriate RADIUS servers.		the appropriate RADIUS servers.
	Accounting messages are not needed to deliver a PrePaid service.		Accounting messages are not needed to deliver a PrePaid service.
	However, accounting messages can be used to keep the PrePaid Server		However, accounting messages can be used to keep the PrePaid Server
	current as to what is happening with the PrePaid data session.		current as to what is happening with the PrePaid data session.
	Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the		Therefore, BAAA SHOULD deliver RADIUS Accounting messages using the
	pass through mode described in [RFC2866].		pass through mode described in [RFC2866].
	4.2 Authentication and Authorization		4.2 Authentication and Authorization for Prepaid Enabled Access Devices
	The Access Device initiates the authentication and authorization		The Access Device initiates the authentication and authorization
	procedure by sending a RADIUS Access-Request as usual.		procedure by sending a RADIUS Access-Request as usual.
	If the Access Device has PrePaid Client capabilities, it MUST		If the Access Device has PrePaid Client capabilities, it MUST
	include the PPCC attribute in the RADIUS Access-Request. The PPCC		include the PPCC attribute in the RADIUS Access-Request. The PPCC
	attribute indicates to the PrePaid server the PrePaid capabilities		attribute indicates to the PrePaid server the PrePaid capabilities
	possessed by the Access Device. These are required in order to		possessed by the Access Device. These are required in order to
	complete the PrePaid authorization procedures.		complete the PrePaid authorization procedures.
			If the Access Device supports multiple sessions-keys capabilities,
			then it SHOULD include the MultiSession-Capabilities attribute. The
			presence of the MultiSession-Capabilities attribute will indicate to
			the PPS that the Access Device support prepaid service
			differentiation above simple prepaid access.
	If the Access Device supports the Disconnect-Message or the Change-		If the Access Device supports the Disconnect-Message or the Change-
	of-Auhtorization capabilities, then it SHOULD include the Dynamic-		of-Auhtorization capabilities, then it SHOULD include the Dynamic-
	Capabilities attribute.		Capabilities attribute.
	In certain deployments, there may be other ways in which to		In certain deployments, there may be other ways in which to
	terminate a data session, or change authorization of an active		terminate a data session, or change authorization of an active
	session. For example, some Access Devices provide a session		session. For example, some Access Devices provide a session
	termination service via Telnet or SNMP. In these cases, the AAA		termination service via Telnet or SNMP. In these cases, the AAA
	server MAY add the Dynamic-Capabilities message to the Access-		server MAY add the Dynamic-Capabilities message to the Access-
	Request.		Request.
	If the authentication procedure involves multiple Access-Requests		If the authentication procedure involves multiple Access-Requests
	(as in EAP), the Access Device MUST include the PPCC attribute and		(as in EAP), the Access Device MUST include the PPCC attribute and
	the Dynamic-Capabilities attribute (if used) in at least the last		the Dynamic-Capabilities attribute (if used) in at least the last
	Access-Request of the authentication procedure.		Access-Request of the authentication procedure.
	The Access-Request will be sent as usual to the HAAA. The packet		The Access-Request will be sent as usual to the HAAA. The packet
	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 not		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
	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 PPCC attribute, the Dynamic-		The Access-Request will contain the PPCC attribute, the Dynamic-
	Capabilities attribute if one was included; the User-Name(1)		Capabilities attribute if one was included; and the MultiSession-
			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
	to the password used between the HAAA and the PrePaid server.		to the password used between the HAAA and the PrePaid server.
	The PrePaid server lookups the subscriberÆs PrePaid account and will		The PrePaid server lookups the subscriber’s PrePaid account and will
	authorize the subscriber taking into consideration the Access Device		authorize the subscriber taking into consideration the Access Device
	PrePaid Client Capabilities.		PrePaid Client Capabilities. The Prepaid Server will decide whether
			single service prepaid access will be provided or a multiple session
			pre-paid access will be provided.
	Upon successful authorization, the PrePaid server will generate an		4.2.1 Single Service Pre-paid
	Access-Accept containing the PPAQ attribute, which contains the
	following sub-attributes:		If a single service prepaid access is provided, upon successful
			authorization, the PrePaid server will generate an Access-Accept
			containing the PPAQ attribute, which contains the following sub-
			attributes:
	- The QUOTA-Id which is set by the PrePaid server to a unique value		- The QUOTA-Id which is set by the PrePaid server to a unique value
	that is used to correlate subsequent quota requests;		that is used to correlate subsequent quota requests;
	- Volume and/or Time Quotas, one of which is set to a value		- Volume and/or Time Quotas, one of which is set to a value
	representing a portion of the subscribers account;		representing a portion of the subscribers account;
	- MAY contain a Time or Volume Threshold that controls when the		- MAY contain a Time or Volume Threshold that controls when the
	Access Device requests additional quota;		Access Device requests additional quota;
	- 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).
			- Optionally, a tariff switch time;
			- Optionally, a Volume and Time Quota which can be used following a
			tariff Switch;
			Note: Idle-Timeout(28) can be used to trigger the premature
			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 or an Access-Accept		PrePaid server will generate an Access-Reject or an Access-Accept
	and set the Filter-Id(11) or the Ascend-Data-Filter (if supported)		and set the Filter-Id(11) or the Ascend-Data-Filter (if supported)
	attribute and the Session-Timeout(27) attribute such that the		attribute and the Session-Timeout(27) attribute such that the
	PrePaid subscriber could get access to a restricted set of locations		PrePaid subscriber could get access to a restricted set of locations
	for a short duration to allow them to replenish their account, or		for a short duration to allow them to replenish their account, or
	create an account; or to browse free content.		create 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
	will append the usual service attributes and forward the packet to		will append the usual service attributes and forward the packet to
	the Access Device. The HAAA SHALL NOT append or overwrite any		the Access Device. The HAAA SHALL NOT append or overwrite any
	attributes already set by the PrePaid server. If the HAAA, receives		attributes already set by the PrePaid server. If the HAAA, receives
	an Access-Reject message, it will simply forward the packet to its		an Access-Reject message, it will simply forward the packet to its
	client. Depending on site policies, if the HAAA fails to receive an		client. Depending on site policies, if the HAAA fails to receive an
	Access-Accept or Access-Reject message from the PrePaid server it		Access-Accept or Access-Reject message from the PrePaid server it
	MAY do nothing or send an Access-Reject or an Access-Accept message		MAY do nothing or send an Access-Reject or an Access-Accept message
	back to its client.		back to its client.
			4.2.2 Multiple-Session Pre-paid
			If the prepaid server decides that multiple-session prepaid service
			is to be provided, upon successful authorization, the Prepaid server
			will generate an Access Accept containing the initial PPQ-Response
			attribute which contains the following sub-attributes:
			- a list of the service keys which the Access Device can subsequently
			use in pre-paid service authorization request.
			The Prepaid Referral the first one is set to the IP address of the
			Serving Prepaid Server, the second one is set to an alternate
			Prepaid Server. This way the HAAA will be able to route subsequent
			packets to the serving Prepaid Server or its alternate.
			Additionally, the Prepaid server MAY set the Terminate-Action(29) to
			RADIUS-Request(1); and MAY set Acct-Interim-Interval(85) to control
			how often interim Accounting Requests are generated.
			Upon receiving the Access Accept from the Prepaid Server, the HAAA
			will append the usual service attributes and forward the packet.
			The HAAA SHALL NOT append any attributes already set by the Prepaid
			server. If the HAAA, receives an Access Reject message, it will
			simply forward the packet to its client. Depending on site
			policies, if the HAAA fails to receive an Access Response message
			from the Prepaid server it MAY do nothing or send an Access Reject
			or an Access Accept message back to its client.
			Upon receiving the Access Accept with a list of service keys, the
			Access Device can trigger the authorization request for a particular
			service corresponding to a service key. The technique for triggering
			an authorization request for a particular service is out of scope of
			this draft.
			The Access Device initiates authorization for a particular service
			by sending a RADIUS Access Request including a single service-key
			reference.
			For the specific service-key reference, the prepaid server will
			check whether funds are available and will, following successful
			allocation of funds, the Prepaid server will generate an Access
			Accept containing the PPQ-Response attribute which contains the
			following sub-attributes:
			- The QUOTA-Id which is set by the Prepaid server to a unique value
			that is used to correlate subsequent quota updates;
			- The ServiceKey-Id which is set by the Prepaid server to the
			service key requested by the Access Device;
			- Volume and Time Quotas, one of which is set to a value
			representing a portion of the subscribers account;
			- The Time of Volume Threshold that the Prepaid server MAY set to
			control when the Access Device requests additional quota.
			- Optionally, a tariff switch time.
			- Optionally, a Volume and Time Quota which can be used following a
			tariff Switch
			Note: Idle-Timeout(28) can be used to trigger the premature
			termination of a pre-paid service following subscriber inactivity.
	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)
			message it will only know that the session has started upon the
			first reception of a quota replenishment operation.
			If the Prepaid server does not receive indication directly (via
			Accounting-Request(start)) or indirectly, it SHOULD after some
			configurable time, deduce that the Session has not started. If the
			Access Device supports termination capabilities, the PPS SHOULD send
			a Disconnect Message to the Access Device to 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 Access Device		During the lifetime of a PrePaid data session the Access Device will
	SHOULD be configured to generate Accounting-Request (Interim) and		request to replenish the quotas using Authorize-Only Access-Request
	will request to replenish the quotas using Authorize Only Access-		messages.
	Request messages.
	Once the allocated quota has been reached or the threshold has been		Once the allocated quota has been reached or the threshold has been
	reached, the Access Device MUST send an Access-Request with Service-		reached, the Access Device MUST send an Access-Request with Service-
	Type(6) set to a value of ôAuthorize Onlyö and the PPAQ attribute.		Type(6) set to a value of “Authorize Only” and the PPAQ attribute.
	The Access Device MUST also include NAS identifiers, and Session		The Access Device MUST also include NAS identifiers, and Session
	identifier attributes in the Authorize Only Access-Request. The		identifier attributes in the Authorize Only Access-Request. The
	Session Identifier should be the same as those used during the		Session Identifier should be the same as those used during the
	Access-Request. For example, if the User-Name(1) attribute was used		Access-Request. For example, if the User-Name(1) attribute was used
	in the Access-Request it MUST be included in the Authorize Only		in the Access-Request it MUST be included in the Authorize Only
	Access-Request especially if the User-Name(1) attribute is used to		Access-Request especially if the User-Name(1) attribute is used to
	route the Access-Request to the Home AAA server.		route the Access-Request to the Home AAA server.
	The Authorize Only Access-Request MUST not include either User		The Authorize Only Access-Request MUST not include either User
	Password or Chap Password. In order to authenticate the message,		Password or Chap Password. In order to authenticate the message,
	the Access Device must include the Message-Authenticator(80)		the Access Device MUST include the Message-Authenticator(80)
	attribute. The Access Device will compute the value for the		attribute. The Access Device will compute the value for the
	Message-Authenticator based on [RFC2869].		Message-Authenticator based on [RFC2869].
	When the HAAA receives the Authorize-Only Access-Request that		When the HAAA receives the Authorize-Only Access-Request that
	contains a PPAQ, it SHALL validate the message using the Message-		contains a PPAQ, it SHALL validate the message using the Message-
	Authenticator(80) as per [RFC2869]. If the HAAA receives an		Authenticator(80) as per [RFC2869]. If the HAAA receives an
	Authorize Only Access-Request that contains a PPAQ but not a		Authorize Only Access-Request that contains a PPAQ but not a
	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 PPAQ		Authorize Only Access-Request message that does not contain a PPAQ
	is either in error or belongs to another application (for example, a		is either in error or belongs to another application (for example, a
	Change of Authorization message [CHIBA]). In this case the		Change of Authorization message [RFC3576]). In this case the
	Authorize Only Access-Request will either be silently discarded or		Authorize Only Access-Request will either be silently discarded or
	handled by another application (not in scope of this document).		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
	Only Access-Request to the PrePaid server specified in the PPAQ.		Only Access-Request to the PrePaid server specified in the PPAQ.
	The HAAA MUST sign the message using the Message-Authenticator(80)		The HAAA MUST sign the message using the Message-Authenticator(80)
	and the procedures in [RFC2869]. As with the Access-Request		and the procedures in [RFC2869]. As with the Access-Request
	message, the HAAA MAY modify the User-Name(1) attribute to a value		message, the HAAA MAY modify the User-Name(1) attribute to a value
	that represents the userÆs internal PrePaid account in the PrePaid		that represents the user’s internal PrePaid account in the PrePaid
	server. Note the PrePaid server could use the Quota-ID sub-		server. Note the PrePaid server could use the Quota-ID sub-
	attribute contained within the PPAQ to locate the user account.		attribute contained within the PPAQ to locate the user account.
	Upon receiving the Authorize Only Access-Request containing a PPAQ		Upon receiving the Authorize Only Access-Request containing a PPAQ
	attribute, the PrePaid server MUST validate the Message-		attribute, the PrePaid server MUST validate the Message-
	Authenticator(80) as prescribed in [RFC2869]. If the message is		Authenticator(80) as prescribed in [RFC2869]. If the message is
	invalid, the PrePaid server MUST silently discard the message. If		invalid, the PrePaid server MUST silently discard the message. If
	it received an Authorize Only Access-Request message that does not		it received an Authorize Only Access-Request message that does not
	contain a PPAQ it MUST silently discard the message.		contain a PPAQ it MUST silently discard the message.
	The PrePaid server will lookup the PrePaid session by using the		The PrePaid server will lookup the PrePaid session by using the
	PrePaid Quota Id contained within the PPAQ. The PrePaid Server		PrePaid Quota Id contained within the PPAQ. The PrePaid Server
	would, take the last allocated quota and subtract that from the		would, take the last allocated quota and subtract that from the
	UserÆs balance. If there is remaining balance, the PrePaid server		User’s balance. If there is remaining balance, the PrePaid server
	re-authorizes the PrePaid session by allocate an additional quota.		re-authorizes the PrePaid session by allocate an additional quota.
	The PrePaid server may want to calculate a different threshold		The PrePaid server may want to calculate a different threshold
	values as well.		values as well.
	Upon successful re-authorization, the PrePaid server will generate		Upon successful re-authorization, the PrePaid server will generate
	an Access-Accept containing the PPAQ attribute. The Access-Accept		an Access-Accept containing the PPAQ attribute. The Access-Accept
	message MAY contain Service-Type(6) set to Authorize-Only and MAY		message MAY contain Service-Type(6) set to Authorize-Only and MAY
	contain the Message-Authenticator(80).		contain the Message-Authenticator(80).
	Depending on site policies, upon unsuccessful authorization, the		Depending on site policies, upon unsuccessful authorization, the
	PrePaid server will generate an Access-Reject or an Access-Accept		PrePaid server will generate an Access-Reject or an Access-Accept
	with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute		with Filter-Id(11) or Ascend-Data-Filter (if supported) attribute
	and the Session-Timeout(27) attribute such that the PrePaid		and the Session-Timeout(27) attribute such that the PrePaid
	subscriber could get access to a restricted set of locations for a		subscriber could get access to a restricted set of locations for a
	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.
	Upon receiving an Access-Accept, the Access Device SHALL update its		Upon receiving an Access-Accept, the Access Device SHALL update its
	quotas and threshold parameters with the values contained in the		quotas and threshold parameters with the values contained in the
	skipping to change at page 17, line 43 ¶		skipping to change at page 28, line 4 ¶
	identified at the Access Device. As a minimum the PrePaid server:		identified at the Access Device. As a minimum the PrePaid 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		4.5.1 Unsolicited Session Termination Operation
			This capability is described in detail in [RFC3576]. The PrePaid
	This capability is described in detail in [CHIBA]. The PrePaid		server sends a Disconnect Request packet that MUST contain
	server send a Disconnect Request packet that MUST contain		identifiers that uniquely identify the subscriber’s data session and
	identifiers that uniquely identify the subscriberÆs data session and		the Access Device servicing that session.
	the Access Device holding that session.
	Upon receiving the Disconnect Request packet the HAAA will either		Upon receiving the Disconnect Request packet the HAAA will either
	act on it or will proxy it to another AAA server until it is		act on it or will proxy it to another AAA server until it is
	received by the a AAA that is in the same network as the serving		received by the a AAA that is in the same network as the serving
	Access Device.		Access Device.
	Each AAA MUST route the Disconnect Request packet. How the routing		Each AAA MUST route the Disconnect Request packet. How the routing
	decision is made is an implementation detail.		decision is made is an implementation detail.
	Once the Disconnect Request packet reaches AAA that is in the same		Once the Disconnect Request packet reaches AAA that is in the same
	network as the serving Access Device, if the Access Device supports		network as the serving Access Device, if the Access Device supports
	Disconnect-Request (as per [CHIBA]), it sends the message directly		Disconnect-Request (as per [RFC3576]), it sends the message directly
	to the Access Device; otherwise it uses other mechanisms such as		to the Access Device; otherwise it uses other mechanisms such as
	SNMP or Telnet to command the Access Device to terminate the		SNMP or Telnet to command the Access Device to terminate the
	session.		session.
	If the Access Device receives a Disconnect-Request packet, it will		If the Access Device receives a Disconnect-Request packet, it will
	respond with either a Disconnect-ACK packet if it was able to		respond with either a Disconnect-ACK packet if it was able to
	terminate the session or else it will respond with a Disconnect-NAK		terminate the session or else it will respond with a Disconnect-NAK
	packet.		packet.
	If the AAA server is performing the disconnect operation, it MUST		If the AAA server is performing the disconnect operation, it MUST
	respond with a Disconnect-ACK message if it successfully terminated		respond with a Disconnect-ACK message if it successfully terminated
	the session or a Disconnect-NAK message if it failed to terminate		the session or a Disconnect-NAK message if it failed to terminate
	the session.		the session.
	If any AAA server is unable to route the Disconnect-Request it MUST		If any AAA server is unable to route the Disconnect-Request it MUST
	respond with a Disconnect-NAK packet.		respond with a Disconnect-NAK packet.
	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		The PrePaid Server MAY send a Change-of-Authorization message as
	described in [CHIBA] to restrict internet access when the subscriber		described in [RFC3576] to restrict internet access when the
	has no more balance.		subscriber has no more balance.
	The PrePaid server sends a Change-of-Authorization packet it MUST		The PrePaid server sends a Change-of-Authorization packet it MUST
	contain identifiers that will uniquely identify the subscriber		contain identifiers that will uniquely identify the subscriber
	session and the Access Device serving that session.		session and the Access Device serving that session.
	Upon receiving the Change-of-Authorization packet the HAAA will		Upon receiving the Change-of-Authorization packet the HAAA will
	either act on it or proxy it to another AAA server until it is		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		received by a AAA server that is in the same network as the serving
	Access Device.		Access Device.
	skipping to change at page 19, line 35 ¶		skipping to change at page 29, line 40 ¶
	If a AAA server was unable to route the Change-of-Authorization it		If a AAA server was unable to route the Change-of-Authorization it
	MUST respond with a Change-of-Authorization-NAK packet.		MUST respond with a Change-of-Authorization-NAK packet.
	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 Access Device		off; the quotas have been consumed, or when the Access Device
	receives a Disconnect Message. In all of these instances, if the		receives a Disconnect Message. In all of these instances, if the
	session is a PrePaid data session, the Access Device will send an		session is a PrePaid data session, the Access Device will send an
	Authorize-Only Access-Request message with a PPAQ Update-Reason		Authorize-Only Access-Request message with a PPAQ Update-Reason
	attribute set to either ôClient Service terminationö or ôRemote		attribute set to either “Client Service termination” or “Remote
	Forced disconnectö and the currently used quota.		Forced disconnect” and the currently used quota.
	The BAAA MUST forward this packet to the next BAAA or the HAAA.		The BAAA MUST forward this packet to the next BAAA or the HAAA.
	The HAAA MUST validate the Authorize Only Access-Request using the		The HAAA MUST validate the Authorize Only Access-Request using the
	Message-Authenticator(80) as per [RFC2869] and if valid, use the		Message-Authenticator(80) as per [RFC2869] and if valid, use the
	PrePaidServer subtype in the PPAQ to forward the Authorize Only		PrePaidServer subtype in the PPAQ to forward the Authorize Only
	Access-Request packet to the serving PrePaid Server or if needed,		Access-Request packet to the serving PrePaid Server or if needed,
	its alternate.		its alternate.
	The PrePaid Server MUST validate the Authorize Only Access Request		The PrePaid Server MUST validate the Authorize Only Access Request
	and use the information contained in the PPAQ attribute to adjust		and use the information contained in the PPAQ attribute to adjust
	the subscriberÆs balance and to close the session. The PrePaid		the subscriber’s balance and to close the session. The PrePaid
	Server SHALL respond back with an Access-Accept message.		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 is		between WLAN and CDMA2000 networks, the PrePaid data session is
	maintained transparently.		maintained transparently.
	As the subscriber device associates with the new Access Device, the		As the subscriber device associates with the new Access Device, the
	skipping to change at page 20, line 32 ¶		skipping to change at page 30, line 34 ¶
	Authentication and Authorization procedure described earlier.		Authentication and Authorization procedure described earlier.
	The Access-Request message is routed to the home network and MUST		The Access-Request message is routed to the home network and MUST
	reach the PrePaid System that is serving the PrePaid session. The		reach the PrePaid System that is serving the PrePaid session. The
	PrePaid system will then correlate the new authorization request		PrePaid system will then correlate the new authorization request
	with the existing active session and will assign a quota to the new		with the existing active session and will assign a quota to the new
	request. Any outstanding quota at the old Access Device will be		request. Any outstanding quota at the old Access Device will be
	returned to the PrePaid system due to the usual mobile-ip handoff		returned to the PrePaid system due to the usual mobile-ip handoff
	procedures. Specifically, the quota will be returned when the		procedures. Specifically, the quota will be returned when the
	Access Device sends the Authorize Only Access-Request with PPAQ		Access Device sends the Authorize Only Access-Request with PPAQ
	Update-Reason subtype set to either ôRemote Forced disconnectö or		Update-Reason subtype set to either “Remote Forced disconnect” or
	ôClient Service terminationö. In order to trigger the sending of		“Client Service termination”. In order to trigger the sending of
	this last Authorize Only Access-Request, the PrePaid system may		this last Authorize Only Access-Request, the PrePaid system may
	issue a Disconnect Message [CHIBA] to the Access Device.		issue a Disconnect Message [CHIBA] to the Access Device.
	If the subscriber has roamed to an Access Device that does not have		If the subscriber has roamed to an Access Device that does not have
	any PrePaid Capabilities, PrePaid data service may still be possible		any PrePaid Capabilities, PrePaid data service may still be possible
	by requesting the Home Agent (providing it has PrePaid Capabilities)		by requesting the Home Agent (providing it has PrePaid Capabilities)
	to assume responsibilities for metering the service. The procedure		to assume responsibilities for metering the service. The procedure
	for this scenario will be given in the next release of this draft.		for this scenario will be given in the next release of this draft.
	4.8 Accounting Considerations		4.8 Accounting Considerations
	skipping to change at page 20, line 44 ¶		skipping to change at page 31, line 4 ¶
	this last Authorize Only Access-Request, the PrePaid system may		this last Authorize Only Access-Request, the PrePaid system may
	issue a Disconnect Message [CHIBA] to the Access Device.		issue a Disconnect Message [CHIBA] to the Access Device.
	If the subscriber has roamed to an Access Device that does not have		If the subscriber has roamed to an Access Device that does not have
	any PrePaid Capabilities, PrePaid data service may still be possible		any PrePaid Capabilities, PrePaid data service may still be possible
	by requesting the Home Agent (providing it has PrePaid Capabilities)		by requesting the Home Agent (providing it has PrePaid Capabilities)
	to assume responsibilities for metering the service. The procedure		to assume responsibilities for metering the service. The procedure
	for this scenario will be given in the next release of this draft.		for this scenario will be given in the next release of this draft.
	4.8 Accounting Considerations		4.8 Accounting Considerations
	Accounting messages are not required to deliver PrePaid Data		Accounting messages are not required to deliver PrePaid Data
	Service. Accounting message will typically be generated for PrePaid		Service. Accounting message will typically be generated for PrePaid
	Data Service. This because accounting message are used for auditing		Data Service. This because accounting message are used for auditing
	purposes as well as for bill generation.		purposes as well as for bill generation.
	Accounting messages associated with PrePaid Data Sessions should		Accounting messages associated with PrePaid Data Sessions should
	include the PPAQ attribute.		include the PPAQ attribute.
	4.9 Interoperability with Diameter		4.9 Service Device Operation
			To be completed
			4.10 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 Access Device are RADIUS based; or the Access		Diameter based and the Access Device are RADIUS based; or the Access
	Device is Diameter based and the AAA infrastructure is RADIUS based.		Device is Diameter based and the AAA infrastructure is RADIUS based.
	The Diameter Credit Control Application [DIAMETERCC] describes how		The Diameter Credit Control Application [DIAMETERCC] describes how
	to implement a PrePaid using an all Diameter based infrastructure.		to implement a PrePaid using an all Diameter based infrastructure.
	<This section to be completed.>		<This section to be completed.>
	5. Attributes		5. Attributes
	As currently written, this draft is using the RADIUS [RFC2865]		As currently written, this draft is using the RADIUS [RFC2865]
	namespace.		namespace.
	Subsequent version will probably be written to use VSAs. However,
	the Vendor Identifier that would be proposed would be PrePaid
	Application.
	Note: as currently written, this draft proposes to use container		Note: as currently written, this draft proposes to use container
	types, or attributes that contain sub-attributes, that will have		types, or attributes that contain sub-attributes, that will have
	attributes from the PrePaid space and also attributes belonging to		attributes from the PrePaid space and also attributes belonging to
	RADIUS space. The technique for encoding such a structure will be		RADIUS space. The technique for encoding such a structure will be
	identified in future release of this document.		identified in future release of this document.
			There has been some discussion on the use of subtypes. The authors
			are open to the concept of “flattening” the attributes. However,
			this will further move this specification away from the 3GPP2
			implementation from which this document is based. Note: that the
			only entities that would decode the attributes would be those that
			implement the prepaid capabilities. As well, the attributes that
			have been subtyped are related to each other semantically and the
			use of a single attribute would not make sense.
	Note: The attributes presented in this version of the draft,		Note: The attributes presented in this version of the draft,
	represent the bare minimum attributes required to implement a		represent the bare minimum attributes required to implement a
	PrePaid solution. The use of the ôAuthorize Onlyö Pattern allows		PrePaid solution. The use of the “Authorize Only” Pattern allows
	the ability to extend PrePaid by adding additional PrePaid VSA in		the ability to extend PrePaid by adding additional PrePaid VSA in
	the future.		the future.
	5.1 PPCC attribute		5.1 PPCC attribute
	The PPCC at tribute is sent in the Access-Request message and is		The PPCC at tribute is sent in the Access-Request message and is
	used to describe the Access Devices PrePaid capabilities. The		used to describe the Access Devices PrePaid capabilities. The
	attribute is encrypted using the procedures defined in [RFC2868 ]		attribute is encrypted using the procedures defined in [RFC2868 ]
	section 3.5.		section 3.5.
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 26, line 19 ¶		skipping to change at page 36, line 27 ¶
	the order of the attributes.		the order of the attributes.
	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 Access Device can measure time, and if Time-Threshold appears		If the Access Device can measure time, and if Time-Threshold appears
	with Volume Quota, then the Access device should trigger a quota		with Volume Quota, then the Access device should trigger a quota
	replenishment when the Current Time >= Time-Threshold.		replenishment when the Current Time >= Time-Threshold.
	5.4 Table of Attributes		5.4 Tarrif Switch
			TBD
			5.5 Table of Attributes
	TO BE COMPLETED.		TO BE COMPLETED.
	Request Accept Reject Challenge # Attribute		Request Accept Reject Challenge # Attribute
	Authorize_Only Request Accept Reject		Authorize_Only Request Accept Reject
	6. Security Considerations		6. Security Considerations
	The protocol exchanges described are susceptible to the same		The protocol exchanges described are susceptible to the same
	skipping to change at page 27, line 40 ¶		skipping to change at page 38, line 9 ¶
	[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June		[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June
	2000.		2000.
	[RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS		[RFC2869] Rigney, C., Willats, W., Calhoun, P., "RADIUS
	Extensions", RFC 2869, June 2000.		Extensions", RFC 2869, June 2000.
	[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,		[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
	Holdrege, M., Goyret, I., "RADIUS Attributes for		Holdrege, M., Goyret, I., "RADIUS Attributes for
	Tunnel Protocol Support" , RFC 2868, June 2000.		Tunnel Protocol Support" , RFC 2868, June 2000.
	[CHIBA] 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)", Internet Draft (work in progress), draft-		(RADIUS)", RFC 3576, February 2003.
	chiba-radius-dynamic-authorization-07.txt, February
	2003.
	[DIAMETERCC] Work in Progress.		[DIAMETERCC] Work in Progress.
	Acknowledgments		Acknowledgments
			The authors would like to thank Mark Grayson (Cisco) for his
			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 29, line 39 ¶		skipping to change at page 40, line 10 ¶
	will not be revoked by the Internet Society or its successors or		will not be revoked by the Internet Society or its successors or
	assigns. This document and the information contained herein is		assigns. This document and the information contained herein is
	provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE		provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
	INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR		INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."
	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-
	01.txt>, and will expire 30th December, 2003.		02.txt, and will expire 27th March, 2004.
End of changes. 67 change blocks.
	316 lines changed or deleted		679 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/