< draft-tschofenig-radext-qos-01.txt		draft-tschofenig-radext-qos-02.txt >
	RADIUS EXTensions (radext) H. Tschofenig		RADIUS EXTensions (radext) H. Tschofenig
	Internet-Draft Siemens		Internet-Draft Siemens
	Expires: January 19, 2006 A. Mankin		Expires: April 25, 2006 A. Mankin
	Shinkuro, Inc		Shinkuro, Inc
	T. Tsenov		T. Tsenov
	Siemens		Siemens
	A. Lior		A. Lior
	Bridgewater Systems		Bridgewater Systems
	July 18, 2005		October 22, 2005
	RADIUS Quality of Service Support		RADIUS Quality of Service Support
	draft-tschofenig-radext-qos-01.txt		draft-tschofenig-radext-qos-02.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 19, 2006.		This Internet-Draft will expire on April 25, 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 22 ¶		skipping to change at page 2, line 22 ¶
	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. RADIUS functional considerations . . . . . . . . . . . . . . . 6		4. RADIUS functional considerations . . . . . . . . . . . . . . . 6
	5. Authorization and QoS parameter provision . . . . . . . . . . 7		5. Authorization and QoS parameter provision . . . . . . . . . . 7
	5.1 QoS enabled initial access authentication and		5.1. QoS enabled initial access authentication and
	authorization . . . . . . . . . . . . . . . . . . . . . . 7		authorization . . . . . . . . . . . . . . . . . . . . . . 7
	5.2 Mid-Session QoS authorization . . . . . . . . . . . . . . 8		5.2. Mid-Session QoS authorization . . . . . . . . . . . . . . 8
	5.2.1 Client-side initiated QoS		5.2.1. Client-side initiated QoS
	authorization/re-authorization . . . . . . . . . . . . 8		authorization/re-authorization . . . . . . . . . . . . 8
	5.2.2 Server-side initiated Re-Authorization . . . . . . . . 8		5.2.2. Server-side initiated Re-Authorization . . . . . . . . 8
	5.3 Session Termination . . . . . . . . . . . . . . . . . . . 9		5.3. Session Termination . . . . . . . . . . . . . . . . . . . 9
	5.3.1 Client-side initiated session termination . . . . . . 9		5.3.1. Client-side initiated session termination . . . . . . 9
	5.3.2 Server-side initiated session termination . . . . . . 9		5.3.2. Server-side initiated session termination . . . . . . 9
	6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7.1 QSPEC Attribute . . . . . . . . . . . . . . . . . . . . . 11		7.1. QSPEC Attribute . . . . . . . . . . . . . . . . . . . . . 11
	7.2 Flow Identification . . . . . . . . . . . . . . . . . . . 16		7.2. Flow Identification . . . . . . . . . . . . . . . . . . . 16
	7.3 Authorization Objects . . . . . . . . . . . . . . . . . . 17		7.3. Authorization Objects . . . . . . . . . . . . . . . . . . 18
	8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 18		8. Diameter RADIUS Interoperability . . . . . . . . . . . . . . . 20
	9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.1 RADIUS authorization of a QoS signaling reservation		9.1. RADIUS authorization of a QoS signaling reservation
	request . . . . . . . . . . . . . . . . . . . . . . . . . 19		request . . . . . . . . . . . . . . . . . . . . . . . . . 21
	9.2 RADIUS authentication, authorization and management of		9.2. RADIUS authentication, authorization and management of
	a QoS-enabled access session . . . . . . . . . . . . . . . 21		a QoS-enabled access session . . . . . . . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . 24		10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	12.1 Normative References . . . . . . . . . . . . . . . . . . . 26		12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
	12.2 Informative References . . . . . . . . . . . . . . . . . . 26		12.2. Informative References . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
	Intellectual Property and Copyright Statements . . . . . . . . 29		Intellectual Property and Copyright Statements . . . . . . . . . . 31
	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, namely:		This document has a few ambitious goals, 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,
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	scenarios of QoS authorization and parameter provisioning by		scenarios of QoS authorization and parameter provisioning by
	Authorization entities, which know the user and its subscription		Authorization entities, which know the user and its subscription
	profile (Home AAA server) or can provide authorization for a session		profile (Home AAA server) or can provide authorization for a session
	requested by the user (Application server). QoS authorization and		requested by the user (Application server). QoS authorization and
	parameter provisioning MAY be incorporated into initial		parameter provisioning MAY be incorporated into initial
	authentication and authorization RADIUS exchange or MAY be triggered		authentication and authorization RADIUS exchange or MAY be triggered
	at a later moment by a reception of a QoS signalling message.		at a later moment by a reception of a QoS signalling message.
	5. Authorization and QoS parameter provision		5. Authorization and QoS parameter provision
	5.1 QoS enabled initial access authentication and authorization		5.1. QoS enabled initial access authentication and authorization
	QoS enabled RADIUS client (NAS) initiates the authentication and		QoS enabled RADIUS client (NAS) initiates the authentication and
	authorization process by sending a RADIUS Access-Request to the		authorization process by sending a RADIUS Access-Request to the
	user's Home AAA server. In addition to authentication related		user's Home AAA server. In addition to authentication related
	attributes, it includes the QSPEC(TBD) attribute, which MAY specify		attributes, it includes the QSPEC(TBD) attribute, which MAY specify
	the QoS-Model [15] supported by the NAS and description of the		the QoS-Model [15] supported by the NAS and description of the
	currently available QoS resources or description of the QoS		currently available QoS resources or description of the QoS
	explicitly requested by the user. In the second case, additional		explicitly requested by the user. In the second case, additional
	session and flow identification information MIGHT be included		session and flow identification information MIGHT be included
	together with the identity of the QoS authorizing application server.		together with the identity of the QoS authorizing application server.
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	the Home AAA server or the application server sends back an Access-		the Home AAA server or the application server sends back an Access-
	Reject message containing Reply-Message(18) attribute with the reason		Reject message containing Reply-Message(18) attribute with the reason
	for rejection.		for rejection.
	When the QoS authorization exchange completes successfully, a RADIUS		When the QoS authorization exchange completes successfully, a RADIUS
	Accounting session SHOULD start for reporting accounting information.		Accounting session SHOULD start for reporting accounting information.
	Accounting information is reported as described in [2] and [3]. Loss		Accounting information is reported as described in [2] and [3]. Loss
	of bearer information is reported using Access-Request message as		of bearer information is reported using Access-Request message as
	specified in the following section.		specified in the following section.
	5.2 Mid-Session QoS authorization		5.2. Mid-Session QoS authorization
	5.2.1 Client-side initiated QoS authorization/re-authorization		5.2.1. Client-side initiated QoS authorization/re-authorization
	Two types of QoS-related events MIGHT initiate Authorize-Only Access-		Two types of QoS-related events MIGHT initiate Authorize-Only Access-
	Request messages - reception of a QoS signaling message or expiration		Request messages - reception of a QoS signaling message or expiration
	of authorization lifetime of ongoing QoS-enabled session. In both		of authorization lifetime of ongoing QoS-enabled session. In both
	cases, the RADIUS client sends an Access-Request with Service-Type(6)		cases, the RADIUS client sends an Access-Request with Service-Type(6)
	attribute set to a value of "Authorize-Only", QSPEC(TBD) attribute		attribute set to a value of "Authorize-Only", QSPEC(TBD) attribute
	and session and flow identification information. The QSPEC(TBD)		and session and flow identification information. The QSPEC(TBD)
	attribute includes description of new QoS parameters explicitly		attribute includes description of new QoS parameters explicitly
	required by the user or the QoS parameters that SHOULD be re-		required by the user or the QoS parameters that SHOULD be re-
	authorized. Session and flow (only in the re-authorization case)		authorized. Session and flow (only in the re-authorization case)
	skipping to change at page 8, line 46 ¶		skipping to change at page 8, line 46 ¶
	attribute returned to the client SHOULD contain the new duration of		attribute returned to the client SHOULD contain the new duration of
	the QoS enabled session. In case of unsuccessful authorization an		the QoS enabled session. In case of unsuccessful authorization an
	Access-Reject message is sent, containing the Reply-Message(18)		Access-Reject message is sent, containing the Reply-Message(18)
	attribute with the reason of rejection.		attribute with the reason of rejection.
	In case that an Application server MUST be contacted for the QoS		In case that an Application server MUST be contacted for the QoS
	authorization, the Home server forwards the Access-Request to the		authorization, the Home server forwards the Access-Request to the
	indicated Application server, which processes the QoS authorization		indicated Application server, which processes the QoS authorization
	request.		request.
	5.2.2 Server-side initiated Re-Authorization		5.2.2. Server-side initiated Re-Authorization
	In order to take advantage of the dynamic authorization capabilities		In order to take advantage of the dynamic authorization capabilities
	of RADIUS as defined in [4], the Authorization entity (Home or		of RADIUS as defined in [4], the Authorization entity (Home or
	Application server) MUST be sure that the RADIUS client supports them		Application server) MUST be sure that the RADIUS client supports them
	too. An advertising approach proposed in [14] MIGHT be used.(TBD)		too. An advertising approach proposed in [14] MIGHT be used.(TBD)
	At any time during the QoS session the RADIUS server MAY send a		At any time during the QoS session the RADIUS server MAY send a
	Change-of-Authorization (CoA) message with Service-Type(6) attribute		Change-of-Authorization (CoA) message with Service-Type(6) attribute
	set to value "Authorize-ONLY" and session and flow identification		set to value "Authorize-ONLY" and session and flow identification
	information. The RADIUS client MUST respond with a Change-of-		information. The RADIUS client MUST respond with a Change-of-
	Authorization NACK message with Service-Type(6) attribute with value		Authorization NACK message with Service-Type(6) attribute with value
	"Authorize-ONLY" and Error-Cause(101) attribute set to value		"Authorize-ONLY" and Error-Cause(101) attribute set to value
	"Request-Initiated". The RADIUS client MUST then send an Access-		"Request-Initiated". The RADIUS client MUST then send an Access-
	Request containing Service-Type(6) attribute with value "Authorize-		Request containing Service-Type(6) attribute with value "Authorize-
	ONLY", QSPEC(TBD) attribute, session and flow identification		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].
	5.3 Session Termination		5.3. Session Termination
	5.3.1 Client-side initiated session termination		5.3.1. Client-side initiated session termination
	Service session MAY be related to a particular authorized QoS-		Service session MAY be related to a particular authorized QoS-
	provisioned data flow. In this case, session termination MAY be		provisioned data flow. In this case, session termination MAY be
	caused by a QoS signaling tear down message or loss of bearer report.		caused by a QoS signaling tear down message or loss of bearer report.
	In another scenario the service session is a QoS enabled access		In another scenario the service session is a QoS enabled access
	session, which can handle authorization of several QoS-provisioned		session, which can handle authorization of several QoS-provisioned
	user's data flows. In this case session termination MAY be caused by		user's data flows. In this case session termination MAY be caused by
	user log-off.		user log-off.
	A RADIUS client indicates session termination by sending an		A RADIUS client indicates session termination by sending an
	Accounting-Request message with Acc-Status-Type(40) attribute set to		Accounting-Request message with Acc-Status-Type(40) attribute set to
	"Stop" value and final QoS related accounting records(TBD).		"Stop" value and final QoS related accounting records(TBD).
	5.3.2 Server-side initiated session termination		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 the 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
	determine the subscriber's session and the RADIUS client serving that		determine the subscriber's session and the RADIUS client serving that
	session and Service-Type(6) attribute with value "Authorize-ONLY".		session and Service-Type(6) attribute with value "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		with the Disconnect-NACK message with Service-Type(6) attribute with
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 9 ¶
	send Access-Request message with Service-Type(6) attribute with value		send Access-Request message with Service-Type(6) attribute with 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(24) attribute SHOULD be used as specified in RFC 3576		Also the State(24) attribute SHOULD be used as specified in RFC 3576
	[4].		[4].
	6. 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 [1],		this document use RADIUS Accounting as defined in the RFC2865 [1],
	RFC2866 [2] and RFC2869 [3]. The definition of new accounting		RFC2866 [2] and RFC2869 [3]. The attributes containing a QoS
	attributes may be necessary but left for further study.		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		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.		the current accounting session to the reported QoS session.
	Class(25) and Acc-Session-ID(44) attributes SHOULD be used according		Class(25) and Acc-Session-ID(44) attributes SHOULD be used according
	to [1] and [2]. The RADIUS server responds with an Accounting-		to [1] and [2]. The RADIUS server responds with an Accounting-
	Response message after successfully processing the Accounting-Request		Response message after successfully processing the Accounting-Request
	message. The Accounting-Response message MAY contain instructions		message. The Accounting-Response message MAY contain instructions
	for managing the accounting session, such as the Acct-Interim-		for managing the accounting session, such as the Acct-Interim-
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	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 Attributes required to carry authorization information (e.g.,		o Attributes required to carry authorization information (e.g.,
	authorization tokens as specified in [6])		authorization tokens as specified in [6])
	7.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
	[15] 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 Minimum 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
	are included as subtypes into the QSPEC attribute. Subtypes not used		are included as subtypes into the QSPEC attribute. Subtypes not used
	are omitted in the message.		are omitted in the message.
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 31 ¶
	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 [15].		updated according to [15].
	7.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 receive authorized QoS takes a
	a different format. Signaling session Identifier (NSIS) or flow		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TYPE | LENGTH | SUB-TYPE 1 | LENGTH |		| TYPE | LENGTH | SUB-TYPE 1 | LENGTH |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signaling Session ID |		| Signaling Session ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| SUB-TYPE 2 | LENGTH | Flow-ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| SUB-TYPE 3 | LENGTH | Flow-Status |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type : Value of QoS-Flow-ID		Type : Value of QoS-Flow-ID
	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): 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 [10], Signaling session ID is an unique		With the NSIS framework [10], a signaling session ID is a 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		entire lifetime of the session. It is locally mapped to the
	flow identifiers.		specific flow identifiers.
	Additional Sub-Type attributes SHOULD be added, which combined with		Sub-Type (=2): Flow-ID
	filter specifications (such as QoS-Filter-Rule [17]) provide flow
	identification. [TBD]
	7.3 Authorization Objects		Length : Length of Flow-ID attribute
	TBD:		Flow-ID:
			The Flow-ID attribute is an application assigned identifier for an
			IP flow that identifies the IP flow in an application layer
			session (e.g., SIP/SDP). It might be used in conjunction with a
			QoS-Filter-Rule [17] attribute for provision of flow description
			and identification. Note that more than one Flow-ID sub-
			attributes MAY be present in the QoS-Flow-Id attribute.
			Sub-Type (=3): Flow-State
			Length : Length of Flow-State attribute
			Flow-State:
			The Flow-State attribute indicates the action that MUST be
			performed on the flow(s) to which QoS authorization message
			exchange applies as identified by the QoS-Flow-Id. The flow could
			be enabled (i.e., it is allowed to trespass the QoS element) and
			it is treated according to the QoS described in the QSPEC
			attribute. The flow could be disabled, i.e., the QoS described in
			the QSPEC could be reserved but additional authorization approval
			by the Authorizing entity is required in order for the flow to
			receive this QoS treatment and to trespass the QoS element.
			In the current approach, there is a one to one binding between a
			QSPEC and a QoS-Flow-Id attribute in a RADIUS message. It is for
			further study whether different QoS authorization information (i.e.,
			multiple QSPEC attributes) for different groups of flows (i.e.,
			multiple QoS-Flow-Id attributes) might need to be carried in a single
			RADIUS message.
			7.3. 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.
			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 [6], with the
			Open Settlement Protocol (OSP) [18] or using SAML as outlined in
			[19] and [20]. The structure of the token is considered to be out
			of the scope for this document.
	8. 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.
	9. Examples		9. Examples
	The following diagrams show RADIUS protocol interactions for		The following diagrams show RADIUS protocol interactions for
	different scenarios and deployment architectures.		different scenarios and deployment architectures.
	9.1 RADIUS authorization of a QoS signaling reservation request		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, Acc-Session-ID.../ |		Start |Accounting-Request/Start, Acc-Session-ID.../ |
	skipping to change at page 21, line 8 ¶		skipping to change at page 23, line 8 ¶
	| Accounting-Response /Final,.../ |		| Accounting-Response /Final,.../ |
	|<-----------------------------------------------|		|<-----------------------------------------------|
	This example shows the protocol exchange between the RADIUS client		This example shows the protocol exchange between the RADIUS client
	and the RADIUS server. An incoming QoS reservation request received		and the RADIUS server. An incoming QoS reservation request received
	at the QoS policy aware node (i.e., RADIUS client) invokes the		at the QoS policy aware node (i.e., RADIUS client) invokes the
	transmission of a Access-Request message (AR) to the RADIUS server.		transmission of a Access-Request message (AR) to the RADIUS server.
	This message contains the requested QoS resources in a QSPEC		This message contains the requested QoS resources in a QSPEC
	attribute along with user identification and authentication		attribute along with user identification and authentication
	information. After the request is successfully authenticated and		information. After the request is successfully authenticated and
	authorizated, the RADIUS server replies with a Access-Accept message		authorized, the RADIUS server replies with a Access-Accept message
	(AA), which grants a reservation for a certain amount of resources		(AA), which grants a reservation for a certain amount of resources
	(as included in the QSPEC attribute). After the successful exchange		(as included in the QSPEC attribute). After the successful exchange
	of the AR/AA messages, the RADIUS client starts an accounting session		of the AR/AA messages, the RADIUS client starts an accounting session
	by sending an Accounting-Request message. The server replies with an		by sending an Accounting-Request message. The server replies with an
	Accounting-Response message that MAY include instructions for further		Accounting-Response message that MAY include instructions for further
	handling of the accounting session, such as the Acc-Interim-Period		handling of the accounting session, such as the Acc-Interim-Period
	attribute.		attribute.
	The client-side re-authorization caused by expiration of the		The client-side re-authorization caused by expiration of the
	authorization lifetime initiates an Authorize-ONLY Access-Request /		authorization lifetime initiates an Authorize-ONLY Access-Request /
	skipping to change at page 21, line 33 ¶		skipping to change at page 23, line 33 ¶
	In this example, the RADIUS server initiates a session termination.		In this example, the RADIUS server initiates a session termination.
	It therefore sends a Disconnect-Request message. The client responds		It therefore sends a Disconnect-Request message. The client responds
	with a Disconnect-NACK message and sends an AR message indicating the		with a Disconnect-NACK message and sends an AR message indicating the
	termination cause. The server replies to the AR message with an AA		termination cause. The server replies to the AR message with an AA
	message. After receiving the AA message sent by the server, the		message. After receiving the AA message sent by the server, the
	client sends remaining accounting information with the Accounting-		client sends remaining accounting information with the Accounting-
	Request message. The server replies with the Accounting-Response		Request message. The server replies with the Accounting-Response
	message.		message.
	9.2 RADIUS authentication, authorization and management of a QoS-		9.2. RADIUS authentication, authorization and management of a QoS-
	enabled access session		enabled access session
	QoS enabled NAS Home		QoS enabled NAS Home
	RADIUS client RADIUS server		RADIUS client RADIUS server
	| |		| |
	| Access-Request/....QSPEC(QoS Available) .../ |		| Access-Request/....QSPEC(QoS Available) .../ |
	v----------------------------------------------->|		v----------------------------------------------->|
	* |		* |
	* Multiple |		* Multiple |
	Authentication *<==============================================>|		Authentication *<==============================================>|
	process * Access-Request/Access-Challenge Exchange |		process * Access-Request/Access-Challenge Exchange |
	skipping to change at page 26, line 7 ¶		skipping to change at page 28, line 7 ¶
	[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.]
	11. 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.
	12. References		12. References
	12.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.
	skipping to change at page 26, line 47 ¶		skipping to change at page 28, line 47 ¶
	Differentiated Services-aware MPLS Traffic Engineering",		Differentiated Services-aware MPLS Traffic Engineering",
	RFC 3564, July 2003.		RFC 3564, July 2003.
	[10] 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] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,		[11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588, September 2003.		"Diameter Base Protocol", RFC 3588, September 2003.
	12.2 Informative References		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-04 (work in progress), September 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] Lior, A., "Prepaid Extensions to Remote Authentication Dial-In		[14] Lior, A., "PrePaid Extensions to Remote Authentication Dial-In
	User Service (RADIUS)", draft-lior-radius-prepaid-extensions-07		User Service (RADIUS)", draft-lior-radius-prepaid-extensions-08
	(work in progress), February 2005.
	[15] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05
	(work in progress), July 2005.		(work in progress), July 2005.
			[15] Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-06
			(work in progress), October 2005.
	[16] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using		[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.
	[17] 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.
			[18] European Telecommunications Standards Institute,
			"Telecommunications and Internet Protocol Harmonization Over
			Networks (TIPHON); Open Settlement Protocol (OSP) for Inter-
			domain pricing, authorization, and usage exchange", TS 101
			321.
			[19] Peterson, J., "Trait-based Authorization Requirements for the
			Session Initiation Protocol (SIP)",
			draft-ietf-sipping-trait-authz-01 (work in progress),
			February 2005.
			[20] Tschofenig, H., "Using SAML for SIP",
			draft-tschofenig-sip-saml-04 (work in progress), July 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
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
End of changes. 36 change blocks.
	62 lines changed or deleted		156 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/