< draft-tschofenig-radext-qos-00.txt   draft-tschofenig-radext-qos-01.txt >
RADIUS EXTensions (radext) H. Tschofenig RADIUS EXTensions (radext) H. Tschofenig
Internet-Draft Siemens Internet-Draft Siemens
Expires: January 12, 2006 A. Mankin Expires: January 19, 2006 A. Mankin
Shinkuro, Inc Shinkuro, Inc
T. Tsenov T. Tsenov
Siemens Siemens
A. Lior A. Lior
Bridgewater Systems Bridgewater Systems
July 11, 2005 July 18, 2005
RADIUS Quality of Service Support RADIUS Quality of Service Support
draft-tschofenig-radext-qos-00.txt draft-tschofenig-radext-qos-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 12, 2006. This Internet-Draft will expire on January 19, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes an extension to the RADIUS protocol that This document describes an extension to the RADIUS protocol that
performs authentication, authorization, and accounting for Quality- performs authentication, authorization, and accounting for Quality-
of-Service reservations. of-Service reservations.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Flexibility is provided by offering support for different Flexibility is provided by offering support for different
authorization models and by decoupling specific QoS attributes authorization models and by decoupling specific QoS attributes
carried in the QoS signaling protocol from the AAA protocol. This carried in the QoS signaling protocol from the AAA protocol. This
document is the RADIUS complement to the DIAMETER QoS application. document is the RADIUS complement to the DIAMETER QoS application.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. QoS Authorization for a Session . . . . . . . . . . . . . . . 6 4. RADIUS functional considerations . . . . . . . . . . . . . . . 6
4.1 Session Establishment . . . . . . . . . . . . . . . . . . 6 5. Authorization and QoS parameter provision . . . . . . . . . . 7
4.2 QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 6 5.1 QoS enabled initial access authentication and
4.2.1 Client-side initiated Re-Authorization . . . . . . . . 6 authorization . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2 Server-side initiated Re-Authorization . . . . . . . . 7 5.2 Mid-Session QoS authorization . . . . . . . . . . . . . . 8
4.3 Session Termination . . . . . . . . . . . . . . . . . . . 7 5.2.1 Client-side initiated QoS
4.3.1 Client-side initiated session termination . . . . . . 7 authorization/re-authorization . . . . . . . . . . . . 8
4.3.2 Server-side initiated session termination . . . . . . 7 5.2.2 Server-side initiated Re-Authorization . . . . . . . . 8
5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3 Session Termination . . . . . . . . . . . . . . . . . . . 9
6. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3.1 Client-side initiated session termination . . . . . . 9
6.1 QSPEC Attribute . . . . . . . . . . . . . . . . . . . . . 9 5.3.2 Server-side initiated session termination . . . . . . 9
6.2 Flow Identification . . . . . . . . . . . . . . . . . . . 14 6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3 Authorization Objects . . . . . . . . . . . . . . . . . . 15 7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 16 7.1 QSPEC Attribute . . . . . . . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2 Flow Identification . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.3 Authorization Objects . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 19 8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1 Normative References . . . . . . . . . . . . . . . . . . . 20 9.1 RADIUS authorization of a QoS signaling reservation
11.2 Informative References . . . . . . . . . . . . . . . . . . 20 request . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 9.2 RADIUS authentication, authorization and management of
Intellectual Property and Copyright Statements . . . . . . . . 23 a QoS-enabled access session . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . 24
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1 Normative References . . . . . . . . . . . . . . . . . . . 26
12.2 Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29
1. Introduction 1. Introduction
To meet the quality-of-service needs of applications such as voice- To meet the quality-of-service needs of applications such as voice-
over-IP, it will often be necessary to explicitly request resources over-IP, it will often be necessary to explicitly request resources
from the network. This will allow the network to identify packets from the network. This will allow the network to identify packets
belonging to these application flows and ensure that bandwidth, belonging to these application flows and ensure that bandwidth,
delay, and error rate requirements are met. delay, and error rate requirements are met.
This document is a complement to the ongoing work of the DIAMETER QoS This document is a complement to the ongoing work of the DIAMETER QoS
skipping to change at page 5, line 7 skipping to change at page 5, line 7
the requirements defined in [13]. the requirements defined in [13].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [5]. document are to be interpreted as described in RFC-2119 [5].
3. Goals 3. Goals
This document has a few ambitious goals, namely: This document has a few ambitious, namely:
o Decouple the QoS signaling protocol (such as NSIS, RSVP or link o Decouple the QoS signaling protocol (such as NSIS, RSVP or link
layer QoS signaling protocols) from the AAA protocol. This goal layer QoS signaling protocols) from the AAA protocol. This goal
is accomplished with the help of a generic QoS description, the is accomplished with the help of a generic QoS description, the
QSPEC object. QSPEC object.
o Support for different scenarios that demand authorization for QoS o Support for different scenarios that demand authorization for QoS
reservations. The impact is to provide flexibility with regard to reservations. The impact is to provide flexibility with regard to
the entities that trigger the QoS reservation, the QoS parameters the entities that trigger the QoS reservation, the QoS parameters
that need to be provided to the RADIUS server for authorization, that need to be provided to the RADIUS server for authorization,
the granularity of the QoS reservation (e.g., for an individual the granularity of the QoS reservation (e.g., for an individual
application flow, for an aggregate). application flow, for an aggregate).
4. QoS Authorization for a Session 4. RADIUS functional considerations
A request from a Quality of Service enabled RADIUS clietn starts a Being a value-added service, QoS provisioning SHOULD go along with
RADIUS message exchange. The identity of the user, and depending on explicit authorization, accounting and control over the QoS-featured
the scenario, the identity of the QoS authorizing application server user session. Specifically, the management of the authorized session
and optional session identification information, are assembled into a with Session-Timeout(27) and Termination-Action(29) attributes raises
RADIUS Access-Request message by the AAA client responsible for a number of issues, identified in [14]. The solution presented in
resource allocation and sent to a AAA server either co-located with this document aims to allow explicit control by the RADIUS server
an application server, to the local AAA server or to the RADIUS (Authorizing entity) over the authorization session and its
server in the user's home realm. parameters. In addition, it aims to support flexible deployment
scenarios of QoS authorization and parameter provisioning by
Authorization entities, which know the user and its subscription
profile (Home AAA server) or can provide authorization for a session
requested by the user (Application server). QoS authorization and
parameter provisioning MAY be incorporated into initial
authentication and authorization RADIUS exchange or MAY be triggered
at a later moment by a reception of a QoS signalling message.
If the authentication procedure involves multiple Access-Requests (as 5. Authorization and QoS parameter provision
in EAP), the RADIUS client MUST include the QoS-attributes in at
least the last Access-Request of the authentication procedure.
The server processes the information and responds with a RADIUS 5.1 QoS enabled initial access authentication and authorization
Access-Accept message, which contains the QoS authorization result,
accounting and bearer gating information. Also, the value of the
Session-Timeout attribute is set to the duration of the session, the
value of the "Termination-Action" attribute is set and the "State"
attribute MUST be included as stated in [1].
If the authorization decision at the RADIUS server indiates that the QoS enabled RADIUS client (NAS) initiates the authentication and
request cannot be completed successfully then an Access-Reject authorization process by sending a RADIUS Access-Request to the
message containing the Reply-Message attribute with the reason for user's Home AAA server. In addition to authentication related
rejection. attributes, it includes the QSPEC(TBD) attribute, which MAY specify
the QoS-Model [15] supported by the NAS and description of the
currently available QoS resources or description of the QoS
explicitly requested by the user. In the second case, additional
session and flow identification information MIGHT be included
together with the identity of the QoS authorizing application server.
4.1 Session Establishment If the authentication process involves multiple Access-Requests (as
in EAP), the RADIUS client MUST include the QSPEC(TBD) attribute and
any additional QoS-authorization related information in at least the
last Access-Request of the authentication process.
When the QoS authorization exchange completes successfully, an RADIUS The Home AAA server receives the Access-Request message and
Accounting session SHOULD start for reporting accounting information authenticates the user. Based on the user profile it determines the
and loss of bearer. Accounting information is reported as described subscription QoS parameters and includes them into the QSPEC(TBD)
in [2] and [3]. Loss of bearer information is reported using Access- attribute of the Access-Accept message.
Request message.
4.2 QoS Re-Authorization In case that the QoS authorization MUST be done by an Application
server, which identity is included into the Access-Request message,
the Home server forwards the Access-Request to the Application
server. The Access-Request will contain the QSPEC(TBD) attribute and
session identification information. Upon successful authorization,
the Application server generates an Access-Accept containing the
QSPEC(TBD) attribute, flow identification information and optionally
bearer gating information.
4.2.1 Client-side initiated Re-Authorization The QSPEC attribute returned to the client SHOULD contain the
duration of the QoS enabled session.
If the authentication or authorization of the user is not successful,
the Home AAA server or the application server sends back an Access-
Reject message containing Reply-Message(18) attribute with the reason
for rejection.
When the QoS authorization exchange completes successfully, a RADIUS
Accounting session SHOULD start for reporting accounting information.
Accounting information is reported as described in [2] and [3]. Loss
of bearer information is reported using Access-Request message as
specified in the following section.
5.2 Mid-Session QoS authorization
5.2.1 Client-side initiated QoS authorization/re-authorization
Two types of QoS-related events MIGHT initiate Authorize-Only Access-
Request messages - reception of a QoS signaling message or expiration
of authorization lifetime of ongoing QoS-enabled session. In both
cases, the RADIUS client sends an Access-Request with Service-Type(6)
attribute set to a value of "Authorize-Only", QSPEC(TBD) attribute
and session and flow identification information. The QSPEC(TBD)
attribute includes description of new QoS parameters explicitly
required by the user or the QoS parameters that SHOULD be re-
authorized. Session and flow (only in the re-authorization case)
identification information SHOULD be the same as those used during
the initial Access-Request. For example, if the User-Name(1)
attribute was used in the initial Access-Request it MUST be included,
especially if the User-Name(1) attribute is used to route the Access-
Request to the Home RADIUS server.
The "Authorize-ONLY" Access-Request MUST NOT include either User The "Authorize-ONLY" Access-Request MUST NOT include either User
Password or a CHAP Password. In order to protect the RADIUS message, Password(2) or a CHAP Password(3). In order to protect the RADIUS
the RADIUS client MUST include the Message-Authenticator(80) message, the RADIUS client MUST include the Message-Authenticator(80)
attribute. The RADIUS client will compute the value for the Message- attribute. The RADIUS client will compute the value for the Message-
Authenticator based on [3]. Authenticator(80) based on [3].
The RADIUS server processes the information including the The RADIUS server processes the information, including the
verification of the Message-Authenticator(80) as per [3] and responds verification of the Message-Authenticator(80) as per [3], and upon
with a RADIUS Access-Accept message which contains the "Service-Type" successful authorization it responds with a RADIUS Access-Accept
(6) attribute with value "Authorize-ONLY", QoS authorization, message. It contains the Service-Type(6) attribute with value
accounting, bearer gating information, and the "State" attribute with "Authorize-ONLY", the QSPEC(TBD) attribute, flow identification
new value or a Access-Reject message containing the Reply-Message information and optionally bearer gating information. The QSPEC(TBD)
attribute returned to the client SHOULD contain the new duration of
the QoS enabled session. In case of unsuccessful authorization an
Access-Reject message is sent, containing the Reply-Message(18)
attribute with the reason of rejection. attribute with the reason of rejection.
4.2.2 Server-side initiated Re-Authorization In case that an Application server MUST be contacted for the QoS
authorization, the Home server forwards the Access-Request to the
indicated Application server, which processes the QoS authorization
request.
At any time during the QoS session the RAIDUS server MAY send a 5.2.2 Server-side initiated Re-Authorization
Change-of-Authorization (CoA) message with the "Service-Type" (6)
attribute with the value "Authorize-ONLY". The RADIUS client MUST In order to take advantage of the dynamic authorization capabilities
respond with a Change-of-Authorization NACK message with the of RADIUS as defined in [4], the Authorization entity (Home or
"Service-Type" (6) attribute with the value "Authorize-ONLY" and the Application server) MUST be sure that the RADIUS client supports them
Error-Cause attribute with value "Request-Initiated". The RADIUS too. An advertising approach proposed in [14] MIGHT be used.(TBD)
client MUST then send an Access-Request containing "Service-Type" (6) At any time during the QoS session the RADIUS server MAY send a
attribute with value "Authorize-ONLY" and re-authorization Change-of-Authorization (CoA) message with Service-Type(6) attribute
set to value "Authorize-ONLY" and session and flow identification
information. The RADIUS client MUST respond with a Change-of-
Authorization NACK message with Service-Type(6) attribute with value
"Authorize-ONLY" and Error-Cause(101) attribute set to value
"Request-Initiated". The RADIUS client MUST then send an Access-
Request containing Service-Type(6) attribute with value "Authorize-
ONLY", QSPEC(TBD) attribute, session and flow identification
information. This approach is compatible with the DIAMETER re- information. This approach is compatible with the DIAMETER re-
authorization procedure and is defined in RFC 3576 [4]. Furthermore, authorization procedure and is defined in RFC 3576 [4]. Furthermore,
the "State" attribute SHOULD be used as specified in RFC 3576 [4]. the "State" attribute SHOULD be used as specified in RFC 3576 [4].
4.3 Session Termination 5.3 Session Termination
4.3.1 Client-side initiated session termination 5.3.1 Client-side initiated session termination
A QoS session may be terminated from the client side by sending a Service session MAY be related to a particular authorized QoS-
Access-Request message with unchanged "State" attribute received from provisioned data flow. In this case, session termination MAY be
the RADIUS server. This action is defined in [6]. caused by a QoS signaling tear down message or loss of bearer report.
In another scenario the service session is a QoS enabled access
session, which can handle authorization of several QoS-provisioned
user's data flows. In this case session termination MAY be caused by
user log-off.
4.3.2 Server-side initiated session termination A RADIUS client indicates session termination by sending an
Accounting-Request message with Acc-Status-Type(40) attribute set to
"Stop" value and final QoS related accounting records(TBD).
5.3.2 Server-side initiated session termination
At anytime during a session the Authorizing Server may send a At anytime during a session the Authorizing Server may send a
Disconnect message to terminate a session. This capability is Disconnect message to terminate the session. This capability is
described in detail in RFC 3576 [4]. The RADIUS server sends a described in detail in RFC 3576 [4]. The RADIUS server sends a
Disconnect message that MUST contain identifiers that uniquely Disconnect message that MUST contain identifiers that uniquely
identify the subscribers data session and the RADIUS client serving determine the subscriber's session and the RADIUS client serving that
that session and the "Service-Type" (6) attribute with value session and Service-Type(6) attribute with value "Authorize-ONLY".
"Authorize-ONLY".
If the RADIUS client receives a Disconnect message, it MUST respond If the RADIUS client receives a Disconnect message, it MUST respond
with the Disconnect-NACK message with "Service-Type" (6) attribute with the Disconnect-NACK message with Service-Type(6) attribute with
with value "Authorize-ONLY" and Error-Cause attribute with the value value "Authorize-ONLY" and Error-Cause(101) attribute with value
"Request-Initiated". If it is able to terminate the session it will "Request-Initiated". If it is able to terminate the session it will
send Access-Request message with "Service-Type" (6) attribute with send Access-Request message with Service-Type(6) attribute with value
value "Authorize-ONLY" and attributes for session termination. This "Authorize-ONLY" and attributes for session termination. This
message flow is required for compatibility with DIAMETER protocol. message flow is required for compatibility with DIAMETER protocol.
Also the "State" attribute SHOULD be used as specified in RFC 3576 Also the State(24) attribute SHOULD be used as specified in RFC 3576
[4]. [4].
5. Accounting 6. Accounting
Application of the RADIUS protocol for QoS Authorization presented in Application of the RADIUS protocol for QoS authorization presented in
this document use RADIUS Accounting as defined in the RFC2865, this document use RADIUS Accounting as defined in the RFC2865 [1],
RFC2866 and RFC2869. The definition of new accounting attributes may RFC2866 [2] and RFC2869 [3]. The definition of new accounting
be necessary but left for further study. attributes may be necessary but left for further study.
After a successful QoS authorization the RADIUS client starts the After a successful QoS authorization the RADIUS client starts the
corresponding accounting session by sending the Accounting-Request corresponding accounting session by sending the Accounting-Request
message. This message SHOULD contain necessary attributes to bind message. This message SHOULD contain necessary attributes to bind
the current accounting session to the reported QoS session. "Class" the current accounting session to the reported QoS session.
and "Acc-Session-ID" attributes SHOULD be used according to [1] and Class(25) and Acc-Session-ID(44) attributes SHOULD be used according
[2].The RADIUS server responds with a Accounting-Accept message after to [1] and [2]. The RADIUS server responds with an Accounting-
successfully processing the Accounting-Request message. The Response message after successfully processing the Accounting-Request
Accounting-Accept message MAY contain instructions for managing the message. The Accounting-Response message MAY contain instructions
accounting session, such as the Accounting-Interim-Interval AVP. for managing the accounting session, such as the Acct-Interim-
Interval(85) attribute.
After every successful re-authorization procedure the RADIUS client After every successful re-authorization procedure the RADIUS client
SHOULD re-initiate accounting message exchange. SHOULD re-initiate accounting message exchange.
After successful session termination the RADIUS client SHOULD For indication of session termination the RADIUS client SHOULD
initiate a final exchange of accounting messages with the RADIUS initiate a final exchange of accounting messages with the RADIUS
server. server.
6. Attributes 7. Attributes
This section defines three categories of attributes: This section defines three categories of attributes:
o QSPEC parameters describing requested/authorized QoS o QSPEC parameters describing requested/authorized QoS
o Identification of the flow that should receive QoS described in o Identification of the flow that should receive QoS described in
QSPEC QSPEC
o AVPs required to carry authorization information (e.g., o Attributes required to carry authorization information (e.g.,
authorization tokens as specified in [7]) authorization tokens as specified in [6])
6.1 QSPEC Attribute 7.1 QSPEC Attribute
The generic QoS description is taken from QoS-NSLP QSpec Template The generic QoS description is taken from QoS-NSLP QSpec Template
[14] which aims to support QoS parameters for all QoS reservations [15] which aims to support QoS parameters for all QoS reservations
and is independent of a specific QoS model (QOSM). The QSPEC and is independent of a specific QoS model (QOSM). The QSPEC
template format is organized into QoS Control information, Requested, template format is organized into QoS Control information, Requested,
Reserved, Available and Minimun objects. Each of the objects Reserved, Available and Minimun objects. Each of the objects
contains a number of QSPEC parameters. For QoS authorization contains a number of QSPEC parameters. For QoS authorization
purposes only part of the parameters SHOULD be used, e.g., mainly purposes only part of the parameters SHOULD be used, e.g., mainly
those included into the QoS Desired and some of those included into those included into the QoS Desired and some of those included into
QoS Control information objects. In addition information for QoS Control information objects. In addition information for
duration of the authorized QoS SHOULD be provided. duration of the authorized QoS SHOULD be provided.
QSPEC parameters and QoS authorization session management parameters QSPEC parameters and QoS authorization session management parameters
skipping to change at page 11, line 17 skipping to change at page 13, line 17
Length: variable, greater than 8 Length: variable, greater than 8
String: The String value MUST be encoded as follows: String: The String value MUST be encoded as follows:
Sub-Type (=1): Sub-Type for QoS-Model ID attribute Sub-Type (=1): Sub-Type for QoS-Model ID attribute
Length : Length of QoS-Model ID attribute (= 6 octets) Length : Length of QoS-Model ID attribute (= 6 octets)
QoS-Model ID (QoSM ID): QoS-Model ID (QoSM ID):
Identifier of the used QoS signaling model.[14] Identifier of the used QoS signaling model.[15]
Sub-Type (=2): Sub-Type for Excess Treatment attribute Sub-Type (=2): Sub-Type for Excess Treatment attribute
Length : Length of Excess Treatment attribute (= 3 octets) Length : Length of Excess Treatment attribute (= 3 octets)
Excess Treatment: Excess Treatment:
Description of how the excess traffic to be processed (out-of- Description of how the excess traffic to be processed (out-of-
profile traffic). Excess traffic MAY be dropped, shaped and/or profile traffic). Excess traffic MAY be dropped, shaped and/or
remarked. remarked.
skipping to change at page 11, line 43 skipping to change at page 13, line 43
Bandwidth: Bandwidth:
Link bandwidth needed by a flow. Link bandwidth needed by a flow.
Sub-Type (=4): Sub-Type for Token Bucket Rate attribute Sub-Type (=4): Sub-Type for Token Bucket Rate attribute
Length : Length of Token Bucket Rate attribute (= 6 octets) Length : Length of Token Bucket Rate attribute (= 6 octets)
Token Bucket Rate: Token Bucket Rate:
Rate is a Token Bucket parameter as specified in [8]. Rate is a Token Bucket parameter as specified in [7].
Sub-Type (=5): Sub-Type for Token Bucket Size attribute Sub-Type (=5): Sub-Type for Token Bucket Size attribute
Length : Length of Token Bucket Size attribute (= 6 octets) Length : Length of Token Bucket Size attribute (= 6 octets)
Token Bucket Size: Token Bucket Size:
Size is a Token Bucket parameter as specified in [8]. Size is a Token Bucket parameter as specified in [7].
Sub-Type (=6): Sub-Type for Peak Data Rate attribute Sub-Type (=6): Sub-Type for Peak Data Rate attribute
Length : Length of Peak Data Rate attribute (= 6 octets) Length : Length of Peak Data Rate attribute (= 6 octets)
Token Bucket Size: Token Bucket Size:
Peak Data Rate is a Token Bucket parameter as specified in [8]. Peak Data Rate is a Token Bucket parameter as specified in [7].
Sub-Type (=7): Sub-Type for Minimum Policed Unit attribute Sub-Type (=7): Sub-Type for Minimum Policed Unit attribute
Length : Length of Minimum Policed Unit attribute (= 6 Length : Length of Minimum Policed Unit attribute (= 6
octets) octets)
Minimum Policed Unit: Minimum Policed Unit:
Minimum Policed Unit is a Token Bucket parameter as specified in Minimum Policed Unit is a Token Bucket parameter as specified in
[8]. [7].
Sub-Type (=8): Sub-Type for Maximum Packet Size [MTU] attribute Sub-Type (=8): Sub-Type for Maximum Packet Size [MTU] attribute
Length : Length of Maximum Packet Size [MTU] attribute (= 6 Length : Length of Maximum Packet Size [MTU] attribute (= 6
octets) octets)
Maximum Packet Size [MTU]: Maximum Packet Size [MTU]:
Maximum Packet Size [MTU] is a Token Bucket parameter as specified Maximum Packet Size [MTU] is a Token Bucket parameter as specified
in [8]. in [7].
Sub-Type (=9): Sub-Type for PHB class attribute Sub-Type (=9): Sub-Type for PHB class attribute
Length : Length of PHB class attribute (= 6 octets) Length : Length of PHB class attribute (= 6 octets)
PHB class: PHB class:
Indicates the QoS class used in DiffServ per-hop behavior QoS Indicates the QoS class used in DiffServ per-hop behavior QoS
signaling [9]. signaling [8].
Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute Sub-Type (=10): Sub-Type for Y.1541 QoS class attribute
Length : Length of Y.1541 QoS class attribute (= 3 octets) Length : Length of Y.1541 QoS class attribute (= 3 octets)
Y.1541 QoS class: Y.1541 QoS class:
Indicates the Y.1541 QoS Class [15]. Indicates the Y.1541 QoS Class [16].
Sub-Type (=11): Sub-Type for DSTE class attribute Sub-Type (=11): Sub-Type for DSTE class attribute
Length : Length of DSTE class attribute (= 3 octets) Length : Length of DSTE class attribute (= 3 octets)
DSTE Class: DSTE Class:
Indicates the QoS class used in DiffServ-enabled MPLS traffic Indicates the QoS class used in DiffServ-enabled MPLS traffic
engineering.[10]. engineering.[9].
Sub-Type (=12): Sub-Type for Preemption Priority attribute Sub-Type (=12): Sub-Type for Preemption Priority attribute
Length : Length of Preemption Priority attribute (= 4 octets) Length : Length of Preemption Priority attribute (= 4 octets)
Preemption Priority: Preemption Priority:
Parameter used in the process of differentiation of flows. Parameter used in the process of differentiation of flows.
Indicates the priority of the new flow compared with the defending Indicates the priority of the new flow compared with the defending
priority of previously admitted flows. priority of previously admitted flows.
skipping to change at page 13, line 42 skipping to change at page 15, line 42
Sub-Type (=14): Sub-Type for Reservation Priority attribute Sub-Type (=14): Sub-Type for Reservation Priority attribute
Length : Length of Reservation Priority attribute (= 4 Length : Length of Reservation Priority attribute (= 4
octets) octets)
Reservation Priority: Reservation Priority:
Parameter used in the process of differentiation of flows for Parameter used in the process of differentiation of flows for
emergency services, ETS, E911, etc., and assigning them a higher emergency services, ETS, E911, etc., and assigning them a higher
admission priority. admission priority. [Editor's Note: Reference to be included
here.]
Sub-Type (=15): Sub-Type for Authorization lifetime attribute Sub-Type (=15): Sub-Type for Authorization lifetime attribute
Length : Length of Authorization lifetime attribute (= 6 Length : Length of Authorization lifetime attribute (= 6
octets) octets)
Authorization lifetime: Authorization lifetime:
The parameter indicates the duration of the authorized QoS The parameter indicates the duration of the authorized QoS
provisioning. provisioning.
Sub-Type (=16): Sub-Type for Authorized volume attribute Sub-Type (=16): Sub-Type for Authorized volume attribute
Length : Length of Authorized volume attribute (= 6 octets) Length : Length of Authorized volume attribute (= 6 octets)
Authorized volume: Authorized volume:
skipping to change at page 14, line 25 skipping to change at page 16, line 29
Length : Length of Authorized volume attribute (IPv4 = 6 Length : Length of Authorized volume attribute (IPv4 = 6
octets, IPv6= 18 octets) octets, IPv6= 18 octets)
Application server ID: Application server ID:
Application server ID indicates the address of the authorizing Application server ID indicates the address of the authorizing
Application Server. Application Server.
Provided QSPEC parameters list is not exhaustive and SHOULD be Provided QSPEC parameters list is not exhaustive and SHOULD be
updated according to [14]. updated according to [15].
6.2 Flow Identification 7.2 Flow Identification
Depending on the deployment and used QoS signaling protocol, Depending on the deployment and used QoS signaling protocol,
identification of the flow that SHOULD received authorized QoS takes identification of the flow that SHOULD received authorized QoS takes
a different format. Signaling session Identifier (NSIS) or flow a different format. Signaling session Identifier (NSIS) or flow
identifier and explicit filter specifications are used. The identifier and explicit filter specifications are used. The
Attribute QoS-Flow-ID is designated to encapsulate such information. Attribute QoS-Flow-ID is designated to encapsulate such information.
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 15, line 12 skipping to change at page 17, line 18
String: The String value MUST be encoded as follows: String: The String value MUST be encoded as follows:
Sub-Type (=1): Signaling Session ID Sub-Type (=1): Signaling Session ID
Length : Length of Signaling Session ID attribute (= 6 Length : Length of Signaling Session ID attribute (= 6
octets) octets)
Signaling Session ID: Signaling Session ID:
In NSIS framework [11], Signaling session ID is an unique In NSIS framework [10], Signaling session ID is an unique
identifier of the signaling session that remains unchanged for the identifier of the signaling session that remains unchanged for the
duration of the session. It is locally mapped to the specific duration of the session. It is locally mapped to the specific
flow identifiers. flow identifiers.
Additional Sub-Type attributes SHOULD be added, which combined with Additional Sub-Type attributes SHOULD be added, which combined with
filter specifications (such as QoS-Filter-Rule [16]) provide flow filter specifications (such as QoS-Filter-Rule [17]) provide flow
identification. [TBD] identification. [TBD]
6.3 Authorization Objects 7.3 Authorization Objects
TBD: TBD:
7. Diameter RADIUS Interoperability 8. Diameter RADIUS Interoperability
In deployments where RADIUS clients communicate with DIAMETER servers In deployments where RADIUS clients communicate with DIAMETER servers
or DIAMETER clients communicate with RADIUS servers then a or DIAMETER clients communicate with RADIUS servers then a
translation agent will be deployed and operate. The DIAMETER-QoS translation agent will be deployed and operate. The DIAMETER-QoS
specification [12] provides a natural candidate for mapping the specification [12] provides a natural candidate for mapping the
RADIUS QoS related AVPs to DIAMETER AVPs and messages. RADIUS QoS related AVPs to DIAMETER AVPs and messages.
8. Examples 9. Examples
TBD: Description of the example goes in here. The following diagrams show RADIUS protocol interactions for
different scenarios and deployment architectures.
9.1 RADIUS authorization of a QoS signaling reservation request
RADIUS RADIUS RADIUS RADIUS
Client Server Client Server
-----------> | | -----------> | |
QoS | Access-Request/UserID, QSPEC/ | QoS | Access-Request/UserID, QSPEC/ |
reservation |----------------------------------------------->| reservation |----------------------------------------------->|
request | | request | |
| Access-Accept/QSPEC/ | | Access-Accept/QSPEC/ |
|<-----------------------------------------------| |<-----------------------------------------------|
| | | |
Start |Accounting-Request/Start,QoS Acc-Session-ID.../ | Start |Accounting-Request/Start, Acc-Session-ID.../ |
Accounting |----------------------------------------------->| Accounting |----------------------------------------------->|
| Accounting-Accept/...Acc-Interim-Period.../ | | Accounting-Response/...Acc-Interim-Period.../ |
|<-----------------------------------------------| |<-----------------------------------------------|
| | | |
Authorization| | Authorization| |
LifeTime | | LifeTime | |
Expires: | | Expires: | |
Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ | Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ |
Authorization|----------------------------------------------->| Authorization|----------------------------------------------->|
| Access-Accept/ Auth-ONLY, QSPEC/ | | Access-Accept/ Auth-ONLY, QSPEC/ |
|<-----------------------------------------------| |<-----------------------------------------------|
| Accounting-Request/Interim, Acc-Session-ID./ | | Accounting-Request/Interim, Acc-Session-ID./ |
|----------------------------------------------->| |----------------------------------------------->|
| Accounting-Accept/...Acc-Interim-Period.../ | | Accounting-Response/...Acc-Interim-Period.../ |
|<-----------------------------------------------| |<-----------------------------------------------|
..................... .....................
| Session | Session
| Termination | Termination
| initiated | initiated
| by | by
| server | server
| Disconnect-Request/Auth-ONLY, .../ <------ | Disconnect-Request/Auth-ONLY, .../ <------
|<-----------------------------------------------| |<-----------------------------------------------|
| Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ | | Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ |
|----------------------------------------------->| |----------------------------------------------->|
| Access-Request/Auth-ONLY,... | | Access-Request/Auth-ONLY,... |
| Acc-Terminate-Cause="Admin-Reset"/| | Acc-Terminate-Cause="Admin-Reset"/|
|----------------------------------------------->| |----------------------------------------------->|
| Access-Accept | | Access-Accept |
|<-----------------------------------------------| |<-----------------------------------------------|
Accounting | Accounting-Request/Final,Acc-Session-ID./ | Accounting | Accounting-Request/Final,Acc-Session-ID./ |
end |----------------------------------------------->| end |----------------------------------------------->|
| Accounting-Accept /Final,.../ | | Accounting-Response /Final,.../ |
|<-----------------------------------------------| |<-----------------------------------------------|
9. Security Considerations This example shows the protocol exchange between the RADIUS client
and the RADIUS server. An incoming QoS reservation request received
at the QoS policy aware node (i.e., RADIUS client) invokes the
transmission of a Access-Request message (AR) to the RADIUS server.
This message contains the requested QoS resources in a QSPEC
attribute along with user identification and authentication
information. After the request is successfully authenticated and
authorizated, the RADIUS server replies with a Access-Accept message
(AA), which grants a reservation for a certain amount of resources
(as included in the QSPEC attribute). After the successful exchange
of the AR/AA messages, the RADIUS client starts an accounting session
by sending an Accounting-Request message. The server replies with an
Accounting-Response message that MAY include instructions for further
handling of the accounting session, such as the Acc-Interim-Period
attribute.
The client-side re-authorization caused by expiration of the
authorization lifetime initiates an Authorize-ONLY Access-Request /
Access-Accept message exchange. After a successful re-authorization
an Accounting-Request message SHOULD be sent to indicate the new
authorization parameters. The server replies with an Accounting-
Response message.
In this example, the RADIUS server initiates a session termination.
It therefore sends a Disconnect-Request message. The client responds
with a Disconnect-NACK message and sends an AR message indicating the
termination cause. The server replies to the AR message with an AA
message. After receiving the AA message sent by the server, the
client sends remaining accounting information with the Accounting-
Request message. The server replies with the Accounting-Response
message.
9.2 RADIUS authentication, authorization and management of a QoS-
enabled access session
QoS enabled NAS Home
RADIUS client RADIUS server
| |
| Access-Request/....QSPEC(QoS Available) .../ |
v----------------------------------------------->|
* |
* Multiple |
Authentication *<==============================================>|
process * Access-Request/Access-Challenge Exchange |
* |
* |
Access granted; * Access-Accept/...QSPEC(user-profile QoS).../|
install QoS v<-----------------------------------------------|
| |
| Accounting-Request/...QSPEC(installed QoS)../ |
|----------------------------------------------->|
| Accounting-Response/.../ |
|<-----------------------------------------------|
| |
| |
QoS-Request | Access-Request/Auth-ONLY, QSPEC, QoS-Flow-ID/ |
--------------->|----------------------------------------------->|
| Access-Response/Auth-ONLY, QSPEC, QoS-Flow-ID/|
QoS authorized; *<-----------------------------------------------|
install QoS for | |
QoS-Flow-ID | |
| Accounting-Request/Interim,.../ |
|----------------------------------------------->|
| Accounting-Response/.../ |
|<-----------------------------------------------|
..............................................................
| |
* |
QoS-Flow-ID authz.lifetime expires |
Delete QoS for QoS-Flow-ID |
| |
| Accounting-Request/Interim,.../ |
|----------------------------------------------->|
| Accounting-Response/.../ |
|<-----------------------------------------------|
..............................................................
| |
| CoA-Request /Auth-ONLY,QSPEC.../ |
|<-----------------------------------------------|
| CoA-NACK/Auth-ONLY,"Request-Initiated"/ |
|----------------------------------------------->|
| Access-Request/Auth-ONLY,QSPEC.../ |
|----------------------------------------------->|
| Access-Accept/Auth-ONLY,QSPEC(New QoS).../ |
Install QoS *<-----------------------------------------------|
| |
| Accounting-Request/...QSPEC(installed QoS)../ |
|----------------------------------------------->|
| Accounting-Response/.../ |
|<-----------------------------------------------|
This example shows the interaction between a QoS enabled NAS and a
Home AAA server. This example aims to show a QoS-enabled access
session. The NAS performs authorization of the QoS-provisioned flows
as part of the user's access session.
The NAS performs initial authentication and authorization of the end
user for an access session. This process MAY take several Access-
Request / Access-Challenge message exchanges. By including the QSPEC
attribute, the RADIUS server provides a description of the QoS
parameters of the user access session. The NAS allocates certain QoS
resources according to the QoS parameters provided by the RADIUS
server and currently available QoS resources. The NAS initiates an
accounting session by sending the Accounting-Request message in which
it reports the actually allocated QoS resources for the access
session. The server replies with an Accounting-Response message that
MAY include instructions for further handling of the accounting
session, such as the Acc-Interim-Period attribute.
Later, when the NAS intercepts a QoS signaling message sent from the
end host an Authorize-ONLY Access-Request message is triggered and
sent to the RADIUS server. It includes the description of the
requested QoS resources in the QSPEC attribute. Optionally, an
identifier of the flow that should receive the requested QoS
treatment is included into the Access-Request message. The RADIUS
server (in the user's home domain) validates the QoS request and
replies with Authorize-ONLY Access-Accept message. The message
includes a QSPEC attribute with description of the authorized QoS
parameters and the duration of authorization. An identifier of the
flow that should receive the requested QoS is also provided. The
RADIUS client will install a QoS reservation based on the provided
QoS parameters for that flow and sends an Accounting-Request message
reporting the new QoS session. The server replies with an
Accounting-Response message.
In this example, the authorization lifetime of the QoS-provisioned
flow expires. The NAS releases the reserved QoS resources allocated
for the flow when the authorization has expired. In addition, the
NAS sends an Accounting-Request message to the RADIUS server,
indicating the stop of QoS provisioning for the flow.
If the Home AAA server decides to change QoS parameters for the
user's access session it sends an Authorize-ONLY Change-of-
Authorization-Request message to the RADIUS client, identifying the
affected access session. The NAS replies with a CoA-NACK message
indicating that an Access-Request has to be generated. The
Authorize-ONLY Access-Request message contains the QSPEC attribute
with the QoS resources currently available at the NAS. The RADIUS
server replies with the Authorize-ONLY Access-Accept message with a
QSPEC attribute containing the new QoS parameters that should be
provided to the user's session. The NAS allocates certain QoS
resources according to the QoS parameters provided by the RADIUS
server and the currently available QoS resources. It sends an
Accounting-Request message in which it reports the actual allocated
QoS resources for the access session. The server replies with an
Accounting-Response message.
10. Security Considerations
For this extension to RADIUS protocol the security considerations For this extension to RADIUS protocol the security considerations
defined in RFC2865 [1], RFC2866 [2], RFC2869 [3] and RFC3576 [4] are defined in RFC2865 [1], RFC2866 [2], RFC2869 [3] and RFC3576 [4] are
applicable. Furthermore, the security of the QoS signaling protocol applicable. Furthermore, the security of the QoS signaling protocol
and the QoS authorization framework must be considered in the and the QoS authorization framework must be considered in the
evaluation of the security properties. evaluation of the security properties.
[Editor's Note: A more detailed treatment will be provided in a [Editor's Note: A more detailed treatment will be provided in a
future document version.] future document version.]
10. Acknowledgments 11. Acknowledgments
We would like to thank Pete McCann and Franck Alfano for their work We would like to thank Pete McCann and Franck Alfano for their work
on the DIAMETER QoS application. on the DIAMETER QoS application.
11. References 12. References
11.1 Normative References 12.1 Normative References
[1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote [1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
[2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[3] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", [3] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000. RFC 2869, June 2000.
[4] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, [4] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial "Dynamic Authorization Extensions to Remote Authentication Dial
In User Service (RADIUS)", RFC 3576, July 2003. In User Service (RADIUS)", RFC 3576, July 2003.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
[6] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [6] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session
"Diameter Base Protocol", RFC 3588, September 2003.
[7] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003. Authorization Policy Element", RFC 3520, April 2003.
[8] Shenker, S. and J. Wroclawski, "General Characterization [7] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC 2215, Parameters for Integrated Service Network Elements", RFC 2215,
September 1997. September 1997.
[9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475, Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998. December 1998.
[10] Le Faucheur, F. and W. Lai, "Requirements for Support of [9] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering", Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003. RFC 3564, July 2003.
[11] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den [10] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
June 2005. June 2005.
11.2 Informative References [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
12.2 Informative References
[12] Alfano, F., "Diameter Quality of Service Application", [12] Alfano, F., "Diameter Quality of Service Application",
draft-alfano-aaa-qosprot-02 (work in progress), February 2005. draft-alfano-aaa-qosprot-02 (work in progress), February 2005.
[13] Alfano, F., "Requirements for a QoS AAA Protocol", [13] Alfano, F., "Requirements for a QoS AAA Protocol",
draft-alfano-aaa-qosreq-01 (work in progress), October 2003. draft-alfano-aaa-qosreq-01 (work in progress), October 2003.
[14] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-04 [14] Lior, A., "Prepaid Extensions to Remote Authentication Dial-In
(work in progress), May 2005. User Service (RADIUS)", draft-lior-radius-prepaid-extensions-07
(work in progress), February 2005.
[15] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using [15] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05
(work in progress), July 2005.
[16] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using
Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in
progress), May 2005. progress), May 2005.
[16] Congdon, P., "RADIUS Extensions for IEEE 802", [17] Congdon, P., "RADIUS Extensions for IEEE 802",
draft-congdon-radext-ieee802-03 (work in progress), draft-congdon-radext-ieee802-03 (work in progress),
February 2005. February 2005.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
 End of changes. 75 change blocks. 
148 lines changed or deleted 374 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/