< draft-lior-radius-prepaid-extensions-15.txt   draft-lior-radius-prepaid-extensions-16.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: May 5, 2009 Cisco Expires: January 14, 2010 Juniper
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
A. Pashalidis A. Pashalidis
NEC NEC
November 1, 2008 July 13, 2009
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-15.txt draft-lior-radius-prepaid-extensions-16.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 5, 2009. This Internet-Draft will expire on January 14, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 7 1.2.1. Architectural Model . . . . . . . . . . . . . . . . . 8
1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 9 1.2.2. Motivation . . . . . . . . . . . . . . . . . . . . . . 10
1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 12
1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 11 1.4. Example Use Case . . . . . . . . . . . . . . . . . . . . . 12
2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 14 2. Supported Features . . . . . . . . . . . . . . . . . . . . . . 15
2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 14 2.1. Services and Quotas . . . . . . . . . . . . . . . . . . . 15
2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 14 2.2. Resource Pools . . . . . . . . . . . . . . . . . . . . . . 15
2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 16 2.3. Rating Groups . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 17 2.4. Tariff Switching . . . . . . . . . . . . . . . . . . . . . 18
2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 18 2.5. Support for Roaming . . . . . . . . . . . . . . . . . . . 19
2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 19 2.6. Dynamic Termination . . . . . . . . . . . . . . . . . . . 20
2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 19 2.7. One Time Event . . . . . . . . . . . . . . . . . . . . . . 20
2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 19 2.7.1. One-Time Charging . . . . . . . . . . . . . . . . . . 20
2.7.2. Resource Consumption Query . . . . . . . . . . . . . . 20 2.7.2. Resource Consumption Query . . . . . . . . . . . . . . 21
2.7.3. Service Price Enquiry . . . . . . . . . . . . . . . . 20 2.7.3. Service Price Enquiry . . . . . . . . . . . . . . . . 21
2.7.4. Balance Check . . . . . . . . . . . . . . . . . . . . 21 2.7.4. Balance Check . . . . . . . . . . . . . . . . . . . . 22
2.7.5. Refund . . . . . . . . . . . . . . . . . . . . . . . . 21 2.7.5. Refund . . . . . . . . . . . . . . . . . . . . . . . . 22
3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 22 3.1. Capability Discovery . . . . . . . . . . . . . . . . . . . 23
3.2. Authentication and Authorization Operation . . . . . . . . 22 3.2. Authentication and Authorization Operation . . . . . . . . 23
3.3. Session Start Operation . . . . . . . . . . . . . . . . . 24 3.3. Session Start Operation . . . . . . . . . . . . . . . . . 25
3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 24 3.4. Mid-Session Operation . . . . . . . . . . . . . . . . . . 25
3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 26 3.5. Dynamic Operations . . . . . . . . . . . . . . . . . . . . 27
3.5.1. Unsolicited Session Termination Operation . . . . . . 26 3.5.1. Unsolicited Session Termination Operation . . . . . . 27
3.5.2. Unsolicited Change of Authorization Operation . . . . 26 3.5.2. Unsolicited Change of Authorization Operation . . . . 27
3.6. Termination Operation . . . . . . . . . . . . . . . . . . 27 3.6. Termination Operation . . . . . . . . . . . . . . . . . . 28
3.7. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 27 3.7. Mobile IP Operations . . . . . . . . . . . . . . . . . . . 28
3.8. Operation Considerations for Multiple Services . . . . . . 28 3.8. Operation Considerations for Multiple Services . . . . . . 29
3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 28 3.8.1. Initial Quota Request . . . . . . . . . . . . . . . . 29
3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 29 3.8.2. Quota Update . . . . . . . . . . . . . . . . . . . . . 30
3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 29 3.8.3. Termination . . . . . . . . . . . . . . . . . . . . . 30
3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 29 3.8.4. Dynamic Operations . . . . . . . . . . . . . . . . . . 30
3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 30 3.8.5. Support for Resource Pools . . . . . . . . . . . . . . 31
3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 30 3.8.6. One-time Charging . . . . . . . . . . . . . . . . . . 31
3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 30 3.8.7. Error Handling . . . . . . . . . . . . . . . . . . . . 31
3.8.8. Accounting Considerations . . . . . . . . . . . . . . 31 3.8.8. Accounting Considerations . . . . . . . . . . . . . . 32
4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 32 4.1. PrePaid Accounting Capability (PPAC) Attribute . . . . . . 33
4.2. Session Termination Capability Attribute . . . . . . . . . 33 4.2. Session Termination Capability Attribute . . . . . . . . . 35
4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 34 4.3. Prepaid Accounting Operation (PPAQ) Attribute . . . . . . 37
4.4. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 52 4.4. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 56 4.5. Prepaid Tariff Switching (PTS) Attribute . . . . . . . . . 54
6. Security Considerations . . . . . . . . . . . . . . . . . . . 57 5. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 60
7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 61
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 7. Table of Attributes . . . . . . . . . . . . . . . . . . . . . 62
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
10.1. Normative References . . . . . . . . . . . . . . . . . . . 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68
10.2. Informative References . . . . . . . . . . . . . . . . . . 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 68
Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 66 10.2. Informative References . . . . . . . . . . . . . . . . . . 68
A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 66 Appendix A. Example flows . . . . . . . . . . . . . . . . . . . . 70
A.2. A flow with prepaid tariff switching . . . . . . . . . . . 69 A.1. A simple flow . . . . . . . . . . . . . . . . . . . . . . 70
A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 72 A.2. A flow with prepaid tariff switching . . . . . . . . . . . 73
A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 77 A.3. Resource pools and Rating Groups . . . . . . . . . . . . . 76
A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 78 A.4. One-time charging . . . . . . . . . . . . . . . . . . . . 81
A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 79 A.5. Price enquiry . . . . . . . . . . . . . . . . . . . . . . 82
A.6. Balance check . . . . . . . . . . . . . . . . . . . . . . 83
Appendix B. Translation between RADIUS Prepaid and Diameter Appendix B. Translation between RADIUS Prepaid and Diameter
Credit Control . . . . . . . . . . . . . . . . . . . 81 Credit Control . . . . . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
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 20, line 50 skipping to change at page 21, line 50
The PPS calculates the cost of the requested service event, but it The PPS calculates the cost of the requested service event, but it
does not perform any account balance check or credit reservation from does not perform any account balance check or credit reservation from
the account. the account.
The estimated cost of the requested service event is returned to the The estimated cost of the requested service event is returned to the
PPS with a PPAQ in the Cost-Information SubType. The PPC may PPS with a PPAQ in the Cost-Information SubType. The PPC may
transfer the information to the end user as an advice of charge. transfer the information to the end user as an advice of charge.
More information regarding the price enquiry functionality is More information regarding the price enquiry functionality is
provided in Section 4.3.17 and in Section 4.3.19. provided in Section 4.3.15 and in Section 4.3.17.
2.7.4. Balance Check 2.7.4. Balance Check
The PPC may only have to verify that the end user's account balance The PPC may only have to verify that the end user's account balance
covers the cost of a certain service without reserving any units from covers the cost of a certain service without reserving any units from
the account at the time of the inquiry. This method does not the account at the time of the inquiry. This method does not
guarantee that credit would be left when the PPC requests the guarantee that credit would be left when the PPC requests the
debiting of the account with a separate request. debiting of the account with a separate request.
A PPC issues a PPAQ to the PPS including the Requested-Action SubType A PPC issues a PPAQ to the PPS including the Requested-Action SubType
skipping to change at page 21, line 26 skipping to change at page 22, line 26
Identifier or a Rating-Group-Identifer. Identifier or a Rating-Group-Identifer.
The PPS makes the balance check, but it does not make any credit- The PPS makes the balance check, but it does not make any credit-
reservation from the account. reservation from the account.
The result of balance check, namely "Success" (1) or "Failure" (2), The result of balance check, namely "Success" (1) or "Failure" (2),
is returned to the PPC in the Check-Balance-Result SubType conveyed is returned to the PPC in the Check-Balance-Result SubType conveyed
in the PPAQ attribute from the PPS to the PPC. in the PPAQ attribute from the PPS to the PPC.
More information regarding the balance check functionality is More information regarding the balance check functionality is
provided in Section 4.3.17 and in Section 4.3.18. provided in Section 4.3.15 and in Section 4.3.16.
2.7.5. Refund 2.7.5. Refund
Some services may refund service units to the end user's account; for Some services may refund service units to the end user's account; for
example, gaming services. example, gaming services.
To initiate refunding the PPC includes the PPAQ attribute in an To initiate refunding the PPC includes the PPAQ attribute in an
Access-Request packet and the amount (as a negative value) to be Access-Request packet and the amount (as a negative value) to be
refunded is specified using the Resource Quota and Resource Quota refunded is specified using the Resource Quota and Resource Quota
overflow subtypes. This functionality is similar to one-time overflow subtypes. This functionality is similar to one-time
skipping to change at page 32, line 15 skipping to change at page 33, line 15
4. Attributes 4. Attributes
This section specifies the attributes that implement the RADIUS This section specifies the attributes that implement the RADIUS
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 | VALUE ... | Type | Length | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... VALUE | Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Continuation | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
Type: Type:
PPAC (35) 26 for Vendor-Specific
Length: Length:
8 6 + 3 + length of SubTypes
VALUE : Vendor-Id:
The content of the subsequent fields are encoded using The Vendor-Id value for WiMAX is 24757.
the data type String.
The AvailableInClient (AiC) SubType is encoding as follows: Vendor type:
35 for PPAC
Vendor length:
3 + length of VALUE
Continuation:
The Continuation Field is defined as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|r|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
The C-bit of the continuation field indicates
if a attribute is being fragmented. When the
C-bit is set to one '1' this indicates that
the attribute is being fragmented that is
the next VSA of the same type is to be appended
to this attribute. When the C-bit is set to zero
'0' this indicates that the next attribute is
not a fragment of this attribute.
An attribute that is not being fragmented will
have the C-bit set to '0'. An attribute that is
being fragmented will have its C-bit set to '1'
for all fragments until the last fragment, which
will have its C-bit set to '0' indicating it's
the last fragment of the attribute. The r-bits
are reserved for future use. They SHALL be set
to zero by the sender and SHALL be ignored by
the receiver.
The value of the C-bit MUST be 0.
VALUE :
The content of the AvailableInClient (AiC) SubType fields
are encoded using the data type String.
Figure 8: PPAC Attribute
The AvailableInClient (AiC) SubType is encoding as follows:
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 | AvailableInClient (AiC) ... | SubType | LENGTH | AvailableInClient (AiC) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AvailableInClient (AiC) | | AvailableInClient (AiC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value (1) SubType : Value (1)
LENGTH : 6
LENGTH : 2 + 4
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
0x00000010 | Duration metering supported 0x00000010 | Duration metering supported
0x00000100 | Resource metering supported 0x00000100 | Resource metering supported
0x00001000 | Pools supported 0x00001000 | Pools supported
0x00010000 | Rating groups supported 0x00010000 | Rating groups supported
0x00100000 | Multi-Services supported 0x00100000 | Multi-Services supported
0x01000000 | Tariff Switch supported 0x01000000 | Tariff Switch supported
0x10000000 | Reserved 0x10000000 | Reserved
Figure 8: PPAC Attribute Figure 9: AvailableInClient (AiC) SubType
4.2. Session Termination Capability Attribute 4.2. Session Termination Capability Attribute
The Session Termination Capability attribute is included in the The Session Termination Capability attribute is included in the
RADIUS Access-Request message towards the RADIUS server to indicate RADIUS Access-Request message towards the RADIUS server to indicate
whether or not the NAS supports Dynamic Authorization. whether or not the NAS supports Dynamic 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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Continuation | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
Type: Type:
Session Termination Capability (36) 26 for Vendor-Specific
Length: Length:
4 6 + 3 + 4
Vendor-Id:
The Vendor-Id value for WiMAX is 24757.
Vendor type:
36 for Session Termination Capability
Vendor length:
3 + 4
Continuation:
The Continuation Field is defined as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|r|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
The C-bit of the continuation field indicates
if a attribute is being fragmented. When the
C-bit is set to one '1' this indicates that
the attribute is being fragmented that is
the next VSA of the same type is to be appended
to this attribute. When the C-bit is set to zero
'0' this indicates that the next attribute is
not a fragment of this attribute.
An attribute that is not being fragmented will
have the C-bit set to '0'. An attribute that is
being fragmented will have its C-bit set to '1'
for all fragments until the last fragment, which
will have its C-bit set to '0' indicating it's
the last fragment of the attribute. The r-bits
are reserved for future use. They SHALL be set
to zero by the sender and SHALL be ignored by
the receiver.
The value of the C-bit MUST be 0.
String: String:
This field is encoded as a bitmap. This field is encoded as a bitmap.
Value | Description Value | Description
---------------+------------------------------------- ---------------+-------------------------------------
0x00000001 | Dynamic Authorization Extensions (RFC 3576) 0x00000000 | Reserved
| is supported. 0x00000001 | Dynamic Authorization Extensions
... | All further values are reserved. | (RFC 3576) is supported.
... | All further values are reserved.
Figure 9: Session Termination Capability Attribute Figure 10: 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
skipping to change at page 35, line 11 skipping to change at page 37, line 46
Note: Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes Note: Either Volume-Quota, Time-Quota, or Resource-Quota SubTypes
MUST appear in the PPAQ attribute, except for the price enquiry MUST appear in the PPAQ attribute, except for the price enquiry
message 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, as shown in Figure 10, has a variable length The PPAQ attribute, as shown in Figure 11, has a variable length
(greater than 8, encoded into one octet), and consists of a variable (greater than 8, encoded into one octet), and consists of a variable
number of subtypes. Unused subtypes are omitted from the message. number of subtypes. Unused subtypes are omitted from the message.
The following table summarizes the presence of various SubTypes in
the PPAQ attribute carried in the Access-Request and Access-Accept
messages.
Request Accept # SubType Name
0-1(g) 0-1(m,n) 1 Quota Identifier
0-1(a,g) 0-1(a,k,n) 2 VolumeQuota
0 0-1(a,m,n) 3 VolumeThreshold
0-1(b,g) 0-1(b,k,n) 4 DurationQuota
0 0-1(b,m,n) 5 DurationThreshold
0-1(c,g) 0-1(c,k,n) 6 ResourceQuota
0 0-1(c,m,n) 7 ResourceThreshold
0-1(d,g) 0 8 Update-Reason
0-n(e,g) 0-n(e,m,n) 9 PrepaidServer
0-1(g,h,j) 0-1(m,n) 10 Service-ID
0-1(g,h,j) 0-1(m,n) 11 Rating-Group-ID
0 0-1(m,n) 12 Termination-Action
0 0-1(m,n) 13 Pool-ID
0 0-1(f,m,n) 14 Pool-Multiplier
0-1(g) 0 15 Requested-Action
0 0-1(k,m,n) 16 Check-Balance-Result
0 0-1(n) 17 Cost-Information
None of the above-listed SubTypes appears in the Access-Reject nor in
the Access-Challenge.
Notes:
(a) SHALL be present if volume based charging is used. SHALL NOT
be present otherwise. Volume- Threshold is optional.
(b) SHALL be present if duration-based charging is used. SHALL
NOT be present otherwise. Duration- Threshold is optional.
(c) SHALL be present if resource-based charging is used. SHALL
NOT be present otherwise. Resource- Threshold is optional.
(d) SHALL be present in an Authorize-Only Access-Request.
(e) MAY be present in an Access-Accept. If present in Access
Accept it SHALL be present in Access- Request (except for the
first Access-Request).
(f) Pool-Multiplier SHALL be present when Pool-ID is present
otherwise Pool-Multiplier SHALL NOT be present in the PPAQ.
(g) If Requested-Action is present then Service-ID SHALL also be
present and all other attributes SHALL NOT be present.
(h) PPAQ SHALL NOT contain both a Service-ID and a
Rating-Group-ID.
(j) A PPAQ that does not contain a Service-ID or a Rating-Group-Id
refers to the "Access Service"(ISF).
(k) If Balance-Check-Result is present and set to 0 then either
Volume-Quota, Duration-Quota or Resource- Quota SHALL be present.
(m) If Balance-Check-Result is present then Service-ID SHALL also
be present and other attributes (tagged with m) SHALL NOT be
present.
(n) The PPAQ in which a Cost-Information occurs SHALL NOT include
a Quota-Identifier, because no quota is actually reserved by the
PPS. The Service-ID SHALL be present with the Cost-Information
for that Service-ID may not be present if the Cost-Information
cannot be provided. All other attribute SHALL not appear.
In the following subsections the various subtypes of the PPAQ In the following subsections the various subtypes of the PPAQ
attribute are specified. attribute are specified.
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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... VALUE | Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Continuation | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
Type: Type:
PPAQ (37) 26 for Vendor-Specific
Length: Length:
variable (dependent on the specific sub-type) 6 + 3 + length of SubTypes
VALUE: Vendor-Id:
Data type String The Vendor-Id value for WiMAX is 24757.
Each subattribute is then encoded in the following style: Vendor type:
0 1 2 3 37 for PPAQ
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: Vendor length:
SubType : 3 + length of SubTypes
Contains an 8 bit unsigned integer. Continuation:
LENGTH : The Continuation Field is defined as follows:
Contains an 8 bit unsigned integer. 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|r|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
Figure 10: PPAQ Attribute Encoding Style The C-bit of the continuation field indicates
if a attribute is being fragmented. When the
C-bit is set to one '1' this indicates that
the attribute is being fragmented that is
the next VSA of the same type is to be appended
to this attribute. When the C-bit is set to zero
'0' this indicates that the next attribute is
not a fragment of this attribute.
An attribute that is not being fragmented will
have the C-bit set to '0'. An attribute that is
being fragmented will have its C-bit set to '1'
for all fragments until the last fragment, which
will have its C-bit set to '0' indicating it's
the last fragment of the attribute. The r-bits
are reserved for future use. They SHALL be set
to zero by the sender and SHALL be ignored by
the receiver.
The value of the C-bit MAY be 0 or 1.
VALUE:
Data type String
Each SubType 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.
The value of the LENGTH field is calculated as the length of the
VALUE field plus two octets (one octet for the length of the
SubType field and another octet for the length of the LENGTH
field).
Figure 11: PPAQ Attribute Encoding Style
4.3.1. Quota Identifier (QID) SubType 4.3.1. Quota Identifier (QID) SubType
The Quota Identifier (QID) is generated by the PPS and subsequently The Quota Identifier (QID) is generated by the PPS and subsequently
returned in a PPAQ->QID subtype from the PPC to the PPS. This field returned in a PPAQ->QID subtype from the PPC to the PPS. This field
has the semantic of a transaction identifier and therefore changes has the semantic of a transaction identifier and therefore changes
with every transaction initiated by the PPS to the PPC. with every transaction initiated by the PPS to the PPC.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE | | VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(1) SubType : Value(1)
LENGTH : 6 LENGTH : 2 + length of VALUE field.
VALUE : Data type String VALUE : Data type String
Quota Identifier (QID) SubType Quota Identifier (QID) SubType
4.3.2. VolumeQuota SubType 4.3.2. VolumeQuota SubType
TVolumeQuota SubType is only present when volume-based charging is TVolumeQuota SubType is only present when volume-based charging is
used. In a RADIUS Access-Accept message (PPS to PPC direction), it used. In a RADIUS Access-Accept message (PPS to PPC direction), it
indicates the volume (in octets) allocated for the session by the indicates the volume (in octets) allocated for the session by the
PPS. In a RADIUS Authorize-Only Access-Request message (PPC to PPS PPS. In a RADIUS Authorize-Only Access-Request message (PPC to PPS
direction), it indicates the totally used volume (in octets) for both direction), it indicates the totally used volume (in octets) for both
inbound and outbound traffic. The Exponent SubType, if present, MUST inbound and outbound traffic. The Exponent Field, if present, MUST
NOT encode a negative number or zero. NOT encode a negative number or zero.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(2) SubType : Value(2)
LENGTH : variable (8 or 14) LENGTH : 2 + (8 or 12)
VALUE : Data type String VALUE : Data type String
The content of the VALUE field either contains the The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the Value-Digits Field (8 octets long) or the Value-Digits Field
Exponent SubType. The length field indicates whether one or plus the Exponent Field (12 octets long).
both subtypes are included.
VolumeQuota SubType 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 10 or 14 octets. This SubType is optionally present if its length is 10 or 14 octets. This SubType is optionally present if
the VolumeQuota is present in a RADIUS Access-Accept message (PPS to the VolumeQuota is present in a RADIUS Access-Accept message (PPS to
PPC direction). It is generated by the PPS and indicates the volume PPC direction). It is generated by the PPS and indicates the volume
(in 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 Exponent This threshold MUST NOT be larger than the VolumeQuota. The Exponent
SubType, if present, MUST NOT encode a negative number or zero. Field, if present, MUST NOT encode a negative number or zero.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(3) SubType : Value(3)
LENGTH : variable (8 or 14) LENGTH : 2 + (8 or 12)
VALUE : Data type String VALUE : Data type String
The content of the VALUE field either contains the The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the Value-Digits Field (8 octets long) or the Value-Digits
Exponent SubType. The length field indicates whether one or SubType plus the Exponent Field 12 octets long).
both subtypes are included.
VolumeThreshold SubType VolumeThreshold SubType
4.3.4. DurationQuota SubType 4.3.4. DurationQuota SubType
The optional DurationQuota SubType is only present if duration-based The optional DurationQuota SubType is only present if duration-based
charging is used. In a RADIUS Access-Accept message (PPS to PPC charging is used. In a RADIUS Access-Accept message (PPS to PPC
direction), it indicates the duration (in seconds) allocated for the direction), it indicates the duration (in seconds) allocated for the
session by the PPS. In a RADIUS Access-Request message (PPC to PPS session by the PPS. In a RADIUS Access-Request message (PPC to PPS
direction), it indicates the total duration (in seconds) since the direction), it indicates the total duration (in seconds) since the
skipping to change at page 39, line 17 skipping to change at page 43, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ... | SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE | | VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(4) SubType : Value(4)
LENGTH : 6 LENGTH : 2 + 4
VALUE : Data type string. VALUE : Data type string.
The content of this field contains a 32-bit unsigned integer The content of this field contains a 32-bit unsigned integer
(with the values 0 to +4,294,967,295). (with the values 0 to +4,294,967,295).
DurationQuota SubType DurationQuota SubType
4.3.5. DurationThreshold SubType 4.3.5. DurationThreshold SubType
skipping to change at page 39, line 46 skipping to change at page 44, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE ... | SubType | LENGTH | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE | | VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(5) SubType : Value(5)
LENGTH : 6 LENGTH : 2 + 4
VALUE : Data type string. VALUE : Data type string.
The content of this field contains a 32-bit unsigned integer The content of this field contains a 32-bit unsigned integer
(with the values 0 to +4,294,967,295). (with the values 0 to +4,294,967,295).
DurationThreshold SubType DurationThreshold SubType
4.3.6. ResourceQuota SubType 4.3.6. ResourceQuota SubType
The optional ResourceQuota SubType is only present if resource-based The optional ResourceQuota SubType is only present if resource-based
or one-time charging is used. In the RADIUS Access-Accept message or one-time charging is used. In the RADIUS Access-Accept message
(PPS to PPC direction) it indicates the resources allocated for the (PPS to PPC direction) it indicates the resources allocated for the
session by the PPS. In RADIUS Authorize-Only Access-Request message session by the PPS. In RADIUS Authorize-Only Access-Request message
(PPC to PPS direction), it indicates the resources used in total, (PPC to PPS direction), it indicates the resources used in total,
including both incoming and outgoing chargeable traffic. In one-time including both incoming and outgoing chargeable traffic. In one-time
charging scenarios, the subtype represents the number of units to charging scenarios, the subtype represents the number of units to
charge the user. The attribute consists of a Value-Digits SubType charge the user. The attribute consists of a Value-Digits Field and
and optionally an Exponent SubType (as indicated by the length optionally an Exponent Field (as indicated by the length field).
field).
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(6) SubType : Value(6)
LENGTH : variable (8 or 14) LENGTH : 2 + (8 or 12)
VALUE : Data type String VALUE : Data type String
The content of the VALUE field either contains the The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the Value-Digits Field (8 octets long) or the Value-Digits Field
Exponent SubType. The length field indicates whether one or plus the Exponent Field (12 octets long).
both subtypes are included.
ResourceQuota SubType ResourceQuota SubType
4.3.7. ResourceThreshold SubType 4.3.7. ResourceThreshold SubType
The semantic of the ResourceThreshold SubType follow those of the The semantic of the ResourceThreshold SubType follow those of the
VolumeThreshold and DurationThreshold SubType. VolumeThreshold and DurationThreshold SubType.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(7) SubType : Value(7)
LENGTH : variable (8 or 14) LENGTH : 2 + (8 or 12)
VALUE : Data type String VALUE : Data type String
The content of the VALUE field either contains the The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the Value-Digits Field (8 octets long) or the Value-Digits Field
Exponent SubType. The length field indicates whether one or plus the Exponent Field (12 octets long).
both subtypes are included.
ResourceThreshold SubType ResourceThreshold SubType
4.3.8. Value-Digits SubType 4.3.8. Update-Reason SubType
The Value-Digits SubType encodes the most significant digits of a
number, encoded as an integer. If decimal values are needed to
present the number, the scaling MUST be indicated with a 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 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(18)
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
The Exponent SubType contains the exponent value that is to be
applied to the accompanying Value-Digit SubType.
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(19)
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
The Update-Reason SubType is present in a RADIUS Access-Request The Update-Reason SubType is present in a RADIUS Access-Request
message (PPC to PPS direction) and indicates the reason for message (PPC to PPS direction) and indicates the reason for
initiating the quota update operation. Update reasons (6), (7), (8) initiating the quota update operation. Update reasons (6), (7), (8)
and (9) indicate that the associated resources are released at the and (9) indicate that the associated resources are released at the
PPC side, and that therefore the PPS MUST NOT allocate a new quota in PPC side, and that therefore the PPS MUST NOT allocate a new quota in
the RADIUS Access-Accept message. the RADIUS Access-Accept message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | VALUE | | SubType | LENGTH | VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(8) SubType : Value(8)
LENGTH : 4 LENGTH : 2 + 1
VALUE : Data type string VALUE : Data type string
This field contains a 16-bit unsigned integer This field contains a byte
(with the values 0 to +65,535). (with the values 0 to 255).
Update-Reason SubType 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...65,535 | **Available for IANA registration** 11...255 | **Available for IANA registration**
Figure 11: Values for Update-Reason SubType Figure 12: Values for Update-Reason SubType
4.3.11. PrepaidServer SubType 4.3.9. PrepaidServer SubType
The optional PrepaidServer SubType indicates the address of the The optional PrepaidServer 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. subtype MAY be present in a single PPAQ attribute.
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.
skipping to change at page 44, line 27 skipping to change at page 47, line 27
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 | Address ... | SubType | LENGTH | Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(9) SubType : Value(9)
LENGTH : variable (6 or 14) LENGTH : 2 + (4 or 16)
Address : Data type String Address : Data type String
For IPv4, the Address field is 4 octets based on the encoding of 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 the NAS-IP-Address defined in RFC 2138. For IPv6, the Address
field is 16 octets long. field is 16 octets long.
PrepaidServer SubType PrepaidServer SubType
4.3.12. Service-ID SubType 4.3.10. Service-ID SubType
The Service-ID SubType is handled as an opaque string that uniquely The Service-ID SubType is handled as an opaque string that uniquely
describes the service instance for which prepaid metering should be describes the service instance for which prepaid metering should be
applied. 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
skipping to change at page 45, line 15 skipping to change at page 48, line 15
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 | Service ... | SubType | LENGTH | Service ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(10) SubType : Value(10)
LENGTH : variable LENGTH : 2 + length (Service)
Service : Data type String Service : Data type String
Service-ID SubType Service-ID SubType
4.3.13. Rating-Group-ID SubType 4.3.11. Rating-Group-ID SubType
The Rating-Group-ID SubType indicates that this PPAQ attribute is The Rating-Group-ID SubType indicates that this PPAQ attribute is
associated with resources allocated to a Rating Group with the associated with resources allocated to a Rating Group with the
corresponding ID. This SubType is encoded as a string. A single corresponding ID. This SubType is encoded as a string. A single
PPAQ MUST NOT contain more than one Rating-Group-ID. PPAQ MUST NOT contain more than one Rating-Group-ID.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VALUE | | VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(11) SubType : Value(11)
LENGTH : 6 LENGTH : 2 + 4
VALUE : Data type string VALUE : Data type string with a length of 4 octets
Rating-Group-ID SubType Rating-Group-ID SubType
4.3.14. Termination-Action SubType 4.3.12. 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType | LENGTH | Action | | SubType | LENGTH | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(12) SubType : Value(12)
LENGTH : 3 LENGTH : 2 + 1
Action : Data type string. Action : Data type string.
The content is an 8 bit unsigned integer (with the values 0 to +255). The content is a byte (with the values 0 to +255).
Termination-Action SubType 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 12: Values for the Termination-Action SubType Figure 13: Values for the Termination-Action SubType
4.3.15. Pool-ID SubType 4.3.13. Pool-ID SubType
The Pool-ID SubType identifies the resource pool. It is encoded as a The Pool-ID SubType identifies the resource pool. It is encoded as a
string. string.
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 | Poolid | | SubType | LENGTH | Poolid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(13) SubType : Value(13)
LENGTH : 6 LENGTH : 2 + 4
Poolid : Data type string Poolid : Data type string with length of 4 octets.
Pool-ID SubType Pool-ID SubType
4.3.16. Pool-Multiplier SubType 4.3.14. Pool-Multiplier SubType
The Pool-Multiplier SubType determines the weight of resources when The Pool-Multiplier SubType determines the weight of resources when
they are inserted into the pool that is identified by the they are inserted into the pool that is identified by the
accompanying Pool-ID SubType, and the rate at which resources are accompanying Pool-ID SubType, and the rate at which resources are
taken out of the pool by the relevant Service or Rating-Group. taken out of the pool by the relevant Service or Rating-Group.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(14) SubType : Value(14)
LENGTH : variable (8 or 14) LENGTH : 2 + (8 or 12)
VALUE : Data type String VALUE : Data type String
The content of the VALUE field either contains the The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the Value-Digits Field (8 octets long) or the Value-Digits Field
Exponent SubType. The length field indicates whether one or plus the Exponent Field (12 octets long).
both subtypes are included.
Pool-Multiplier SubType Pool-Multiplier SubType
4.3.17. Requested-Action SubType 4.3.15. Requested-Action SubType
The Requested-Action SubType is only be present in messages sent from The Requested-Action SubType is only be present in messages sent from
the PPC to the PPS. It indicates that the PPC desires the PPS to the PPC to the PPS. It indicates that the PPC desires the PPS to
perform the indicated action and to return the result. The PPAQ in perform the indicated action and to return the result. The PPAQ in
which a Requested-Action SubType occurs MUST NOT contain a QID, and which a Requested-Action SubType occurs MUST NOT contain a QID, and
MUST contain a Service-Identifier or a Rating-Group-Identifer that MUST contain a Service-Identifier or a Rating-Group-Identifer that
allows the PPS to uniquely identify the service for which the allows the PPS to uniquely identify the service for which the
indicated action is requested. indicated action is requested.
0 1 2 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 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 | | SubType | LENGTH | Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(15) SubType : Value(15)
LENGTH : 3 LENGTH : 2 + 1
Action : Data type string. Action : Data type string.
The content is a 8 bit unsigned integer (with the values 0 to +255) The content is a byte (with the values 0 to +255).
with the values listed below. The values are listed below.
Requested-Action SubType Requested-Action SubType
The following values for the Action field of the Requested-Action The following values for the Action field of the Requested-Action
SubType are defined: 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 13: Values for the Requested-Action SubType Figure 14: Values for the Requested-Action SubType
4.3.18. Check-Balance-Result SubType 4.3.16. Check-Balance-Result SubType
The Check-Balance-Result SubType can only be present in messages sent The Check-Balance-Result SubType can only be present in messages sent
from the PPS to the PPC. It indicates the balance check decision of from the PPS to the PPC. It indicates the balance check decision of
the PPS about a previously received Balance Check Request (as the PPS about a previously received Balance Check Request (as
indicated in a Requested-Action SubType). The PPAQ attribute in indicated in a Requested-Action SubType). The PPAQ attribute in
which a Check-Balance-Result occurs MUST NOT include a QID beause no which a Check-Balance-Result occurs MUST NOT include a QID beause no
quota is reserved by the PPS. quota is reserved by the PPS.
0 1 2 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 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 | | SubType | LENGTH | Decision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(16) SubType : Value(16)
LENGTH : 3 LENGTH : 2 + 1
Decision : Data type string. Decision : Data type string.
The content is a 8 bit unsigned integer (with the values 0 to +255) The content is a byte (with the values 0 to +255).
with the values listed below. The values are listed below.
Check-Balance-Result SubType Check-Balance-Result SubType
The following values for the Decision field of the Check-Balance- The following values for the Decision field of the Check-Balance-
Result SubType are defined: 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 14: Values for the Check-Balance-Result SubType Figure 15: Values for the Check-Balance-Result SubType
4.3.19. Cost-Information SubType 4.3.17. Cost-Information SubType
The Cost-Information SubType is used in order to return the cost The Cost-Information SubType is used in order to return the cost
information of a service, which the PPC can transfer transparently to information of a service, which the PPC can transfer transparently to
the end user. This SubType is sent from the PPS to the PPC as a the end user. This SubType is sent from the PPS to the PPC as a
response to a "Price Enquiry", as indicated by the Requested-Action response to a "Price Enquiry", as indicated by the Requested-Action
SubType. SubType.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(17) SubType : Value(17)
LENGTH : variable LENGTH : 2 + 12 + 4 + length of the Cost-Unit Field
VALUE : Data type String VALUE : Data type String
The content of the VALUE field contains (in this order) the The content of the VALUE field contains (in this order) the
Value-Digits SubType, followed by the Value-Digits Field, Exponent Field, Currency-Code Field
Exponent SubType, Currency-Code SubType and the Cost-Unit SubType. and the Cost-Unit Field.
Cost-Information SubType Cost-Information SubType
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 = 454, 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 Field is of type Unsigned32 and used inside the
Check-Balance-Result SubType and contains a currency code that
The Currency-Code SubType is used inside the Check-Balance-Result specifies in which currency the values of AVPs containing monetary
SubType and contains a currency code that specifies in which currency units were given. It is specified by using the numeric values
the values of AVPs containing monetary units were given. It is defined in the ISO 3166-1 standard.
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(20)
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 The Cost-Unit Field is used inside the Check-Balance-Result SubType
and contains a human readable UTF8 encoded string that can be and contains a human readable UTF8 encoded string that can be
displayed to the end user. It specifies the applicable unit to the 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 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 of the service is $1 per minute). The Cost-Unit can, for example, be
minutes, hours, days, kilobytes, megabytes, etc. minutes, hours, days, kilobytes, megabytes, etc.
0 1 2 3 4.4. Fields
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: 4.4.1. Value-Digits Field
SubType : Value(22) The Value-Digits Field is an Unsigned64 value (with a length of 8
octets) that contains the significant digits of the number. If
decimal values are needed to present the number, the scaling MUST be
indicated with a related Exponent Field, see Section 4.4.2.
LENGTH : variable For example, the decimal number 0.05 is encoded by a Value-Digits
Field set to 5, and a scaling that is indicated with the Exponent
Field set to -2.
VALUE : Data type String The encoding of this SubType is not done in an TLV format but rather
the encoded value is added to existing subtypes.
The content of the VALUE field contains a UTF8 encoded string. 4.4.2. Exponent Field
Cost-Unit SubType The Exponent field is a Integer32 value that contains the exponent
value that is to be applied to the accompanying Value-Digit Field.
4.4. Prepaid Tariff Switching (PTS) Attribute 4.5. 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.
If a RADIUS message contains a PTS attribute, it MUST also contain at If a RADIUS message contains a PTS attribute, it MUST also contain at
skipping to change at page 52, line 40 skipping to change at page 54, line 52
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 15, contains a number of other The following table summarizes the presence of various SubTypes in
subtypes which are specified in the following subsections. the PTS attribute carried in the Access-Request and Access-Accept
messages.
0 1 2 3 Request Accept # SubType Name
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 1 1 1 Quota Identifier
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 0 2 VolumeUsedAfterTariffSwitch
| Type | Length | VALUE ... 0 0-1 3 TarrifSwitchInterval
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 0-1(a) 4 TimeIntervalAfterTarriffSwitchUpdate
... VALUE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : PTS (38) None of the above-listed SubTypes appears in the Access-Reject nor in
the Access-Challenge.
Length: variable Notes:
(a) The PPS SHALL include this AVP if there is another tariff
switch period after the period that ends as indicated by the TSI
attribute.
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 | Vendor-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Continuation | VALUE ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The fields have the following meaning and encoding:
Type:
26 for Vendor-Specific
Length:
6 + 3 + length of SubTypes
Vendor-Id:
The Vendor-Id value for WiMAX is 24757.
Vendor type:
38 for PTS
Vendor length:
3 + length of SubTypes
Continuation:
The Continuation Field is defined as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|r|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
The C-bit of the continuation field indicates
if a attribute is being fragmented. When the
C-bit is set to one '1' this indicates that
the attribute is being fragmented that is
the next VSA of the same type is to be appended
to this attribute. When the C-bit is set to zero
'0' this indicates that the next attribute is
not a fragment of this attribute.
An attribute that is not being fragmented will
have the C-bit set to '0'. An attribute that is
being fragmented will have its C-bit set to '1'
for all fragments until the last fragment, which
will have its C-bit set to '0' indicating it's
the last fragment of the attribute. The r-bits
are reserved for future use. They SHALL be set
to zero by the sender and SHALL be ignored by
the receiver.
The value of the C-bit MAY be 0 or 1.
VALUE : Variable length content of data type String containing VALUE : Variable length content of data type String containing
one or multiple SubTypes. 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 ...
skipping to change at page 53, line 42 skipping to change at page 57, line 15
Contains an 8 bit unsigned integer. Contains an 8 bit unsigned integer.
LENGTH: LENGTH:
Contains an 8 bit unsigned integer. Contains an 8 bit unsigned integer.
VALUE: VALUE:
Contains the content of the SubType. Contains the content of the SubType.
Figure 15: PTS Attribute Figure 16: PTS Attribute
4.4.1. VolumeUsedAfterTariffSwitch SubType 4.5.1. VolumeUsedAfterTariffSwitch SubType
The optional VolumeUsedAfterTariffSwitch (VUATS) SubType is used in The optional VolumeUsedAfterTariffSwitch (VUATS) SubType is 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. accompanying PPAQ attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 54, line 20 skipping to change at page 57, line 40
The fields have the following meaning and encoding: The fields have the following meaning and encoding:
SubType : Value(23) SubType : Value(23)
LENGTH : variable (8 or 14) LENGTH : variable (8 or 14)
VALUE : Data type String VALUE : Data type String
The content of the VALUE field either contains the The content of the VALUE field either contains the
Value-Digits SubType or the Value-Digits SubType plus the Value-Digits Field or the Value-Digits Field plus the
Exponent SubType. The length field indicates whether one or Exponent Field. The length field indicates whether one or
both subtypes are included. both subtypes are included.
VolumeUsedAfterTariffSwitch SubType VolumeUsedAfterTariffSwitch SubType
4.4.2. TariffSwitchInterval SubType 4.5.2. TariffSwitchInterval SubType
The TariffSwitchInterval (TSI) SubType MUST be present in each PTS The TariffSwitchInterval (TSI) SubType MUST be present in each PTS
attribute that is part of a RADIUS Access-Accept message (PPS to PPC attribute 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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 55, line 8 skipping to change at page 58, line 29
LENGTH : 6 LENGTH : 6
VALUE : Data type string VALUE : Data type string
This field contains a 16-bit unsigned integer This field contains a 16-bit unsigned integer
(with the values 0 to +65,535). (with the values 0 to +65,535).
TariffSwitchInterval SubType TariffSwitchInterval SubType
4.4.3. TimeIntervalafterTariffSwitchUpdate SubType 4.5.3. TimeIntervalafterTariffSwitchUpdate SubType
The PPS MUST include TimeIntervalafterTariffSwitchUpdate (TITSU) The PPS MUST include TimeIntervalafterTariffSwitchUpdate (TITSU)
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 contains the number of seconds of the tariff period that SubType contains the number of seconds of the tariff period that
begins immediately after the period that ends as indicated by the TSI begins immediately after the period that ends as indicated by the TSI
attribute. If the TITSU SubType is not present, the PPC assumes that attribute. If the TITSU SubType is not present, the PPC assumes that
the tariff period, which ends as indicated by the TSI SubType, lasts the tariff period, which ends as indicated by the TSI SubType, lasts
until further notice. If TITSU is specified, the PPC MUST send a until further notice. If TITSU is specified, the PPC MUST send a
quota update before the point in time specified by the TITSU SubType quota update before the point in time specified by the TITSU SubType
skipping to change at page 60, line 32 skipping to change at page 64, line 32
7 | ResourceThreshold 7 | ResourceThreshold
8 | Update-Reason 8 | Update-Reason
9 | PrepaidServer 9 | PrepaidServer
10 | Service-ID 10 | Service-ID
11 | Rating-Group-ID 11 | Rating-Group-ID
12 | Termination-Action 12 | Termination-Action
13 | Pool-ID 13 | Pool-ID
14 | Pool-Multiplier 14 | Pool-Multiplier
15 | Requested-Action 15 | Requested-Action
16 | Check-Balance-Result 16 | Check-Balance-Result
17 | Cost-Information 17..255 | **Available for IANA registration**
18 | Value-Digits
19 | Exponent
20 | CurrencyCode
21 | Cost-Unit
22..255 | **Available for IANA registration**
The semantic of the above-listed SubTypes is described in The semantic of the above-listed SubTypes is described in
Section 4.3. Section 4.3.
Following the policies outline in [RFC3575] the available SubTypes Following the policies outline in [RFC3575] the available SubTypes
(i.e., value 0 and values 22-255) with a description of their (i.e., value 0 and values 22-255) with a description of their
semantic will be assigned after the expert review process. Updates semantic will be assigned after the expert review process. Updates
can be provided based on expert approval only. Based on expert can be provided based on expert approval only. Based on expert
approval it is possible to mark entries as "deprecated". A approval it is possible to mark entries as "deprecated". A
designated expert will be appointed by the IESG. designated expert will be appointed by the IESG.
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.4. New Registry: PTS SubTypes 8.4. New Registry: PTS SubTypes
Section 4.4 defines the SubTypes used within the PTS attribute. IANA Section 4.5 defines the SubTypes used within the PTS attribute. IANA
is asked to create a registry for these SubTypes. Each registry 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
PTS SubType. This document creates the following PTS SubTypes for PTS SubType. This document creates the following PTS SubTypes for
this registry: this registry:
Value | SubType Name Value | SubType Name
---------+----------------------------- ---------+-----------------------------
0 | Reserved 0 | Reserved
1 | Quota Identifier 1 | Quota Identifier
2 | VolumeUsedAfterTariffSwitch 2 | VolumeUsedAfterTariffSwitch
3 | TariffSwitchInterval 3 | TariffSwitchInterval
4 | TimeIntervalafterTariffSwitchUpdate 4 | TimeIntervalafterTariffSwitchUpdate
5..255 | **Available for IANA registration** 5..255 | **Available for IANA registration**
The semantic of the above-listed SubTypes is described in The semantic of the above-listed SubTypes is described in
Section 4.4. Section 4.5.
Following the policies outline in [RFC3575] the available SubTypes Following the policies outline in [RFC3575] the available SubTypes
(i.e., value 0 and values 5-255) with a description of their semantic (i.e., value 0 and values 5-255) with a description of their semantic
will be assigned after the expert review process. Updates can be will be assigned after the expert review process. Updates can be
provided based on expert approval only. Based on expert approval it provided based on expert approval only. Based on expert approval it
is possible to mark entries as "deprecated". A designated expert is possible to mark entries as "deprecated". A designated expert
will be appointed by the IESG. will be appointed by the IESG.
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.5. New Registry: Update-Reason 8.5. New Registry: Update-Reason
Section 4.3.10 defines the Update-Reason SubType. IANA is asked to Section 4.3.8 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 11. Each registry entry consists of a 16 SubType, as shown in Figure 12. 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
the expert review process. Updates can be provided based on expert the expert review process. Updates can be provided based on expert
approval only. Based on expert approval it is possible to mark approval only. Based on expert approval it is possible to mark
entries as "deprecated". A designated expert will be appointed by entries as "deprecated". A designated expert will be appointed by
the IESG. the IESG.
8.6. New Registry: Termination-Action 8.6. New Registry: Termination-Action
Section 4.3.14 defines the Termination-Action SubType. IANA is asked Section 4.3.12 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 12. Each registry entry consists Action SubType, as shown in Figure 13. 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
the expert review process. Updates can be provided based on expert the expert review process. Updates can be provided based on expert
approval only. Based on expert approval it is possible to mark approval only. Based on expert approval it is possible to mark
entries as "deprecated". A designated expert will be appointed by entries as "deprecated". A designated expert will be appointed by
the IESG. the IESG.
8.7. New Registry: Requested-Action 8.7. New Registry: Requested-Action
Section 4.3.17 defines the Requested-Action SubType. IANA is asked Section 4.3.15 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 13. Each registry entry consists of a 8 SubType, as shown in Figure 14. 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
the expert review process. Updates can be provided based on expert the expert review process. Updates can be provided based on expert
approval only. Based on expert approval it is possible to mark approval only. Based on expert approval it is possible to mark
entries as "deprecated". A designated expert will be appointed by entries as "deprecated". A designated expert will be appointed by
the IESG. the IESG.
8.8. New Registry: Check-Balance-Result 8.8. New Registry: Check-Balance-Result
Section 4.3.18 defines the Check-Balance-Result SubType. IANA is Section 4.3.16 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 14. Each registry entry Balance-Result SubType, as shown in Figure 15. 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
the expert review process. Updates can be provided based on expert the expert review process. Updates can be provided based on expert
approval only. Based on expert approval it is possible to mark approval only. Based on expert approval it is possible to mark
entries as "deprecated". A designated expert will be appointed by entries as "deprecated". A designated expert will be appointed by
the IESG. the IESG.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Christian Guenther, Bernard Aboba, The authors would like to thank Bernard Aboba, Christian Guenther,
and John Loughney for their feedback throughout the development of Dirk Kroeselberg and John Loughney for their feedback throughout the
this document. Additionally, the authors would like to thank the development of this document. Additionally, the authors would like
members of the Wimax Forum and the members of 3GPP2 for their help to thank the members of the Wimax Forum and the members of 3GPP2 for
with this specification. 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.
[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Adoba, "RFC 3576: Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service (RADIUS)",
February 2003.
10.2. Informative References 10.2. Informative References
[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 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999. 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.
Adoba, "RFC 3576: Dynamic Authorization Extensions to
Remote Authentication Dial-In User Service (RADIUS)",
February 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
"IEEE 802.1X Remote Authentication Dial In User Service "IEEE 802.1X Remote Authentication Dial In User Service
(RADIUS) Usage Guidelines", RFC 3580, September 2003. (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",
skipping to change at page 67, line 25 skipping to change at page 71, 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 16: A simple example message flow Figure 17: 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 70, line 21 skipping to change at page 74, line 21
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 17: Example message flow with Tariff Switch Figure 18: 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 74, line 36 skipping to change at page 78, 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 18: Example message flow with resource pools and rating groups Figure 19: 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 78, line 25 skipping to change at page 82, 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 19: Example message flow with one-time charging Figure 20: 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 79, line 28 skipping to change at page 83, 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 20: Example message flow with price enquiry (advice of charge) Figure 21: 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 80, line 22 skipping to change at page 84, 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 21: Example message flow with balance check Figure 22: 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. 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
skipping to change at page 90, line 16 skipping to change at page 94, line 16
Avi Lior Avi Lior
Bridgewater Systems Bridgewater Systems
303 Terry Fox Drive 303 Terry Fox Drive
Ottawa, Ontario Suite 100 Ottawa, Ontario Suite 100
Canada Canada
Email: avi@bridgewatersystems.com Email: avi@bridgewatersystems.com
Parviz Yegani Parviz Yegani
Cisco Juniper
Mobile Wireless Group, Cisco Systems
3625 Cisco Way, San Jose, California 95134
USA
Email: pyegani@cisco.com Email: pyegani@juniper.net
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Starent Networks
30 International Place, 3rd Floor 30 International Place, 3rd Floor
Tewksbury, MA 01876 Tewksbury, MA 01876
USA USA
Email: kchowdhury@starentnetworks.com Email: kchowdhury@starentnetworks.com
Hannes Tschofenig Hannes Tschofenig
skipping to change at page 90, line 47 skipping to change at page 94, line 44
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at 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: pashalidis@gmail.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 141 change blocks. 
365 lines changed or deleted 559 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/