RADIUS EXTensions (radext) H. Tschofenig
Internet-Draft Siemens
Expires: September 6, 2007 A. Mankin
T. Tsenov
A. Lior
Bridgewater Systems
J. Korhonen
TeliaSonera
March 5, 2007
RADIUS Quality of Service Support
draft-tschofenig-radext-qos-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tschofenig, et al. Expires September 6, 2007 [Page 1]
Internet-Draft RADIUS Quality of Service Support March 2007
Abstract
This document describes an extension to the RADIUS protocol that
performs authentication, authorization, and accounting for Quality-
of-Service reservations.
The described extensions allow network elements to authenticate the
initiator of a reservation request (if desired), to ensure that the
reservation is authorized, and to account for established QoS
resources.
Flexibility is provided by offering support for different
authorization models and by decoupling specific QoS attributes
carried in the QoS signaling protocol from the AAA protocol. This
document is the RADIUS complement to the DIAMETER QoS application.
Tschofenig, et al. Expires September 6, 2007 [Page 2]
Internet-Draft RADIUS Quality of Service Support March 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. RADIUS functional considerations . . . . . . . . . . . . . . . 7
5. Authorization and QoS parameter provision . . . . . . . . . . 8
5.1. QoS enabled initial access authentication and
authorization . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Mid-Session QoS authorization . . . . . . . . . . . . . . 9
5.2.1. Client-side initiated QoS
authorization/re-authorization . . . . . . . . . . . . 9
5.2.2. Server-side initiated Re-Authorization . . . . . . . . 9
5.3. Session Termination . . . . . . . . . . . . . . . . . . . 10
5.3.1. Client-side initiated session termination . . . . . . 10
5.3.2. Server-side initiated session termination . . . . . . 10
6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. QoS-Resources . . . . . . . . . . . . . . . . . . . . . . 12
7.2. ExtendedQoSFilterRule . . . . . . . . . . . . . . . . . . 13
7.3. QoS-Parameter . . . . . . . . . . . . . . . . . . . . . . 15
7.4. QoS-Flow-State . . . . . . . . . . . . . . . . . . . . . . 17
7.5. Authorization Objects . . . . . . . . . . . . . . . . . . 18
8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 20
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. RADIUS authorization of a QoS signaling reservation
request . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.2. RADIUS authentication, authorization and management of
a QoS-enabled access session . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Tschofenig, et al. Expires September 6, 2007 [Page 3]
Internet-Draft RADIUS Quality of Service Support March 2007
1. Introduction
To meet the quality-of-service needs of applications such as voice-
over-IP, it will often be necessary to explicitly request resources
from the network. This will allow the network to identify packets
belonging to these application flows and ensure that bandwidth,
delay, and error rate requirements are met.
This document is a complement to the ongoing work of the DIAMETER QoS
application described in [6]. It describes RADIUS protocol
extensions supporting AAA in an environment where better than best
effort Quality of Service is desired. The suggested extensions to
the RFC 2865 [1], RFC 2866 [7], RFC 2869 [8] and RFC 3576 [9] satisfy
the requirements defined in [10].
Disclaimer: The content of this document will be aligned with the
ongoing QoS work in the DIME working group. Additionally, the
description of the data traffic that is experiencing the QoS
treatment will be aligned with the [11]. Hence, the content of the
attributes presented in this document are subject to change.
Tschofenig, et al. Expires September 6, 2007 [Page 4]
Internet-Draft RADIUS Quality of Service Support March 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
Tschofenig, et al. Expires September 6, 2007 [Page 5]
Internet-Draft RADIUS Quality of Service Support March 2007
3. Goals
This document has a few ambitious goals, namely:
o Decouple the QoS signaling protocol (such as NSIS, RSVP or link
layer QoS signaling protocols) from the AAA protocol. This goal
is accomplished with the help of a generic QoS description, the
QSPEC object.
o Support for different scenarios that demand authorization for QoS
reservations. The impact is to provide flexibility with regard to
the entities that trigger the QoS reservation, the QoS parameters
that need to be provided to the RADIUS server for authorization,
the granularity of the QoS reservation (e.g., for an individual
application flow, for an aggregate).
Tschofenig, et al. Expires September 6, 2007 [Page 6]
Internet-Draft RADIUS Quality of Service Support March 2007
4. RADIUS functional considerations
Being a value-added service, QoS provisioning SHOULD go along with
explicit authorization, accounting and control over the QoS-featured
user session. Specifically, the management of the authorized session
with Session-Timeout(27) and Termination-Action(29) attributes raises
a number of issues, identified in [12]. The solution presented in
this document aims to allow explicit control by the RADIUS server
(Authorizing entity) over the authorization session and its
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.
Tschofenig, et al. Expires September 6, 2007 [Page 7]
Internet-Draft RADIUS Quality of Service Support March 2007
5. Authorization and QoS parameter provision
5.1. QoS enabled initial access authentication and authorization
QoS enabled RADIUS client (NAS) initiates the authentication and
authorization process by sending a RADIUS Access-Request to the
user's Home AAA server. In addition to authentication related
attributes, it includes the QSPEC(TBD) attribute, which MAY specify
the QoS-Model [13] 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.
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.
The Home AAA server receives the Access-Request message and
authenticates the user. Based on the user profile it determines the
subscription QoS parameters and includes them into the QSPEC(TBD)
attribute of the Access-Accept message.
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.
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 [7] and [8]. Loss
of bearer information is reported using Access-Request message as
specified in the following section.
Tschofenig, et al. Expires September 6, 2007 [Page 8]
Internet-Draft RADIUS Quality of Service Support March 2007
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
Password(2) or a CHAP Password(3). In order to protect the RADIUS
message, the RADIUS client MUST include the Message-Authenticator(80)
attribute. The RADIUS client will compute the value for the Message-
Authenticator(80) based on [8].
The RADIUS server processes the information, including the
verification of the Message-Authenticator(80) as per [8], and upon
successful authorization it responds with a RADIUS Access-Accept
message. It contains the Service-Type(6) attribute with value
"Authorize-ONLY", the QSPEC(TBD) attribute, flow identification
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.
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.
5.2.2. Server-side initiated Re-Authorization
In order to take advantage of the dynamic authorization capabilities
of RADIUS as defined in [9], the Authorization entity (Home or
Application server) MUST be sure that the RADIUS client supports them
too. An advertising approach proposed in [12] MIGHT be used.(TBD)
Tschofenig, et al. Expires September 6, 2007 [Page 9]
Internet-Draft RADIUS Quality of Service Support March 2007
At any time during the QoS session the RADIUS server MAY send a
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-
authorization procedure and is defined in RFC 3576 [9]. Furthermore,
the "State" attribute SHOULD be used as specified in RFC 3576 [9].
5.3. Session Termination
5.3.1. Client-side initiated session termination
Service session MAY be related to a particular authorized QoS-
provisioned data flow. In this case, session termination MAY be
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.
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
Disconnect message to terminate the session. This capability is
described in detail in RFC 3576 [9]. The RADIUS server sends a
Disconnect message that MUST contain identifiers that uniquely
determine the subscriber's session and the RADIUS client serving that
session and Service-Type(6) attribute with value "Authorize-ONLY".
If the RADIUS client receives a Disconnect message, it MUST respond
with the Disconnect-NACK message with Service-Type(6) attribute with
value "Authorize-ONLY" and Error-Cause(101) attribute with value
"Request-Initiated". If it is able to terminate the session it will
send Access-Request message with Service-Type(6) attribute with value
"Authorize-ONLY" and attributes for session termination. This
message flow is required for compatibility with DIAMETER protocol.
Also the State(24) attribute SHOULD be used as specified in RFC 3576
[9].
Tschofenig, et al. Expires September 6, 2007 [Page 10]
Internet-Draft RADIUS Quality of Service Support March 2007
6. Accounting
Application of the RADIUS protocol for QoS authorization presented in
this document use RADIUS Accounting as defined in the RFC2865 [1],
RFC2866 [7] and RFC2869 [8]. The attributes containing a QoS
description and flow identification (see Section 7) are used in the
accounting session for reporting the status and parameters of the
provided QoS. The definition of new accounting attributes may be
necessary. This aspect is for further study.
After a successful QoS authorization the RADIUS client starts the
corresponding accounting session by sending the Accounting-Request
message. This message SHOULD contain necessary attributes to bind
the current accounting session to the reported QoS session.
Class(25) and Acc-Session-ID(44) attributes SHOULD be used according
to [1] and [7]. The RADIUS server responds with an Accounting-
Response message after successfully processing the Accounting-Request
message. The Accounting-Response message MAY contain instructions
for managing the accounting session, such as the Acct-Interim-
Interval(85) attribute.
After every successful re-authorization procedure the RADIUS client
SHOULD re-initiate accounting message exchange.
For indication of session termination the RADIUS client SHOULD
initiate a final exchange of accounting messages with the RADIUS
server.
Tschofenig, et al. Expires September 6, 2007 [Page 11]
Internet-Draft RADIUS Quality of Service Support March 2007
7. Attributes
This section defines a QoS-Resource attribute that which consists
ofthree categories of attributes:
o A QoS filter rule for packet classification
o QoS parameters describing requested/authorized QoS
o Enumerated value stating when and how to apply the QoS-parameters
to a flow.
o Attributes required to carry authorization information (e.g.,
authorization tokens as specified in [3])
7.1. QoS-Resources
The QoS-Resources attribute is a single group attribute that can be
sent in RADIUS messages to Authenticate, Authorize and provide
Accounting information for QoS parameters of Flows.
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 | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-QoS-Filter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-QoS-Filter | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS-Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS-parameter | SUB-TYPE 3 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS-Flow-State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS-Flow-State | SUB-TYPE 4 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authorization-token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Value of QoS-Resources
Tschofenig, et al. Expires September 6, 2007 [Page 12]
Internet-Draft RADIUS Quality of Service Support March 2007
Length: variable, greater than 8
String: The String value MUST be encoded as follows:
Sub-Type (=1): Sub-Type for Extended-QoS-Filter
Length : variable, greater than 8
String :
The Extended-QoS-Filter rule is a string type defined in
Section 7.2
Sub-Type (=2): Sub-Type for QoS-Parameter
Length : variable, greater than 8
String :
The QoS-Parameter is a string type defined in Section 7.3
Sub-Type (=3): Sub-Type for QoS-Flow-State
Length : variable, greater than 8
String :
The QoS-Flow-State rule is a string type defined in Section 7.4
Sub-Type (=4): Sub-Type for Authorization-Token
Length : variable, greater than 8
String :
The Authorization-Token is a string type defined in Section 7.5
7.2. ExtendedQoSFilterRule
The Extended QoS filter rule parameter is based on [4] and is used as
a packet classifier.
Tschofenig, et al. Expires September 6, 2007 [Page 13]
Internet-Draft RADIUS Quality of Service Support March 2007
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 | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-QoS-Filter-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended-QoS-Filter-Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Value of Extended-QoS-filter-Value
Length: variable, greater than 8
String: The String value uses the ASCII charset. It MUST follow the
format:
The ExtendedQoSFilterRule is an OctetString. It uses the ASCII
charset. The ExtendedQoSFilterRule MUST follow the format:
Tschofenig, et al. Expires September 6, 2007 [Page 14]
Internet-Draft RADIUS Quality of Service Support March 2007
action dir proto from src to dst [options]
Labels Description
action Action associated with the packet treatment.
Basic actions are described in the IPFilterRule
and extended for usage with QoS treatment.
dir Direction of the packet follow the filter applies to.
A basic description can be found with the
IPFilterRule. Examples are in, out and both.
proto Protocol
A description can be found with the IPFilterRule.
src and dst <address/mask> [ports]
A description can be found with the IPFilterRule.
flow-label IPv6 Flow Label
A description can be found in TBD.
dscp Diffserv Codepoints
A description can be found in TBD.
ipsec-spi IPsec Security Parameter Index (SPI)
A description can be found in TBD.
qos-id A unique id referencing the applicable QoS parameters
that need to be applied to the specified packets.
Rules for the appropriate direction are evaluated in order, with the
first matched rule terminating the evaluation. Each packet is
evaluated once. If no rule matches, the packet is treated as best
effort. An access device that is unable to interpret or apply a QoS
rule SHOULD NOT terminate the session.
7.3. QoS-Parameter
The generic QoS description is taken from [5] which aims to support
QoS parameters for all QoS reservations and is independent of a
specific QoS model (QOSM). The QoS-Parameter template format is
identified by a qoS-Id value and has QSPEC parameters in it. These
QSPEC parametrs are organized into QoS Control information,
Requested, Reserved, Available and Minimum objects.
QoS-Id and QSPEC parameters are are included as subtypes into the
QSPEC attribute. Subtypes not used are omitted in the message.
Tschofenig, et al. Expires September 6, 2007 [Page 15]
Internet-Draft RADIUS Quality of Service Support March 2007
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 | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS-ID | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 [r] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | TMOD Size-1 [b] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1[b] | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 [p] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Minimum policed unit-1 [m] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Minimum policed unit-1 [m] | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-2 [r] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | TMOD Size-2 [b] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-2[b] | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-2 [p] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Minimum policed unit-2 [m] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Minimum policed unit-2 [m] | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Path Jitter STAT1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT1 | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Path Jitter STAT3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Path Jitter STAT3 | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Path Jitter STAT4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Path Packet Loss Ratio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Packet Loss Ratio | SUB-TYPE 2 | LENGTH |
Tschofenig, et al. Expires September 6, 2007 [Page 16]
Internet-Draft RADIUS Quality of Service Support March 2007
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Packet Error Ratio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Slack Term |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Slack Term | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Preemption prioroty | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Defending priority | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Admission Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | RPH Namespace |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Priority | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Treatment Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | PHB Class Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB Class Parameter | SUB-TYPE 2 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DSTE Class Type Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SUB-TYPE 2 | LENGTH | Y.1541 QoS Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Y.1541 QoS Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The above-mentioned attributes are defined in [5] and the list of
parameters mentioned SHOULD be updated according to [5].
7.4. QoS-Flow-State
The QoS-Flow-State gives an indication by the Authorizing entity as
to how the flow MUST be treated. When included in an Access-Request
message, it contains an action to be performed on the state of the
flow to which the message applies. It is of type Enumerated.
TBD
Tschofenig, et al. Expires September 6, 2007 [Page 17]
Internet-Draft RADIUS Quality of Service Support March 2007
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 | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS-flow-State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Enumerated
Length : Length of QoS-Flow-State attribute (= 4 octets)
QoS-Flow-State:
0 Open - Enable the transport plane service, for which
the signaling has been performed.
1 Close - Disable the transport plane service
2 Maintain - Do not alter the current state (enabled/disabled)
of the transport plane service.
The QoS-Flow-State is optional. When not included in a Access-
Accept response, the default behavior is to immediately allow the
flow of packets (Open).
The behavior of Close (0) for the QoS-Flow-State refers to the
case where a QoS reservation exists but it is not activated and
therefore not charged. For time-based charging the time interval
where the gate is closed will not be included of the chargeable
time interval. The QoS model might give some indication whether
an established QoS reservation needs to be freed or needs to be
removed only if not enough resources are available.
7.5. Authorization Objects
Depending on the deployment, different attributes MAY be used as an
input for computing the QoS authorization decision by the Authorizing
entity. In addition to the credentials of the end host, requesting
QoS reservation (e.g., User-Name(1) attribute), an authorization
token MAY be used. This occurs in a deployment scenario, where the
QoS parameters are negotiated as part of an application layer
signaling exchange and where the authorization decision at this
application layer exchange needs to be associated with the
authorization of the QoS reservation of the QoS signaling exchange.
The QoS-Authorization-Data attribute is designated to encapsulate
such information.
Tschofenig, et al. Expires September 6, 2007 [Page 18]
Internet-Draft RADIUS Quality of Service Support March 2007
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 | SUB-TYPE 1 | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authorization-Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Value of QoS-Authorization-Data
Length: variable, greater than 8
String: The String value MUST be encoded as follows:
Sub-Type (=1): Authorization-Token
Length : Length of Authorization-Token attribute
Authorization-Token:
The Authorization-Token sub-attribute is a container that
encapsulates an authorization token received via the QoS signaling
message typically sent by the end host. The token is generated by
the Authorizing entity during the application layer signaling
exchange and identifies the application service session, for which
the QoS reservation request applies. A possible structure for the
authorization token is proposed in context of RSVP [3] or using
SAML as outlined in [14] and [15]. The structure of the token is
considered to be out of the scope for this document.
Tschofenig, et al. Expires September 6, 2007 [Page 19]
Internet-Draft RADIUS Quality of Service Support March 2007
8. Diameter RADIUS Interoperability
In deployments where RADIUS clients communicate with DIAMETER servers
or DIAMETER clients communicate with RADIUS servers then a
translation agent will be deployed and operate. The DIAMETER-QoS
specification [6] provides a natural candidate for mapping the RADIUS
QoS related AVPs to DIAMETER AVPs and messages.
Tschofenig, et al. Expires September 6, 2007 [Page 20]
Internet-Draft RADIUS Quality of Service Support March 2007
9. Examples
The following diagrams show RADIUS protocol interactions for
different scenarios and deployment architectures.
9.1. RADIUS authorization of a QoS signaling reservation request
Tschofenig, et al. Expires September 6, 2007 [Page 21]
Internet-Draft RADIUS Quality of Service Support March 2007
RADIUS RADIUS
Client Server
-----------> | |
QoS | Access-Request/UserID, QSPEC/ |
reservation |----------------------------------------------->|
request | |
| Access-Accept/QSPEC/ |
|<-----------------------------------------------|
| |
Start |Accounting-Request/Start, Acc-Session-ID.../ |
Accounting |----------------------------------------------->|
| Accounting-Response/...Acc-Interim-Period.../ |
|<-----------------------------------------------|
| |
Authorization| |
LifeTime | |
Expires: | |
Re- | Access-Request/Auth-ONLY, UserID, QSPEC/ |
Authorization|----------------------------------------------->|
| Access-Accept/ Auth-ONLY, QSPEC/ |
|<-----------------------------------------------|
| Accounting-Request/Interim, Acc-Session-ID./ |
|----------------------------------------------->|
| Accounting-Response/...Acc-Interim-Period.../ |
|<-----------------------------------------------|
.....................
| Session
| Termination
| initiated
| by
| server
| Disconnect-Request/Auth-ONLY, .../ <------
|<-----------------------------------------------|
| Disconnect-NACK/Auth-ONLY,"Request-Initiated"/ |
|----------------------------------------------->|
| Access-Request/Auth-ONLY,... |
| Acc-Terminate-Cause="Admin-Reset"/|
|----------------------------------------------->|
| Access-Accept |
|<-----------------------------------------------|
Accounting | Accounting-Request/Final,Acc-Session-ID./ |
end |----------------------------------------------->|
| Accounting-Response /Final,.../ |
|<-----------------------------------------------|
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
Tschofenig, et al. Expires September 6, 2007 [Page 22]
Internet-Draft RADIUS Quality of Service Support March 2007
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
authorized, 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)../ |
Tschofenig, et al. Expires September 6, 2007 [Page 23]
Internet-Draft RADIUS Quality of Service Support March 2007
|----------------------------------------------->|
| 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-
Tschofenig, et al. Expires September 6, 2007 [Page 24]
Internet-Draft RADIUS Quality of Service Support March 2007
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.
Tschofenig, et al. Expires September 6, 2007 [Page 25]
Internet-Draft RADIUS Quality of Service Support March 2007
10. IANA Considerations
TBD
Tschofenig, et al. Expires September 6, 2007 [Page 26]
Internet-Draft RADIUS Quality of Service Support March 2007
11. Security Considerations
For this extension to RADIUS protocol the security considerations
defined in RFC2865 [1], RFC2866 [7], RFC2869 [8] and RFC3576 [9] are
applicable. Furthermore, the security of the QoS signaling protocol
and the QoS authorization framework must be considered in the
evaluation of the security properties.
[Editor's Note: A more detailed treatment will be provided in a
future document version.]
Tschofenig, et al. Expires September 6, 2007 [Page 27]
Internet-Draft RADIUS Quality of Service Support March 2007
12. Acknowledgments
We would like to thank Pete McCann and Franck Alfano for their work
on the Diameter QoS application.
Tschofenig, et al. Expires September 6, 2007 [Page 28]
Internet-Draft RADIUS Quality of Service Support March 2007
13. References
13.1. Normative References
[1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[3] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003.
[4] Zorn, G., McCann, P., Tschofenig, H., Tsou, T., and A. Doria,
"Diameter Quality of Service Application",
draft-ietf-dime-diameter-qos-00.txt (work in progress),
February 2006.
[5] Korhonen, J. and H. Tschofenig, "Quality of Service Parameters
for RADIUS and Diameter",
draft-korhonen-dime-qos-parameters-00.txt (work in progress),
February 2006.
13.2. Informative References
[6] Alfano, F., "Diameter Quality of Service Application",
draft-tschofenig-dime-diameter-qos-01 (work in progress),
October 2006.
[7] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[8] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000.
[9] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba,
"Dynamic Authorization Extensions to Remote Authentication Dial
In User Service (RADIUS)", RFC 3576, July 2003.
[10] Alfano, F., "Requirements for a QoS AAA Protocol",
draft-alfano-aaa-qosreq-01 (work in progress), October 2003.
[11] Congdon, P., "RADIUS Filter Rule Attribute",
draft-ietf-radext-filter-08 (work in progress), January 2007.
[12] Lior, A., "Prepaid extensions to Remote Authentication Dial-In
User Service (RADIUS)", draft-lior-radius-prepaid-extensions-11
(work in progress), June 2006.
Tschofenig, et al. Expires September 6, 2007 [Page 29]
Internet-Draft RADIUS Quality of Service Support March 2007
[13] Ash, J., "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-15
(work in progress), February 2007.
[14] Peterson, J., "Trait-based Authorization Requirements for the
Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-02 (work in progress),
January 2006.
[15] Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-01 (work in progress), October 2006.
Tschofenig, et al. Expires September 6, 2007 [Page 30]
Internet-Draft RADIUS Quality of Service Support March 2007
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Allison Mankin
1025 Vermont Avenue
Washington, DC 20005
US
Phone: +1 301-728-7199 (mobile)
Email: mankin@psg.com
URI: http://www.psg.com/~mankin/
Tseno Tsenov
Sofia,
Bulgaria
Email: tseno.tsenov@mytum.de
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Ottawa, Ontario K2K 3J1
Canada
Phone: +1 613-591-6655
Email: avi@bridgewatersystems.com
Jouni Korhonen
TeliaSonera
Teollisuuskatu 13
Sonera FIN-00051
Finland
Email: jouni.korhonen@teliasonera.com
Tschofenig, et al. Expires September 6, 2007 [Page 31]
Internet-Draft RADIUS Quality of Service Support March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Tschofenig, et al. Expires September 6, 2007 [Page 32]