< draft-lior-radius-prepaid-extensions-13.txt   draft-lior-radius-prepaid-extensions-14.txt >
RADEXT A. Lior RADEXT A. Lior
Internet-Draft Bridgewater Systems Internet-Draft Bridgewater Systems
Intended status: Informational P. Yegani Intended status: Informational P. Yegani
Expires: August 28, 2008 Cisco Expires: January 15, 2009 Cisco
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
A. Pashalidis A. Pashalidis
NEC NEC
February 25, 2008 July 14, 2008
Prepaid Extensions to Remote Authentication Dial-In User Service Prepaid Extensions to Remote Authentication Dial-In User Service
(RADIUS) (RADIUS)
draft-lior-radius-prepaid-extensions-13.txt draft-lior-radius-prepaid-extensions-14.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008. This Internet-Draft will expire on January 15, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document specifies an extension to the Remote Authentication This document specifies an extension to the Remote Authentication
Dial-In User Service (RADIUS) protocol that enables service providers Dial-In User Service (RADIUS) protocol that enables service providers
to charge for prepaid services. The supported charging models to charge for prepaid services. The supported charging models
supported are volume-based, duration-based, and based on one-time supported are volume-based, duration-based, and based on one-time
events. events.
Table of Contents Table of Contents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 28 3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 28
3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29
3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 29 3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 29
3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 29 3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 29
3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 30 3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 30
3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 30
3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 30 3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 30
3.8.8. Accounting Considerations . . . . . . . . . . . . . . 31 3.8.8. Accounting Considerations . . . . . . . . . . . . . . 31
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 32 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 32
4.2. Session Termination Attribute . . . . . . . . . . . . . . 33 4.2. Session Termination Capability Attribute . . . . . . . . . 33
4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 33 4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 34
4.4. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 40 4.4. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 52
5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 43 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 56
6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 6. Security Considerations . . . . . . . . . . . . . . . . . . . 57
7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 45 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 58
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59
8.1. New RADIUS Attributes . . . . . . . . . . . . . . . . . . 46 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
8.2. New Registry: Prepaid SubTypes . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.3. New Registry: Update-Reason . . . . . . . . . . . . . . . 48 10.1. Normative References . . . . . . . . . . . . . . . . . . . 64
8.4. New Registry: Termination-Action . . . . . . . . . . . . . 48 10.2. Informative References . . . . . . . . . . . . . . . . . . 64
8.5. New Registry: Requested-Action . . . . . . . . . . . . . . 48 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 66
8.6. New Registry: Check-Balance-Result . . . . . . . . . . . . 49 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 66
8.7. New Registry: AvailableInClient-Extended . . . . . . . . . 49 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 69
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 72
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 77
10.1. Normative References . . . . . . . . . . . . . . . . . . . 51 A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 78
10.2. Informative References . . . . . . . . . . . . . . . . . . 51 A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 79
Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 52
A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 52
A.2. A flow with prepaid tariff switching . . . . . . . . . . . 54
A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 58
A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 63
A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 64
A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Translation between RADIUS Prepaid and Diameter Appendix B. Translation between RADIUS Prepaid and Diameter
Credit Control . . . . . . . . . . . . . . . . . . . 67 Credit Control . . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90
Intellectual Property and Copyright Statements . . . . . . . . . . 77 Intellectual Property and Copyright Statements . . . . . . . . . . 91
1. Introduction 1. Introduction
This document specifies an extension to the RADIUS protocol that This document specifies an extension to the RADIUS protocol that
enables service providers to perform accounting and charging in an enables service providers to perform accounting and charging in an
"online" fashion. In particular, they enable the service provider to "online" fashion. In particular, they enable the service provider to
(a) ensure that subscriber's remaining funds suffice before the (a) ensure that subscriber's remaining funds suffice before the
service is delivered, and service is delivered, and
skipping to change at page 23, line 43 skipping to change at page 23, line 43
premature termination of a prepaid service, for example as a result premature termination of a prepaid service, for example as a result
of inactivity. of inactivity.
Depending on site policies, after failed authorization, the PPS may Depending on site policies, after failed authorization, the PPS may
generate an Access-Reject in order to terminate the session generate an Access-Reject in order to terminate the session
immediately. Alternatively, the PPS may generate an Access-Accept immediately. Alternatively, the PPS may generate an Access-Accept
blocking some or all of the traffic and/or redirect some or all of blocking some or all of the traffic and/or redirect some or all of
the traffic to a location to a fixed server. (This feature could be the traffic to a location to a fixed server. (This feature could be
used, for example, to prompt the user to replenish their account.) used, for example, to prompt the user to replenish their account.)
Blocking of traffic is achieved by either Filter-ID(11) or NAS- Blocking of traffic is achieved by either Filter-ID(11) or NAS-
Filter-Rule (see [I-D.ietf-radext-filter-rules]). A description of Filter-Rule (see [RFC4849]). A description of the redirect
the redirect functionality is outside the scope of this document. functionality is outside the scope of this document. The time period
The time period before the session is blocked/redirected is specified before the session is blocked/redirected is specified by the Session-
by the Session-Timeout(27) attribute. Timeout(27) attribute.
Upon receiving an Access-Accept from the PPS, the HAAA appends the Upon receiving an Access-Accept from the PPS, the HAAA appends the
usual service attributes and forward the packet to the PPC. The HAAA usual service attributes and forward the packet to the PPC. The HAAA
SHOULD NOT overwrite any attributes already set by the PPS. If the SHOULD NOT overwrite any attributes already set by the PPS. If the
HAAA receives an Access-Reject message, it will simply forward the HAAA receives an Access-Reject message, it will simply forward the
packet to its client. Depending on site policies, if the HAAA does packet to its client. Depending on site policies, if the HAAA does
not receive an Access-Accept or an Access-Reject message from the PPS not receive an Access-Accept or an Access-Reject message from the PPS
it MAY do nothing or send an Access-Reject or an Access- Accept it MAY do nothing or send an Access-Reject or an Access- Accept
message back to the PPC. message back to the PPC.
skipping to change at page 26, line 23 skipping to change at page 26, line 23
threshold parameters with the values contained in the PPAQ attribute. threshold parameters with the values contained in the PPAQ attribute.
Note that the PPS MAY update the PrePaidServer attribute(s) and these Note that the PPS MAY update the PrePaidServer attribute(s) and these
may have to be saved as well. If the Access-Accept message contains may have to be saved as well. If the Access-Accept message contains
a Filter-Id(11), an Ascend-Data-Filter attribute, or Session a Filter-Id(11), an Ascend-Data-Filter attribute, or Session
Timeout(27), the PPC SHALL restrict the subscriber session Timeout(27), the PPC SHALL restrict the subscriber session
accordingly. accordingly.
3.5. Dynamic Operations 3.5. Dynamic Operations
The PPS may take advantage of the dynamic capabilities that are The PPS may take advantage of the dynamic capabilities that are
supported by the PPC as advertised in the Dynamic-Capabilities supported by the PPC as advertised in the Session Termination and the
attribute during the initial Access-Request. There are two types of PPAC attribute during the initial Access-Request. There are two
actions that the PPS may perform. Firstly, it may request the types of actions that the PPS may perform. Firstly, it may request
session to be terminated. Secondly, it may request the attributes the session to be terminated. Secondly, it may request the
associated with the session to be modified. More specifically, it attributes associated with the session to be modified. More
may modify a previously sent PPAQ. specifically, it may modify a previously sent PPAQ.
Both of these actions require that the session be uniquely identified Both of these actions require that the session be uniquely identified
at the PPC as described in [RFC3576]. at the PPC as described in [RFC3576].
3.5.1. Unsolicited Session Termination Operation 3.5.1. Unsolicited Session Termination Operation
At anytime during a session the PPS may send a Disconnect Message in At anytime during a session the PPS may send a Disconnect Message in
order to terminate a session, see in [RFC3576]. Upon successful order to terminate a session, see in [RFC3576]. Upon successful
termination of a session the PPC MUST return any unused quota to the termination of a session the PPC MUST return any unused quota to the
PPS by issuing an Authorize-Only Access-Request containing the PPAQ PPS by issuing an Authorize-Only Access-Request containing the PPAQ
skipping to change at page 32, line 18 skipping to change at page 32, line 18
extensions for prepaid. extensions for prepaid.
4.1. PrePaid Accounting Capability (PPAC) Attribute 4.1. PrePaid Accounting Capability (PPAC) Attribute
The PrepaidAccountingCapability (PPAC) attribute is sent in the The PrepaidAccountingCapability (PPAC) attribute is sent in the
Access-Request message by a PPC to describe its prepaid capabilities. Access-Request message by a PPC to describe its prepaid capabilities.
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 | SubType (1) | LENGTH | | TYPE | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient-Extended (AiC-ext) | ... VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE : IANA registered value of PPAC attribute The fields have the following meaning and encoding:
LENGTH: 8
VALUE : Data type String
The value field is encoded as follows: Type:
PPAC (35)
Length:
8
VALUE :
The content of the subsequent fields are encoded using
the data type String.
The AvailableInClient (AiC) SubType is encoding as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | AvailableInClient (AiC) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value (1) SubType : Value (1)
Length : 6 or 10 octets LENGTH : 6
AvailableInClient (AiC): The bitmap is encoded as: AvailableInClient (AiC): The bitmap is encoded as:
Value | Description Value | Description
------------ -+------------------------------------- ------------ -+-------------------------------------
0x00000001 | Volume metering supported 0x00000001 | Volume metering supported
0x00000002 | Duration metering supported 0x00000010 | Duration metering supported
0x00000004 | Resource metering supported 0x00000100 | Resource metering supported
0x00000008 | Pools supported 0x00001000 | Pools supported
0x00000010 | Rating groups supported 0x00010000 | Rating groups supported
0x00000020 | Multi-Services supported 0x00100000 | Multi-Services supported
0x00000040 | Tariff Switch supported 0x01000000 | Tariff Switch supported
Others | Reserved 0x10000000 | Reserved
Figure 8: PPAC Attribute Figure 8: PPAC Attribute
4.2. Session Termination Attribute 4.2. Session Termination Capability Attribute
The value shall be bitmap encoded rather than a raw integer. This The Session Termination Capability attribute is included in the
attribute shall be included RADIUS Access-Request message to the RADIUS Access-Request message towards the RADIUS server to indicate
RADIUS server and indicates whether or not the NAS supports Dynamic whether or not the NAS supports Dynamic Authorization.
Authorization.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | LENGTH | String | | TYPE | LENGTH | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : value of Session Termination Capability The fields have the following meaning and encoding:
Length: = 4
String encoded as follows:
0x00000001 Dynamic Authorization Extensions (rfc3576) is Type:
supported.
Figure 9: Session Termination Attribute Session Termination Capability (36)
Length:
4
String:
This field is encoded as a bitmap.
Value | Description
---------------+-------------------------------------
0x00000001 | Dynamic Authorization Extensions (RFC 3576)
| is supported.
... | All further values are reserved.
Figure 9: Session Termination Capability Attribute
4.3. Prepaid Accounting Operation (PPAQ) Attribute 4.3. Prepaid Accounting Operation (PPAQ) Attribute
One or more PPAQ attributes are sent in an Access Request, Authorize- One or more PPAQ attributes are sent in an Access Request, Authorize-
Only Access-Request and Access-Accept message. In an Access Request Only Access-Request and Access-Accept message. In an Access Request
message, the PPAQ attribute is used to facilitate one-time charging message, the PPAQ attribute is used to facilitate one-time charging
transactions. In Authorize-Only Access-Request messages it is used transactions. In Authorize-Only Access-Request messages it is used
for one-time charging, report usage and to request further quota. It for one-time charging, report usage and to request further quota. It
is also used in order to request prepaid quota for a new service is also used in order to request prepaid quota for a new service
instance. In an Access-Accept message it is used in order to instance. In an Access-Accept message it is used in order to
allocate the (initial and subsequent) quotas. allocate the (initial and subsequent) quotas.
When multiple services are supported, a PPAQ is associated with a When multiple services are supported, a PPAQ is associated with a
specific service as indicated by the presence of a Service-Id, a specific service as indicated by the presence of a Service-Id, a
Rating-Group-Id, or the "Access Service" (as indicated by the absence Rating-Group-Id, or the "Access Service" (as indicated by the absence
of both, the Service-Id and the Rating-Group-Id). of both, the Service-Id and the Rating-Group-Id).
Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes MUST Note: Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes
appear in the PPAQ attribute, except for the price enquiry message MUST appear in the PPAQ attribute, except for the price enquiry
exchange where these subtypes MUST be absent. A single PPAQ message exchange where these subtypes MUST be absent. A single PPAQ
attribute MUST NOT contain more than one Service-Id, MUST NOT contain attribute MUST NOT contain more than one Service-Id, MUST NOT contain
more than one Rating-Group-Id, and MUST NOT contain both a Service-Id more than one Rating-Group-Id, and MUST NOT contain both a Service-Id
and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or and a Rating-Group-Id. A PPAQ that does not contain a Service-ID or
a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT a Rating-Group-Id refers to the "Access Service". A PPAQ MUST NOT
contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST contain more than one Pool-Id. A PPAQ that contains a Pool-Id MUST
also contain a Pool-Multiplier SubType. also contain a Pool-Multiplier SubType.
The PPAQ attribute has a variable length (greater than 8, encoded The PPAQ attribute, as shown in Figure 10, has a variable length
into one octet), and consists of a variable number of subtypes. (greater than 8, encoded into one octet), and consists of a variable
Unused subtypes are omitted from the message. In the following number of subtypes. Unused subtypes are omitted from the message.
subsections the various subtypes of the PPAQ attribute are specified. In the following subsections the various subtypes of the PPAQ
attribute are specified.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
Type:
PPAQ (37)
Length:
variable (dependent on the specific sub-type)
VALUE:
Data type String
Each subattribute is then encoded in the following style:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType :
Contains an 8 bit unsigned integer.
LENGTH :
Contains an 8 bit unsigned integer.
Figure 10: PPAQ Attribute Encoding Style
4.3.1. Quota Identifier (QID) SubType 4.3.1. Quota Identifier (QID) SubType
The value of the type field of the Quota Identifier (QID) SubType is The Quota Identifier (QID) is generated by the PPS and subsequently
TBD. The length of this SubType is 6 octets. Its value is encoded returned in a PPAQ->QID subtype from the PPC to the PPS. This field
as a string. It is generated by the PPS and subsequently returned in has the semantic of a transaction identifier and therefore changes
a PPAQ->QID subtype from the PPC to the PPS. This field has the with every transaction initiated by the PPS to the PPC.
semantic of a transaction identifier and therefore changes with every
transaction initiated by the PPS to the PPC. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(2)
LENGTH : 6
VALUE : Data type String
Quota Identifier (QID) SubType
4.3.2. VolumeQuota SubType 4.3.2. VolumeQuota SubType
The value of the type field of the VolumeQuota SubType is TBD. The TVolumeQuota SubType is only present when volume-based charging is
length of this SubType is 12 or 18 octets. It is only present if used. In a RADIUS Access-Accept message (PPS to PPC direction), it
volume-based charging is used. In a RADIUS Access-Accept message indicates the volume (in octets) allocated for the session by the
(PPS to PPC direction), it indicates the volume (in octets) allocated PPS. In a RADIUS Authorize-Only Access-Request message (PPC to PPS
for the session by the PPS. In an RADIUS Authorize-Only Access- direction), it indicates the totally used volume (in octets) for both
Request message (PPC to PPS direction), it indicates the total used inbound and outbound traffic. The Exponent SubType, if present, MUST
volume (in octets) for both inbound and outbound traffic. The NOT encode a negative number or zero.
attribute consists of a Value-Digits SubType and optionally an
Exponent SubType (as indicated in the length field). The Exponent 0 1 2 3
SubType, if present, MUST NOT encode a negative number or zero. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(3)
LENGTH : variable (8 or 14)
VALUE : Data type String
The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the
Exponent SubType. The length field indicates whether one or
both subtypes are included.
VolumeQuota SubType
4.3.3. VolumeThreshold SubType 4.3.3. VolumeThreshold SubType
The value of the type field of the VolumeThreshold SubType is TBD and The value of the type field of the VolumeThreshold SubType is TBD and
its length is 12 or 18 octets. This SubType is optionally present if its length is 10 or 14 octets. This SubType is optionally present if
VolumeQuota is present in a RADIUS Access-Accept message (PPS to PPC the VolumeQuota is present in a RADIUS Access-Accept message (PPS to
direction). It is generated by the PPS and indicates the volume (in PPC direction). It is generated by the PPS and indicates the volume
octets) that has to be consumed before a new quota is requested. (in octets) that has to be consumed before a new quota is requested.
This threshold MUST NOT be larger than the VolumeQuota. The This threshold MUST NOT be larger than the VolumeQuota. The Exponent
attribute consists of a Value-Digits SubType and optionally an
Exponent SubType (as indicated by the length field). The Exponent
SubType, if present, MUST NOT encode a negative number or zero. SubType, if present, MUST NOT encode a negative number or zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(4)
LENGTH : variable (8 or 14)
VALUE : Data type String
The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the
Exponent SubType. The length field indicates whether one or
both subtypes are included.
VolumeThreshold SubType
4.3.4. DurationQuota SubType 4.3.4. DurationQuota SubType
The value of the type field of the DurationQuota SubType is TBD and The optional DurationQuota SubType is only present if duration-based
its length is 6 octets. This optional SubType is only present if charging is used. In a RADIUS Access-Accept message (PPS to PPC
duration-based charging is used. In a RADIUS Access-Accept message direction), it indicates the duration (in seconds) allocated for the
(PPS to PPC direction), it indicates the duration (in seconds) session by the PPS. In a RADIUS Access-Request message (PPC to PPS
allocated for the session by the PPS. It is encoded as an integer. direction), it indicates the total duration (in seconds) since the
start of the accounting session related to the QID subtype of the
PPAQ attribute in which it occurs.
In a RADIUS Access-Request message (PPC to PPS direction), it 0 1 2 3
indicates the total duration (in seconds) since the start of the 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
accounting session related to the QID subtype of the PPAQ attribute +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
in which it occurs. | SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(5)
LENGTH : 6
VALUE : Data type string.
The content of this field contains a 32-bit unsigned integer
(with the values 0 to +4,294,967,295).
DurationQuota SubType
4.3.5. DurationThreshold SubType 4.3.5. DurationThreshold SubType
The value of the type field of the DurationThreshold SubType is TBD The DurationThreshold SubType is optionally present if the
and its length is 6 octets. This SubType shall optionally be present DurationQuota is present in a RADIUS Access-Accept message (PPS to
if the DurationQuota is present in a RADIUS Access-Accept message PPC direction). It represents the duration (in seconds) after which
(PPS to PPC direction). It represents the duration (in seconds) new quota should be requested. This threshold MUST NOT be larger
after which new quota should be requested. This threshold MUST NOT than the DurationQuota SubType.
be larger than the DurationQuota SubType. It is encoded as an
integer. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(6)
LENGTH : 6
VALUE : Data type string.
The content of this field contains a 32-bit unsigned integer
(with the values 0 to +4,294,967,295).
DurationThreshold SubType
4.3.6. ResourceQuota SubType 4.3.6. ResourceQuota SubType
The value of the type field of the ResourceQuota SubType is TBD. The The optional ResourceQuota SubType is only present if resource-based
length of this SubType is 12 or 18 octets. This optional SubType is or one-time charging is used. In the RADIUS Access-Accept message
only present if resource-based or one-time charging is used. In the (PPS to PPC direction) it indicates the resources allocated for the
RADIUS Access-Accept message (PPS to PPC direction) it indicates the session by the PPS. In RADIUS Authorize-Only Access-Request message
resources allocated for the session by the PPS. In RADIUS Authorize- (PPC to PPS direction), it indicates the resources used in total,
Only Access-Request message (PPC to PPS direction), it indicates the including both incoming and outgoing chargeable traffic. In one-time
resources used in total, including both incoming and outgoing charging scenarios, the subtype represents the number of units to
chargeable traffic. In one-time charging scenarios, the subtype charge the user. The attribute consists of a Value-Digits SubType
represents the number of units to charge or credit the user. The and optionally an Exponent SubType (as indicated by the length
attribute consists of a Value-Digits SubType and optionally an field).
Exponent SubType (as indicated by the length field).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(7)
LENGTH : variable (8 or 14)
VALUE : Data type String
The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the
Exponent SubType. The length field indicates whether one or
both subtypes are included.
ResourceQuota SubType
4.3.7. ResourceThreshold SubType 4.3.7. ResourceThreshold SubType
The value of the type field of the ResourceThreshold SubType is TBD. The semantic of the ResourceThreshold SubType follow those of the
The length of this SubType is 12 or 18 octets. The semantics of this VolumeThreshold and DurationThreshold SubType.
SubType follow those of the VolumeThreshold and DurationThreshold
SubType. It consists of a Value-Digits SubType and optionally an 0 1 2 3
Exponent SubType. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(8)
LENGTH : variable (8 or 14)
VALUE : Data type String
The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the
Exponent SubType. The length field indicates whether one or
both subtypes are included.
ResourceThreshold SubType
4.3.8. Value-Digits SubType 4.3.8. Value-Digits SubType
The value of the type field of the Value-Digits SubType is TBD and The Value-Digits SubType encodes the most significant digits of a
its length is 10 octets. This SubType encodes the most significant number, encoded as an integer. If decimal values are needed to
digits of a number, encoded as an integer. If decimal values are present the number, the scaling MUST be indicated with a related
needed to present the number, the scaling MUST be indicated with a Exponent SubType.
related Exponent SubType. For example, the decimal number 0.05 is
encoded by a Value-Digits SubType set to 5, and a scaling that is For example, the decimal number 0.05 is encoded by a Value-Digits
indicated with the Exponent SubType set to -2. SubType set to 5, and a scaling that is indicated with the Exponent
SubType set to -2.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(9)
LENGTH : 6
VALUE : Data type string.
The content of this field contains a 32-bit unsigned integer
(with the values 0 to +4,294,967,295).
Value-Digits SubType
4.3.9. Exponent SubType 4.3.9. Exponent SubType
The value of the type field of the Exponent SubType is TBD. The The Exponent SubType contains the exponent value that is to be
length of this SubType is 6 octets. This SubType contains the applied to the accompanying Value-Digit SubType.
exponent value that is to be applied to the accompanying Value-Digit
SubType. Its value is encoded as an integer. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(10)
LENGTH : 6
VALUE : Data type string.
The content of this field contains a 32-bit signed integer
(with the values -2,147,483,648 to +2,147,483,647).
Exponent SubType
4.3.10. Update-Reason SubType 4.3.10. Update-Reason SubType
The value of the type field of the Update-Reason SubType is TBD. The The Update-Reason SubType is present in a RADIUS Access-Request
length of this SubType is 4 octets. This SubType is present in a message (PPC to PPS direction) and indicates the reason for
RADIUS Access-Request message (PPC to PPS direction) and indicates initiating the quota update operation. Update reasons (6), (7), (8)
the reason for initiating the quota update operation. Update reasons and (9) indicate that the associated resources are released at the
(6), (7), (8) and (9) indicate that the associated resources are PPC side, and that therefore the PPS MUST NOT allocate a new quota in
released at the PPC side, and that therefore the PPS MUST NOT the RADIUS Access-Accept message.
allocate a new quota in the RADIUS Access Accept message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(11)
LENGTH : 4
VALUE : Data type string
This field contains a 16-bit unsigned integer
(with the values 0 to +65,535).
Update-Reason SubType
The following values for the Update-Reason SubType are defined: The following values for the Update-Reason SubType are defined:
Value | Description Value | Description
-------------+-------------------------------------- -------------+--------------------------------------
0 | Reserved 0 | Reserved
1 | Pre-initialization 1 | Pre-initialization
2 | Initial Request 2 | Initial Request
3 | Threshold Reached 3 | Threshold Reached
4 | Quota Reached 4 | Quota Reached
5 | TITSU Approaching 5 | TITSU Approaching
6 | Remote Forced Disconnect 6 | Remote Forced Disconnect
7 | Client Service Termination 7 | Client Service Termination
8 | "Access Service" Terminated 8 | "Access Service" Terminated
9 | Service not established 9 | Service not established
10 | One-Time Charging 10 | One-Time Charging
11..255 | **Available for IANA registration** 11...65,535 | **Available for IANA registration**
Figure 10: Values for Update-Reason SubType Figure 11: Values for Update-Reason SubType
4.3.11. PrepaidServer SubType 4.3.11. PrepaidServer SubType
The value of the type field of the PrepaidServer SubType is TBD. The The optional PrepaidServer SubType indicates the address of the
length of this SubType is 6 or 18 octets, for IPv4 and IPv6 addresses
respectively. This optional SubType indicates the address of the
serving PPS. If present, the Home RADIUS server uses this address to serving PPS. If present, the Home RADIUS server uses this address to
route the message to the serving PPS. Multiple instances of this route the message to the serving PPS. Multiple instances of this
subtype MAY be present in a single PPAQ attribute. The value of this subtype MAY be present in a single PPAQ attribute.
SubType is encoded as an address.
If present in the PrepaidServer SubType of an incoming RADIUS Access- If present in the PrepaidServer SubType of an incoming RADIUS Access-
Accept message, the PPC returns this SubType back without modifying Accept message, the PPC returns this SubType back without modifying
it in the subsequent RADIUS Access-Request message. If multiple it in the subsequent RADIUS Access-Request message. If multiple
values are present, the PPC MUST NOT change their order. values are present, the PPC MUST NOT change their order.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(12)
LENGTH : variable (6 or 14)
Address : Data type String
For IPv4, the Address field is 4 octets based on the encoding of
the NAS-IP-Address defined in RFC 2138. For IPv6, the Address
field is 16 octets long.
PrepaidServer SubType
4.3.12. Service-ID SubType 4.3.12. Service-ID SubType
The value of the type and length fields of the Service-ID SubType are The Service-ID SubType is handled as an opaque string that uniquely
TBD. The value field of this SubType is encoded as a string. This describes the service instance for which prepaid metering should be
value is handled as an opaque string that uniquely describes the applied.
service instance to which prepaid metering should be applied.
A Service-Id could be an IP 5-tuple (source address, source port, A Service-Id could be an IP 5-tuple (source address, source port,
destination address, destination port, protocol). If a Service-ID destination address, destination port, protocol). If a Service-ID
SubType is present in the PPAQ, the entire PPAQ attribute refers to SubType is present in the PPAQ, the entire PPAQ attribute refers to
that service. If a PPAQ attribute does not contain a Service-Id or that service. If a PPAQ attribute does not contain a Service-Id or
Rating-Group-ID, then the PPAQ attribute refers to the "Access Rating-Group-ID, then the PPAQ attribute refers to the "Access
Service". Service".
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Service ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(13)
LENGTH : variable
Service : Data type String
Service-ID SubType
4.3.13. Rating-Group-ID SubType 4.3.13. Rating-Group-ID SubType
The value of the type field of the Rating-Group-ID SubType is TBD. The Rating-Group-ID SubType indicates that this PPAQ attribute is
The length of this SubType is 6 octets. This SubType indicates that associated with resources allocated to a Rating Group with the
this PPAQ attribute is associated with resources allocated to a corresponding ID. This SubType is encoded as a string. A single
Rating Group with the corresponding ID. This SubType is encoded as a PPAQ MUST NOT contain more than one Rating-Group-ID.
string. A single PPAQ MUST NOT contain more than one
Rating-Group-ID. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(14)
LENGTH : 6
VALUE : Data type string
Rating-Group-ID SubType
4.3.14. Termination-Action SubType 4.3.14. Termination-Action SubType
The value of the type field of the Termination-Action SubType is TBD. The value of the type field of the Termination-Action SubType is TBD.
The length of this SubType is 3 octets. This SubType contains an The length of this SubType is 3 octets. This SubType contains an
enumeration of the action to take when the PPS does not grant enumeration of the action to take when the PPS does not grant
additional quota. Valid actions are as follows. additional quota. Valid actions are as follows.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(15)
LENGTH : 3
Action : Data type string.
The content is an 8 bit unsigned integer (with the values 0 to +255).
Termination-Action SubType
The following values for the Termination-Action SubType are defined: The following values for the Termination-Action SubType are defined:
Value | Description Value | Description
-------------+------------------------------------ -------------+------------------------------------
0 | Reserved 0 | Reserved
1 | Terminate 1 | Terminate
2 | Request More Quota 2 | Request More Quota
3 | Redirect/Filter 3 | Redirect/Filter
4..255 | **Available for IANA registration** 4..255 | **Available for IANA registration**
Figure 11: Values for the Termination-Action SubType Figure 12: Values for the Termination-Action SubType
4.3.15. Pool-ID SubType 4.3.15. Pool-ID SubType
The value of the type field of the Pool-ID SubType is TBD. The The Pool-ID SubType identifies the resource pool. It is encoded as a
length of this SubType is 6 octets and it identifies the resource string.
pool. It is encoded as a string.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Poolid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(16)
LENGTH : 6
Poolid : Data type string
Pool-ID SubType
4.3.16. Pool-Multiplier SubType 4.3.16. Pool-Multiplier SubType
The value of the type field of the Pool-Multiplier SubType is TBD. The Pool-Multiplier SubType determines the weight of resources when
The length of this SubType is 12 or 18 octets. The pool multiplier they are inserted into the pool that is identified by the
determines the weight that resources are inserted into the pool that accompanying Pool-ID SubType, and the rate at which resources are
is identified by the accompanying Pool-ID SubType, and the rate at taken out of the pool by the relevant Service or Rating-Group.
which resources are taken out of the pool by the relevant Service or
Rating-Group. The SubType consists of a Value-Digits SubType and 0 1 2 3
optionally an Exponent SubType (as indicated by the length field). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(17)
LENGTH : variable (8 or 14)
VALUE : Data type String
The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the
Exponent SubType. The length field indicates whether one or
both subtypes are included.
Pool-Multiplier SubType
4.3.17. Requested-Action SubType 4.3.17. Requested-Action SubType
The value of the type field of the Requested-Action SubType is TBD. The Requested-Action SubType is only be present in messages sent from
The length of this SubType is 3 octets and it is only be present in the PPC to the PPS. It indicates that the PPC desires the PPS to
messages sent from the PPC to the PPS. It indicates that the PPC perform the indicated action and to return the result. The PPAQ in
desires the PPS to perform the indicated action and to return the which a Requested-Action SubType occurs MUST NOT contain a QID, and
result. The PPAQ in which a Requested-Action SubType occurs MUST NOT MUST contain a Service-Identifier or a Rating-Group-Identifer that
contain a QID, and MUST contain a Service-Identifier or a Rating- allows the PPS to uniquely identify the service for which the
Group-Identifer that allows the PPS to uniquely identify the service indicated action is requested.
for which the indicated action is requested.
The following values for the Requested-Action SubType are defined: 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(18)
LENGTH : 3
Action : Data type string.
The content is a 8 bit unsigned integer (with the values 0 to +255)
with the values listed below.
Requested-Action SubType
The following values for the Action field of the Requested-Action
SubType are defined:
Value | Description Value | Description
-------------+------------------------------------- -------------+-------------------------------------
0 | Reserved 0 | Reserved
1 | Balance Check 1 | Balance Check
2 | Price Enquiry 2 | Price Enquiry
3..255 | **Available for IANA registration** 3..255 | **Available for IANA registration**
Figure 12: Values for the Requested-Action SubType Figure 13: Values for the Requested-Action SubType
4.3.18. Check-Balance-Result SubType 4.3.18. Check-Balance-Result SubType
The value of the type field of the Check-Balance-Result SubType is The Check-Balance-Result SubType can only be present in messages sent
TBD. The length of this SubType is 3 octets. This SubType can only from the PPS to the PPC. It indicates the balance check decision of
be present in messages sent from the PPS to the PPC. It indicates the PPS about a previously received Balance Check Request (as
the balance check decision of the PPS about a previously received indicated in a Requested-Action SubType). The PPAQ attribute in
Balance Check Request (as indicated in a Requested-Action SubType). which a Check-Balance-Result occurs MUST NOT include a QID beause no
The PPAQ attribute in which a Check-Balance-Result occurs MUST NOT quota is reserved by the PPS.
include a QID.
The following values for the Check-Balance-Result SubType are 0 1 2
defined: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Decision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(19)
LENGTH : 3
Decision : Data type string.
The content is a 8 bit unsigned integer (with the values 0 to +255)
with the values listed below.
Check-Balance-Result SubType
The following values for the Decision field of the Check-Balance-
Result SubType are defined:
Value | Description Value | Description
-------------+------------------------------------------- -------------+-------------------------------------------
0 | Success; Sufficient funds available 0 | Success; Sufficient funds available
| in the user's prepaid account | in the user's prepaid account
1 | Failure; Insufficient funds available 1 | Failure; Insufficient funds available
2..255 | **Available for IANA registration** 2..255 | **Available for IANA registration**
Figure 13: Values for the Check-Balance-Result SubType Figure 14: Values for the Check-Balance-Result SubType
4.3.19. Cost-Information SubType 4.3.19. Cost-Information SubType
The value of the type field of the Cost-Information SubType is TBD. The Cost-Information SubType is used in order to return the cost
The length of this SubType is variable. This SubType is used in information of a service, which the PPC can transfer transparently to
order to return the cost information of a service, which the PPC can the end user. This SubType is sent from the PPS to the PPC as a
transfer transparently to the end user. This SubType is sent from response to a "Price Enquiry", as indicated by the Requested-Action
the PPS to the PPC as a response to a "Price Enquiry", as indicated SubType.
by the Requested-Action SubType. This SubType consists of four
further SubTypes, as follows:
Value-Digits SubType:
The Value-Digits SubType encodes the most significant digits of 0 1 2 3
the monetery value that represents the cost in question. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exponent SubType: The fields have the following meaning and encoding:
The Exponent SubType encodes the exponent that applies to the SubType : Value(20)
Value-Digits SubType.
Currency-Code SubType: LENGTH : variable
the value of the type field of this SubType is TBD. The length of VALUE : Data type String
this SubType is 4 octets. It encodes the currency code, as
defined in the ISO 4217 standard.
Cost-Unit SubType: The content of the VALUE field contains (in this order) the
Value-Digits SubType, followed by the
Exponent SubType, Currency-Code SubType and the Cost-Unit SubType.
the value of the type field of this SubType is TBD. The length of Cost-Information SubType
this SubType is variable. It carries a UTF8String encoded human
readable string that can be displayed to the end user. It
specifies the applicable unit to the Cost-Information when the
service cost is a cost per unit (e.g., cost of the service is $1
per minute). The Cost-Unit can be minutes, hours, days,
kilobytes, megabytes, etc.
For example, the cost of 7.75 Malawi kwacha per hour would be encoded For example, the cost of 7.75 Malawi kwacha per hour would be encoded
as follows. Value-Digits = 775, Exponent = -2, Currency Code = 103, as follows. Value-Digits = 775, Exponent = -2, Currency Code = 454,
and Cost-Unit = "hour". and Cost-Unit = "hour".
The PPAQ that carries a Cost-Information MUST NOT include a QID. The PPAQ that carries a Cost-Information MUST NOT include a QID.
4.3.20. Currency-Code SubType
The Currency-Code SubType is used inside the Check-Balance-Result
SubType and contains a currency code that specifies in which currency
the values of AVPs containing monetary units were given. It is
specified by using the numeric values defined in the ISO 3166-1
standard.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(21)
LENGTH : 4
Code : Data type string
The content of the Code field is a 16-bit unsigned integer
(with the values 0 to +65,535).
Currency-Code SubType
4.3.21. Cost-Unit SubType
The Cost-Unit SubType is used inside the Check-Balance-Result SubType
and contains a human readable UTF8 encoded string that can be
displayed to the end user. It specifies the applicable unit to the
Cost-Information when the service cost is a cost per unit (e.g., cost
of the service is $1 per minute). The Cost-Unit can, for example, be
minutes, hours, days, kilobytes, megabytes, etc.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(22)
LENGTH : variable
VALUE : Data type String
The content of the VALUE field contains a UTF8 encoded string.
Cost-Unit SubType
4.4. Prepaid Tariff Switching (PTS) Attribute 4.4. Prepaid Tariff Switching (PTS) Attribute
This specification defines the PTS attribute, which allows to switch This specification defines the PTS attribute, which allows to switch
from one rate to another during service provision. Support for from one rate to another during service provision. Support for
tariff switching is optional to implement and to use for the PPC and tariff switching is optional to implement and to use for the PPC and
the PPS. PPCs use the flag "Tariff Switching supported" in the the PPS. PPCs use the flag "Tariff Switching supported" in the
AvailableInClient field of the PPAC attribute in order to indicate AvailableInClient field of the PPAC attribute in order to indicate
support for tariff switching. PPSs employ the PTS attribute in order support for tariff switching. PPSs employ the PTS attribute in order
to announce their support for tariff switching. to announce their support for tariff switching.
skipping to change at page 40, line 48 skipping to change at page 52, line 40
to the tariff switch for that service. If the PPAQ does not have a to the tariff switch for that service. If the PPAQ does not have a
Service-ID, then the PTS refers to tariff switch for the "Access Service-ID, then the PTS refers to tariff switch for the "Access
Service". Service".
A PPAQ attribute that is transported along with a PTS attribute and A PPAQ attribute that is transported along with a PTS attribute and
has the same value as the QID SubType contained in the PTS attribute has the same value as the QID SubType contained in the PTS attribute
in its own QID SubType is referred to as the "accompanying PPAQ in its own QID SubType is referred to as the "accompanying PPAQ
attribute". If a PPS receives an Access-Request message from a PPC, attribute". If a PPS receives an Access-Request message from a PPC,
it associates a unique value for the QID SubType to this request. it associates a unique value for the QID SubType to this request.
The PTS attribute, as shown in Figure 14, contains a number of other The PTS attribute, as shown in Figure 15, contains a number of other
subtypes which are specified in the following subsections. subtypes which are specified in the following subsections.
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 | VALUE ... | Type | Length | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... VALUE | ... VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE : value of PTS Type : PTS (38)
LENGTH: variable
VALUE : Variable length content of data type String Length: variable
VALUE : Variable length content of data type String containing
one or multiple SubTypes.
Each SubType is then encoding in the following style: Each SubType is then encoding in the following style:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ... | SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PTS Attribute The fields have the following meaning and encoding:
SubType:
Contains an 8 bit unsigned integer.
LENGTH:
Contains an 8 bit unsigned integer.
VALUE:
Contains the content of the SubType.
Figure 15: PTS Attribute
4.4.1. VolumeUsedAfterTariffSwitch SubType 4.4.1. VolumeUsedAfterTariffSwitch SubType
The value of the type field of the VolumeUsedAfterTariffSwitch The optional VolumeUsedAfterTariffSwitch (VUATS) SubType is used in
(VUATS) SubType is TBD. The length of this SubType is 12 or 18
octets. The VolumeUsedAfterTariffSwitch subtype SHOULD be used in
the RADIUS Access-Request messages (PPC to PPS direction). It the RADIUS Access-Request messages (PPC to PPS direction). It
indicates the volume (in octets) used during a session after the last indicates the volume (in octets) used during a session after the last
tariff switch for the service specified via the QID SubType and the tariff switch for the service specified via the QID SubType and the
accompanying PPAQ attribute. The attribute consists of a Value- accompanying PPAQ attribute.
Digits SubType and optionally an Exponent SubType (as indicated in
the length field). 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(23)
LENGTH : variable (8 or 14)
VALUE : Data type String
The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the
Exponent SubType. The length field indicates whether one or
both subtypes are included.
VolumeUsedAfterTariffSwitch SubType
4.4.2. TariffSwitchInterval SubType 4.4.2. TariffSwitchInterval SubType
The type of the TariffSwitchInterval (TSI) SubType is TBD and its The TariffSwitchInterval (TSI) SubType MUST be present in each PTS
length 6 octets. This SubType MUST be present in each PTS attribute attribute that is part of a RADIUS Access-Accept message (PPS to PPC
that is part of a RADIUS Access-Accept message (PPS to PPC
direction). It indicates the interval (in seconds) between the value direction). It indicates the interval (in seconds) between the value
of Event-Timestamp RADIUS attribute (see [RFC2869]) of the of Event-Timestamp RADIUS attribute (see [RFC2869]) of the
corresponding RADIUS Access-Request message and the next tariff corresponding RADIUS Access-Request message and the next tariff
switch condition. switch condition.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(24)
LENGTH : 6
VALUE : Data type string
This field contains a 16-bit unsigned integer
(with the values 0 to +65,535).
TariffSwitchInterval SubType
4.4.3. TimeIntervalafterTariffSwitchUpdate SubType 4.4.3. TimeIntervalafterTariffSwitchUpdate SubType
The value of the type field of the The PPS MUST include TimeIntervalafterTariffSwitchUpdate (TITSU)
TimeIntervalafterTariffSwitchUpdate (TITSU) SubType is TBD. The
length of this SubType is 6 octets. The PPS MUST include this
SubType if there is another tariff switch period after the period SubType if there is another tariff switch period after the period
that ends as indicated by the TSI SubType. The value of the TITSU that ends as indicated by the TSI SubType. The value of the TITSU
SubType in encoded as an integer, and contains the number of seconds SubType contains the number of seconds of the tariff period that
of the tariff period that begins immediately after the period that begins immediately after the period that ends as indicated by the TSI
ends as indicated by the TSI attribute. If the TITSU SubType is not attribute. If the TITSU SubType is not present, the PPC assumes that
present, the PPC assumes that the tariff period which ends as the tariff period, which ends as indicated by the TSI SubType, lasts
indicated by the TSI SubType lasts until further notice. If TITSU is until further notice. If TITSU is specified, the PPC MUST send a
specified, the PPC MUST send a quota update before the point in time quota update before the point in time specified by the TITSU SubType
specified by the TITSU SubType (see Figure 7). (see Figure 7).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding:
SubType : Value(25)
LENGTH : 6
VALUE : Data type string
This field contains a 16-bit unsigned integer
(with the values 0 to +65,535).
TimeIntervalafterTariffSwitchUpdate SubType
5. Diameter RADIUS Interoperability 5. Diameter RADIUS Interoperability
The RADIUS prepaid extensions need to interoperate with the Diameter The RADIUS Prepaid extension described in this document may need to
protocol. Two interoperability scenarios exist, as follows. Either interoperate with the Diameter Credit Control Application. Two
the AAA infrastructure is Diameter based and the PPC are RADIUS interoperability scenarios exist, as follows. Either the AAA server
based, or the PPC is Diameter based and the AAA infrastructure is is Diameter based and the AAA client is RADIUS based, or the AAA
RADIUS based. client is Diameter based and the AAA server is RADIUS based.
The Diameter Credit Control Application [RFC4006] describes how to The Diameter Credit Control Application [RFC4006] describes how to
implement a prepaid accounting system using a Diameter based implement a prepaid accounting system using a Diameter based
infrastructure. infrastructure.
The translation functionality between a Diameter Credit Control and a A possible procedure for accomplishing the translation of the
RADIUS prepaid protocol interaction is described in Appendix B. functionality defined in Diameter Credit Control and in the RADIUS
Prepaid specification is described in Appendix B.
6. Security Considerations 6. Security Considerations
The extended RADIUS protocol described in this document is subject to This specification describes the use of RADIUS for purposes of real-
a number of potential attacks, in a manner similar to the RADIUS time accounting. Threats and security issues for this application
protocol without these extensions. It is recommended that IPsec be are described in [RFC3579] and [RFC3580]; security issues encountered
employed to protect against certain of the attacks. in roaming are described in [RFC2607].
[Editor's Note: This section is freaking short. We should add This document specifies new attributes that can be included in
something here.] existing RADIUS packets, which are protected as described in
[RFC3579] and [RFC3576]. See those documents for a more detailed
description.
The security mechanisms supported in RADIUS are focused on preventing
an attacker from spoofing packets or modifying packets in transit.
They do not prevent an authorized RADIUS/Diameter server or proxy
from modifying, inserting, or removing attributes with malicious
intent. When the attributes defined in this document are modified or
removed by a RADIUS proxy they may lead to incorrect accounting
records being delivered to users or wrong resource consumption being
collected.
The described mechanism add the mechanism of capability negotiation,
so that a RADIUS server can automatically discover whether a NAS
supports the real-time accounting features described in this document
(and even more detailed capabilities can be learned by the RADIUS
server). These mechanisms are being added to ensure that neither the
NAS nor the RADIUS server make incorrect assumptions about the
capabilities of the other party; potentially leading to incorrect
accounting and improper access to the network or other services.
7. Table of Attributes 7. Table of Attributes
The following table provides a guide which attributes may be found in The following table provides a guide which attributes may be found in
which RADIUS messages, and in what quantity. which RADIUS messages, and in what quantity.
Request Accept Reject Challenge Accounting # Attribute Request Accept Reject Challenge Accounting # Attribute
Request Request
0-1 0 0 0 0 TBD PPAC 0-1 0 0 0 0 35 PPAC
0+ 0+ 0 0 0+ TBD PPAQ 0+ 0+ 0 0 0+ 37 PPAQ
0+ 0+ 0 0 0+ TBD PTS 0+ 0+ 0 0 0+ 38 PTS
0-1 0 0 0 0 36 Session Termination
Capability
8. IANA Considerations 8. IANA Considerations
This document contains a number of instructions to IANA. This document contains a number of instructions to IANA.
8.1. New RADIUS Attributes 8.1. RADIUS Attributes
This document requires the assignment of new RADIUS attributes type This document does not require IANA to register the following four
numbers for the following attributes: RADIUS attributes as the code registered by the Wimax Forum is re-
used. The Wimax Forum SMI Network Management Private Enterprise Code
is 24757.
Attribute Name | Attribute Type Value Attribute Name | Attribute Type Value
--------------------------------------+----------------------------- --------------------------------------+-----------------------------
Prepaid-Accounting-Capability (PPAC) | TBD Prepaid-Accounting-Capability (PPAC) | 35
Prepaid-Accounting-Operation (PPAQ) | TBD Prepaid-Accounting-Operation (PPAQ) | 37
Prepaid Tariff Switching (PTS) | TBD Prepaid Tariff Switching (PTS) | 38
Session Termination Capability | 36
8.2. New Registry: Prepaid SubTypes 8.2. New Registry: RADIUS Prepaid SubTypes
Section 4 defines the SubTypes used within newly defined attributes. Section 4 defines the SubTypes used within newly defined attributes.
IANA is asked to create a registry for these SubTypes. Each registry IANA is asked to create a registry for these SubTypes. Each registry
entry consists of a 8 bit number together with a description of the entry consists of a 8 bit number together with a description of the
SubType. This document creates the following SubTypes for this SubType. This document creates the following SubTypes for this
registry: registry:
Value | SubType Name Value | SubType Name
---------+----------------------------- ---------+-----------------------------
0 | Reserved 0 | Reserved
skipping to change at page 47, line 29 skipping to change at page 60, line 29
12 | PrepaidServer 12 | PrepaidServer
13 | Service-ID 13 | Service-ID
14 | Rating-Group-ID 14 | Rating-Group-ID
15 | Termination-Action 15 | Termination-Action
16 | Pool-ID 16 | Pool-ID
17 | Pool-Multiplier 17 | Pool-Multiplier
18 | Requested-Action 18 | Requested-Action
19 | Check-Balance-Result 19 | Check-Balance-Result
20 | Cost-Information 20 | Cost-Information
21 | Currency-Code 21 | Currency-Code
22 | Cost-Unit SubType 22 | Cost-Unit
23 | VolumeUsedAfterTariffSwitch 23 | VolumeUsedAfterTariffSwitch
24 | TariffSwitchInterval 24 | TariffSwitchInterval
25 | TimeIntervalafterTariffSwitchUpdate 25 | TimeIntervalafterTariffSwitchUpdate
26..255 | **Available for IANA registration** 26..255 | **Available for IANA registration**
The semantic of the above-listed SubTypes is described in Section 4. The semantic of the above-listed SubTypes is described in Section 4.
Following the policies outline in [RFC3575] the available SubTypes Following the policies outline in [RFC3575] the available SubTypes
(i.e., value 0 and values 26-255) with a description of their (i.e., value 0 and values 26-255) with a description of their
semantic will be assigned after Expert Review initiated by the O&M semantic will be assigned after Expert Review initiated by the O&M
skipping to change at page 48, line 9 skipping to change at page 61, line 9
mark entries as "deprecated", or to delete entries from the registry mark entries as "deprecated", or to delete entries from the registry
is envisioned. is envisioned.
Each registration must include a number for the SubType and the Each registration must include a number for the SubType and the
semantic of the SubType. semantic of the SubType.
8.3. New Registry: Update-Reason 8.3. New Registry: Update-Reason
Section 4.3.10 defines the Update-Reason SubType. IANA is asked to Section 4.3.10 defines the Update-Reason SubType. IANA is asked to
create a registry for the values contained in the Update-Reason create a registry for the values contained in the Update-Reason
SubType, as shown in Figure 10. Each registry entry consists of a 8 SubType, as shown in Figure 11. Each registry entry consists of a 16
bit number together with a description of the update reason. bit number together with a description of the update reason.
Following the policies outline in [RFC3575] the available values Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned. to delete entries from the registry is envisioned.
8.4. New Registry: Termination-Action 8.4. New Registry: Termination-Action
Section 4.3.14 defines the Termination-Action SubType. IANA is asked Section 4.3.14 defines the Termination-Action SubType. IANA is asked
to create a registry for the values contained in the Termination- to create a registry for the values contained in the Termination-
Action SubType, as shown in Figure 11. Each registry entry consists Action SubType, as shown in Figure 12. Each registry entry consists
of a 8 bit number together with a description of the termination of a 8 bit number together with a description of the termination
action. action.
Following the policies outline in [RFC3575] the available values Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned. to delete entries from the registry is envisioned.
8.5. New Registry: Requested-Action 8.5. New Registry: Requested-Action
Section 4.3.17 defines the Requested-Action SubType. IANA is asked Section 4.3.17 defines the Requested-Action SubType. IANA is asked
to create a registry for the values contained in the Requested-Action to create a registry for the values contained in the Requested-Action
SubType, as shown in Figure 12. Each registry entry consists of a 8 SubType, as shown in Figure 13. Each registry entry consists of a 8
bit number together with a description of the requested reason. bit number together with a description of the requested reason.
Following the policies outline in [RFC3575] the available values Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned. to delete entries from the registry is envisioned.
8.6. New Registry: Check-Balance-Result 8.6. New Registry: Check-Balance-Result
Section 4.3.18 defines the Check-Balance-Result SubType. IANA is Section 4.3.18 defines the Check-Balance-Result SubType. IANA is
asked to create a registry for the values contained in the Check- asked to create a registry for the values contained in the Check-
Balance-Result SubType, as shown in Figure 13. Each registry entry Balance-Result SubType, as shown in Figure 14. Each registry entry
consists of a 8 bit number together with a description of the consists of a 8 bit number together with a description of the
requested reason. requested reason.
Following the policies outline in [RFC3575] the available values Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned. to delete entries from the registry is envisioned.
8.7. New Registry: AvailableInClient-Extended
Section 4.3.18 defines the PrePaid Accounting Capability (PPAC)
attribute with the AvailableInClient-Extended field. IANA is asked
to create a registry for the values contained in the
AvailableInClient-Extended field, as shown in Section 4.1. Each
registry entry consists of a 8 bit number together with a description
of the capability. Note that this is a bitmask and only 8 values are
available for registration via IANA.
Following the policies outline in [RFC3575] the available values
together with a description of their semantic will be assigned after
Expert Review initiated by the O&M Area Directors in consultation
with the RADEXT working group chairs or the working group chairs of a
designated successor working group. Updates can be provided based on
expert approval only. A designated expert will be appointed by the
O&M Area Directors. No mechanism to mark entries as "deprecated", or
to delete entries from the registry is envisioned.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Christian Guenther, Bernard Aboba, The authors would like to thank Christian Guenther, Bernard Aboba,
and John Loughney for their feedback throughout the development of and John Loughney for their feedback throughout the development of
this document. this document. Additionally, the authors would like to thank the
members of the Wimax Forum and the members of 3GPP2 for their help
with this specification.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to [RFC2119] Bradner, S., "RFC 2119: Key words for use in RFCs to
Indicate Requirement Levels", March 1997. Indicate Requirement Levels", March 1997.
[RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "RFC
2865: Remote Authentication Dial In User Server (RADIUS)", 2865: Remote Authentication Dial In User Server (RADIUS)",
June 2000. June 2000.
10.2. Informative References 10.2. Informative References
[I-D.ietf-radext-filter-rules]
Congdon, P., "RADIUS Attributes for Filtering and
Redirection", draft-ietf-radext-filter-rules-03 (work in
progress), July 2007.
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
Authentication Protocol (EAP)", RFC 2284, March 1998. Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000. [RFC2866] Rigney, C., "RFC 2866: RADIUS Accounting", June 2000.
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RFC 2869: RADIUS
Extensions", June 2000. Extensions", June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, Authentication Dial In User Service)", RFC 3575,
July 2003. July 2003.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Adoba, "RFC 3576: Dynamic Authorization Extensions to Adoba, "RFC 3576: Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service (RADIUS)", Remote Authentication Dial-In User Service (RADIUS)",
February 2003. February 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Adoba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "RFC 3748: Extensible Authentication Protocol", Levkowetz, "RFC 3748: Extensible Authentication Protocol",
June 2004. June 2004.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "RFC 4006: Diameter Credit Control Application", Loughney, "RFC 4006: Diameter Credit Control Application",
August 2005. August 2005.
[RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter
Rule Attribute", RFC 4849, April 2007.
Appendix A. Example flows Appendix A. Example flows
Note: This section is informative.
This section presents certain example flows that involve the RADIUS This section presents certain example flows that involve the RADIUS
prepaid extensions. By no means is the intent of this section to prepaid extensions. By no means is the intent of this section to
specify or recommend business logic, rating strategies, and specify or recommend business logic, rating strategies, and
application-level behaviour. The intent of this section is purely to application-level behaviour. The intent of this section is purely to
illustrate some fictive scenarios and the RADIUS prepaid message illustrate some fictive scenarios and the RADIUS prepaid message
flows that could be associated with these scenarios. The contents of flows that could be associated with these scenarios. The contents of
this section should be regarded as a collection of informative this section should be regarded as a collection of informative
examples that aim to provide guidance to implementors. examples that aim to provide guidance to implementors.
A.1. A simple flow A.1. A simple flow
skipping to change at page 53, line 22 skipping to change at page 67, line 25
REASON=ACCESS SERV TERMINATED}} REASON=ACCESS SERV TERMINATED}}
-------(8)---------> -------(8)--------->
[reimburses [reimburses
user account] user account]
AA Accept AA Accept
{RADIUS BASE AVPS} {RADIUS BASE AVPS}
<-------(9)-------- <-------(9)--------
Figure 18: A simple example message flow Figure 16: A simple example message flow
The user logs on (1). The PPC sends a RADIUS Access Request message The user logs on (1). The PPC sends a RADIUS Access Request message
to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP to the PPS (2), and includes the prepaid-specific PPAC AVP. This AVP
indicates that both duration-based and volume-based metering is indicates that both duration-based and volume-based metering is
supported. However, it also indicated that multiple services, rating supported. However, it also indicated that multiple services, rating
groups and resource pools are not supported. Note that, since this groups and resource pools are not supported. Note that, since this
is not an "Authorize-Only" message, no PPAQ attribute with Update is not an "Authorize-Only" message, no PPAQ attribute with Update
Reason="initial request" is included (see Section 3.7.1). The PPS Reason="initial request" is included (see Section 3.7.1). The PPS
then authenticates the user and authorizes the access service, as is then authenticates the user and authorizes the access service, as is
usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at usual in RADIUS. Note that the PPAC AVP is appended by the PPC in at
skipping to change at page 55, line 45 skipping to change at page 70, line 4
to the access service] to the access service]
Access Accept Access Accept
{RADIUS BASE AVPS, {RADIUS BASE AVPS,
PPAQ={QID=8, VQ=30MB, PPAQ={QID=8, VQ=30MB,
VTH = 28 MB},PTS={ VTH = 28 MB},PTS={
QUD=8, PTS=95 sec}} QUD=8, PTS=95 sec}}
<----------(6)-------------- <----------(6)--------------
user logs off user logs off
------(7)------- ------(7)-------
Access Request Access Request
{RADIUS BASE AVPS, {RADIUS BASE AVPS,
PPAQ={QID=8, VQ=17 MB, PPAQ={QID=8, VQ=17 MB,
REASON=ACCESS SERV TERMINATED}, REASON=ACCESS SERV TERMINATED},
PTS={QID=8, VUATS=2.5 MB} PTS={QID=8, VUATS=2.5 MB}
-------(8)---------> -------(8)--------->
[reimburses [reimburses
user account] user account]
AA Accept AA Accept
{RADIUS BASE AVPS} {RADIUS BASE AVPS}
<-------(9)-------- <-------(9)--------
Figure 19: Example message flow with Tariff Switch Figure 17: Example message flow with Tariff Switch
The user logs on (1). The PPC sends a RADIUS Access Request message The user logs on (1). The PPC sends a RADIUS Access Request message
to the home AAA server (2), and includes the prepaid-specific PPAC to the home AAA server (2), and includes the prepaid-specific PPAC
AVP. This AVP indicates that both duration-based and volume-based AVP. This AVP indicates that both duration-based and volume-based
metering is supported, as well as tariff switching. The home AAA metering is supported, as well as tariff switching. The home AAA
server then may authenticate and user and authorize the access server then may authenticate and user and authorize the access
service, as is usual in RADIUS. Note that the PPAC AVP is appended service, as is usual in RADIUS. Note that the PPAC AVP is appended
by the PPC in at least the last message that is sent to the PPS by the PPC in at least the last message that is sent to the PPS
during this possibly multiple-round exchange. during this possibly multiple-round exchange.
skipping to change at page 60, line 34 skipping to change at page 74, line 36
SID="A",RGROUP=1}} SID="A",RGROUP=1}}
-------(12)---------> -------(12)--------->
[reimburses [reimburses
user account] user account]
AA Accept AA Accept
{RADIUS BASE AVPS {RADIUS BASE AVPS
<------(13)-------- <------(13)--------
Figure 20: Example message flow with resource pools and rating groups Figure 18: Example message flow with resource pools and rating groups
The user logs on (1). The PPC sends a RADIUS Access Request message The user logs on (1). The PPC sends a RADIUS Access Request message
to the PPS (2), and includes the prepaid-specific PPAC AVP, to the PPS (2), and includes the prepaid-specific PPAC AVP,
indicating that multiple services, rating groups and resource pools indicating that multiple services, rating groups and resource pools
are supported. Note that, since this is not an "Authorize- Only" are supported. Note that, since this is not an "Authorize- Only"
message, no PPAQ attribute with Update Reason="initial request" is message, no PPAQ attribute with Update Reason="initial request" is
included (see Section 3.7.1). The PPS then may authenticate the user included (see Section 3.7.1). The PPS then may authenticate the user
and authorize the access service, as is usual in RADIUS. Note that and authorize the access service, as is usual in RADIUS. Note that
the PPAC AVP is appended by the PPC in at least the last message that the PPAC AVP is appended by the PPC in at least the last message that
is sent to the PPS during this possibly multiple-round exchange. is sent to the PPS during this possibly multiple-round exchange.
skipping to change at page 64, line 25 skipping to change at page 78, line 25
[rates 650 abstract units [rates 650 abstract units
deducts from user's account] deducts from user's account]
Access Accept Access Accept
{RADIUS BASE AVPS} {RADIUS BASE AVPS}
<----------(3)-------------- <----------(3)--------------
ring tone is delivered ring tone is delivered
<------(4)------- <------(4)-------
Figure 21: Example message flow with one-time charging Figure 19: Example message flow with one-time charging
The user requests a chargeable ring tone (1). The PPC sends a RADIUS The user requests a chargeable ring tone (1). The PPC sends a RADIUS
Access Request message to the PPS (2), and includes a PPAQ attribute Access Request message to the PPS (2), and includes a PPAQ attribute
with Update Reason="one-time charging" is included (see with Update Reason="one-time charging" is included (see
Section 3.8.6). The Service ID indicates to the PPS that the Section 3.8.6). The Service ID indicates to the PPS that the
charging event is connected to a ring tone, so that the PPS can rate charging event is connected to a ring tone, so that the PPS can rate
the event accordingly. The PPAQ also contains a unique Quota the event accordingly. The PPAQ also contains a unique Quota
Identifier. Identifier.
The PPS then may authenticate the user as is usual in RADIUS. If The PPS then may authenticate the user as is usual in RADIUS. If
skipping to change at page 65, line 28 skipping to change at page 79, line 28
Access Accept Access Accept
{RADIUS BASE AVPS, {RADIUS BASE AVPS,
PPAQ={SID=X, VQ=10MB, PPAQ={SID=X, VQ=10MB,
COST INFORMATION= 0.6 euros COST INFORMATION= 0.6 euros
per MB}} per MB}}
<----------(3)-------------- <----------(3)--------------
AoC is delivered AoC is delivered
<------(4)------- <------(4)-------
Figure 22: Example message flow with price enquiry (advice of charge) Figure 20: Example message flow with price enquiry (advice of charge)
Please refer to Section 2.7.3 for an explanation of this message Please refer to Section 2.7.3 for an explanation of this message
flow. flow.
A.6. Balance check A.6. Balance check
End User PPC PPS End User PPC PPS
Access Request Access Request
{RADIUS BASE AVPS, {RADIUS BASE AVPS,
PPAQ={SID=X, VQ=10MB, PPAQ={SID=X, VQ=10MB,
skipping to change at page 66, line 22 skipping to change at page 80, line 22
[rates requested [rates requested
Service and checks Service and checks
remaining funds] remaining funds]
Access Accept Access Accept
{RADIUS BASE AVPS, {RADIUS BASE AVPS,
PPAQ={SID=X, VQ=10MB, PPAQ={SID=X, VQ=10MB,
BALANCE_CHECK_RESULT}} BALANCE_CHECK_RESULT}}
<----------(3)-------------- <----------(3)--------------
Figure 23: Example message flow with balance check Figure 21: Example message flow with balance check
Please refer to Section 2.7.4 for an explanation of this message Please refer to Section 2.7.4 for an explanation of this message
flow. flow.
Appendix B. Translation between RADIUS Prepaid and Diameter Credit Appendix B. Translation between RADIUS Prepaid and Diameter Credit
Control Control
Note: This section is informative.
In scenarios where the service metering device uses the "RADIUS In scenarios where the service metering device uses the "RADIUS
prepaid" (RPP) protocol for accounting and prepaid charging while the prepaid" (RPP) protocol for accounting and prepaid charging while the
AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol, AAA infrastructure uses the "Diameter Credit Control" (DCC) protocol,
a translation agent that enables the interoperation of both systems, a translation agent that enables the interoperation of both systems,
is desirable. This also applies vice versa, i.e., in scenarios where is desirable. This also applies vice versa, i.e., in scenarios where
the AAA infrastructure uses RADIUS and the service metering device the AAA infrastructure uses RADIUS and the service metering device
uses Diameter. uses Diameter.
The idea of such a translation agent would be to convert incoming RPP The idea of such a translation agent would be to convert incoming RPP
(resp. DCC) messages into outgoing DCC (resp. RPP) messages. It (resp. DCC) messages into outgoing DCC (resp. RPP) messages. It
skipping to change at page 76, line 38 skipping to change at page 90, line 38
Email: kchowdhury@starentnetworks.com Email: kchowdhury@starentnetworks.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.com URI: http://www.tschofenig.priv.at
Andreas Pashalidis Andreas Pashalidis
NEC NEC
Kurfuersten-Anlage 36 Kurfuersten-Anlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Email: Andreas.Pashalidis@netlab.nec.de Email: Andreas.Pashalidis@netlab.nec.de
Full Copyright Statement Full Copyright Statement
skipping to change at page 77, line 44 skipping to change at line 3780
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 102 change blocks. 
315 lines changed or deleted 843 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/