< draft-ietf-dime-diameter-qos-14.txt		draft-ietf-dime-diameter-qos-15.txt >
	Diameter Maintenance and D. Sun, Ed.		Diameter Maintenance and D. Sun, Ed.
	Extensions (DIME) Alcatel-Lucent		Extensions (DIME) Alcatel-Lucent
	Internet-Draft P. McCann		Internet-Draft P. McCann
	Intended status: Standards Track Motorola Labs		Intended status: Standards Track Motorola Labs
	Expires: August 25, 2010 H. Tschofenig		Expires: September 8, 2010 H. Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	T. Tsou		T. Tsou
	Huawei		Huawei
	A. Doria		A. Doria
	Lulea University of Technology		Lulea University of Technology
	G. Zorn, Ed.		G. Zorn, Ed.
	Network Zen		Network Zen
	February 21, 2010		March 7, 2010
	Diameter Quality of Service Application		Diameter Quality of Service Application
	draft-ietf-dime-diameter-qos-14.txt		draft-ietf-dime-diameter-qos-15.txt
	Abstract		Abstract
	This document describes the framework, messages and procedures for		This document describes the framework, messages and procedures for
	the Diameter Quality of Service (QoS) application. The Diameter QoS		the Diameter Quality of Service (QoS) application. The Diameter QoS
	application allows network elements to interact with Diameter servers		application allows network elements to interact with Diameter servers
	when allocating QoS resources in the network. In particular, two		when allocating QoS resources in the network. In particular, two
	modes of operation, namely "Pull" and "Push", are defined.		modes of operation, namely "Pull" and "Push", are defined.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 25, 2010.		This Internet-Draft will expire on September 8, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 35		5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 35
	5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 35		5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 35
	5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 36		5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 36
	6. QoS Application State Machine . . . . . . . . . . . . . . . . 37		6. QoS Application State Machine . . . . . . . . . . . . . . . . 37
	6.1. Supplemented States for Push Mode . . . . . . . . . . . . 37		6.1. Supplemented States for Push Mode . . . . . . . . . . . . 37
	7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 39		7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 39
	7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 39		7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 39
	7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 39		7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 39
	8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 41		8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42		9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
	9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 42		9.1. Example Call Flow for Pull Mode (Success Case) . . . . . . 42
	9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 44		9.2. Example Call Flow for Pull Mode (Failure Case) . . . . . . 44
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		9.3. Example Call Flow for Push Mode . . . . . . . . . . . . . 47
	10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 47		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
	10.2. Application IDs . . . . . . . . . . . . . . . . . . . . . 47		10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 50
	10.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 47		10.2. Application IDs . . . . . . . . . . . . . . . . . . . . . 50
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 48		10.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 50
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50		11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 54
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 52		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
	14.2. Informative References . . . . . . . . . . . . . . . . . . 52		14.1. Normative References . . . . . . . . . . . . . . . . . . . 55
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54		14.2. Informative References . . . . . . . . . . . . . . . . . . 55
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
	1. Introduction		1. Introduction
	This document describes the framework, messages and procedures for		This document describes the framework, messages and procedures for
	the Diameter [RFC3588] Quality of Service (QoS) application. The		the Diameter [RFC3588] Quality of Service (QoS) application. The
	Diameter QoS application allows Network Elements (NEs) to interact		Diameter QoS application allows Network Elements (NEs) to interact
	with Diameter servers when allocating QoS resources in the network.		with Diameter servers when allocating QoS resources in the network.
	Two modes of operation are defined. In the first, called "Pull"		Two modes of operation are defined. In the first, called "Pull"
	mode, the network element requests QoS authorization from the		mode, the network element requests QoS authorization from the
	skipping to change at page 42, line 7 ¶		skipping to change at page 42, line 7 ¶
	the QoS resources reserved. It should be noted that the two sessions		the QoS resources reserved. It should be noted that the two sessions
	(authorization and accounting) have independent management by the		(authorization and accounting) have independent management by the
	Diameter base protocol, which allows for finalizing the accounting		Diameter base protocol, which allows for finalizing the accounting
	session after the end of the authorization session.		session after the end of the authorization session.
	The detailed QoS accounting procedures are out of scope in this		The detailed QoS accounting procedures are out of scope in this
	document.		document.
	9. Examples		9. Examples
	9.1. Example Call Flow for Pull Mode		9.1. Example Call Flow for Pull Mode (Success Case)
	This section presents an example of the interaction between the end		This section presents an example of the interaction between the end
	host and Diameter QoS application entities using Pull mode. The		host and Diameter QoS application entities using Pull mode. The
	application layer signaling is, in this example, provided using SIP.		application layer signaling is, in this example, provided using SIP.
	Signaling for a QoS resource reservation is done using the QoS NSLP.		Signaling for a QoS resource reservation is done using the QoS NSLP.
	The authorization of the QoS reservation request is done by the		The authorization of the QoS reservation request is done by the
	Diameter QoS application (DQA).		Diameter QoS application (DQA).
	End-Host SIP Server Correspondent		End-Host SIP Proxy Correspondent
	requesting QoS (DQA Server) Node		requesting QoS (DQA Server) Node
	| | |		| | |
	..|....Application layer SIP signaling.......|..............|..		..|....Application layer SIP signaling.......|..............|..
	. | Invite (SDP) | | .		. | Invite (SDP) | | .
	. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | .		. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | .
	. | 100 Trying | | .		. | 100 Trying | | .
	. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| .		. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| .
	. | +-.-.-.....-.-.> .		. | +-.-.-.....-.-.> .
	. | | 180 SDP' | .		. | | 180 SDP' | .
	skipping to change at page 43, line 47 ¶		skipping to change at page 43, line 47 ¶
	| | |		| | |
	.-.-.-.-. SIP signaling		.-.-.-.-. SIP signaling
	--------- QoS NSLP signaling		--------- QoS NSLP signaling
	- - - - - Diameter QoS Application messages		- - - - - Diameter QoS Application messages
	========= Mapping of objects between QoS and AAA protocol		========= Mapping of objects between QoS and AAA protocol
	Figure 12: QoS Authorization Example - Pull Mode		Figure 12: QoS Authorization Example - Pull Mode
	The communication starts with SIP signaling between the two end		The communication starts with SIP signaling between the two end
	points and the SIP server for negotiation and authorization of the		points and the SIP proxy for negotiation and authorization of the
	requested service and its parameters (see Figure 12). As a part of		requested service and its parameters (see Figure 12). As a part of
	the process, the SIP server verifies whether the user at Host A is		the process, the SIP proxy verifies whether the user at Host A is
	authorized to use the requested service (and potentially the ability		authorized to use the requested service (and potentially the ability
	to be charged for the service usage). Negotiated session parameters		to be charged for the service usage). Negotiated session parameters
	are provided to the end host.		are provided to the end host.
	Subsequently, Host A initiates a QoS signaling message towards Host		Subsequently, Host A initiates a QoS signaling message towards Host
	B. It sends a QoS NSLP Reserve message, in which it includes		B. It sends a QoS NSLP Reserve message, in which it includes
	description of the required QoS (QSPEC object) and authorization data		description of the required QoS (QSPEC object) and authorization data
	for negotiated service session (part of the POLICY_DATA object).		for negotiated service session (part of the POLICY_DATA object).
	Authorization data includes, as a minimum, the identity of the AE		Authorization data includes, as a minimum, the identity of the AE
	(e.g., the SIP server) and an identifier of the application service		(e.g., the SIP proxy) and an identifier of the application service
	session for which QoS resources are requested.		session for which QoS resources are requested.
	A QoS NSLP Reserve message is intercepted and processed by the first		A QoS NSLP Reserve message is intercepted and processed by the first
	QoS aware Network Element. The NE uses the Diameter QoS application		QoS aware Network Element. The NE uses the Diameter QoS application
	to request authorization for the received QoS reservation request.		to request authorization for the received QoS reservation request.
	The identity of the AE (in this case the SIP server that is co-		The identity of the AE (in this case the SIP server that is co-
	located with a Diameter server) is put into the Destination-Host AVP,		located with a Diameter server) is put into the Destination-Host AVP,
	any additional session authorization data is encapsulated into the		any additional session authorization data is encapsulated into the
	QoS-Authorization-Data AVP and the description of the QoS resources		QoS-Authorization-Data AVP and the description of the QoS resources
	is included into QoS-Resources AVP. These AVPs are included into a		is included into QoS-Resources AVP. These AVPs are included into a
	skipping to change at page 44, line 40 ¶		skipping to change at page 44, line 40 ¶
	AVP), as well as duration of the authorization session		AVP), as well as duration of the authorization session
	(Authorization-Lifetime AVP).		(Authorization-Lifetime AVP).
	The NE interacts with the traffic control function and installs the		The NE interacts with the traffic control function and installs the
	authorized QoS resources and forwards the QoS NSLP Reserve message		authorized QoS resources and forwards the QoS NSLP Reserve message
	further along the data path. Moreover, the NE may serve as a		further along the data path. Moreover, the NE may serve as a
	signaling proxy and process the QoS signaling (e.g., initiation or		signaling proxy and process the QoS signaling (e.g., initiation or
	termination of QoS signaling) based on the QoS decision received from		termination of QoS signaling) based on the QoS decision received from
	the authorizing entity.		the authorizing entity.
	9.2. Example Call Flow for Push Mode		9.2. Example Call Flow for Pull Mode (Failure Case)
	This section presents an example of the interaction between the end-		This section illustrates the example shown Section 9.2 that fails due
			to an authorization failure. Failures can occur in various steps
			throughout the protocol execution and in this example we assume that
			the Diameter QAR request processed by the Diameter server leads to an
			unsuccessful result. The QAA message reponds, in this example, with
			a permanent error "DIAMETER_AUTHORIZATION_REJECTED" (5003)set in the
			Result-Code AVP. When the NE receives this response it discontinues
			the QoS reservation signaling downstream and provides an error
			message back to the end host that initiated the QoS signaling
			request. The QoS NSLP RESPONSE signaling message would in this case
			carry a INFO_SPEC object indicating the permanent failure as
			"Authorization failure" (0x02).
			End-Host SIP Proxy Correspondent
			requesting QoS (DQA Server) Node
			| | |
			..|...................SIP Signaling..........|..............|..
			. | Invite (SDP) | | .
			. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | .
			. | 100 Trying | | .
			. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| .
			. | +-.-.-.....-.-.> .
			. | | 180 SDP' | .
			. | <-.-.-.....-.-.+ .
			. | +--------+--------+ | .
			. | |Authorize session| | .
			. | | parameters | | .
			. | 180 (Session parameters) +--------+--------+ | .
			. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | .
			..|..........................................|... ..........|..
			| | |
			| +------------+ | |
			| | NE | | |
			| |(DQA Client)| | |
			| +------+-----+ | |
			| | | |
			|QoS NSLP Reserve | | |
			+------------------> QAR | |
			| (POLICY_DATA>v +- - - - -<<AAA>>- - - -> |
			| QSPEC) v >===>(Destination-Host, | |
			| v >=======>QoS-Authorization-Data++------------+ |
			| >===========>QoS-Resources) |Authorize | |
			| | |QoS resources| |
			| | ++------------+ |
			| | QAA | |
			| <- - - - -<<AAA>>- - - -+ |
			| |(Result-Code = 5003) | |
			| | | |
			|QoS NSLP Response | | |
			|(with error 0x02) | | |
			<------------------+ | |
			| | | |
			| | | |
			.-.-.-.-. SIP signaling
			--------- QoS NSLP signaling
			- - - - - Diameter QoS Application messages
			========= Mapping of objects between QoS and AAA protocol
			Figure 13: QoS Authorization Example - Pull Mode (Failure Case)
			9.3. Example Call Flow for Push Mode
			This section presents an example of the interaction between the end
	host and Diameter QoS application entities using Push mode. The		host and Diameter QoS application entities using Push mode. The
	application layer signaling is, in this example, provided using SIP.		application layer signaling is, in this example, provided using SIP.
	Signaling for a QoS resource reservation is done using the QoS NSLP.		Signaling for a QoS resource reservation is done using the QoS NSLP.
	The authorization of the QoS reservation request is done by the		The authorization of the QoS reservation request is done by the
	Diameter QoS application (DQA).		Diameter QoS application (DQA).
	End-Host NE SIP Server Correspondent		End-Host NE SIP Proxy Correspondent
	requesting QoS (DQA Client) (DQA Server) Node		requesting QoS (DQA Client) (DQA Server) Node
	| | | |		| | | |
	..|....Application layer SIP signaling..........|..............|..		..|..................|...SIP Signaling..........|..............|..
	. | Invite(SDP offer)| | | .		. | Invite(SDP Offer)| | | .
	. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.> | .		. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.->| .
	. | 100 Trying | | | .		. | | | 180 | .
	. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .		. |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.-.| .
	. |.............................................|..............| .		..|.............................................|..............|..
	| | +---------+-------------+|		| | +---------+-------------+|
	| | | Authorize request ||		| | | Authorize Request ||
	| | | Keep session data ||		| | | Keep Session Data ||
	| | |/Authz-time,Session-Id/||		| | |/Authz-time,Session-Id/||
	| | +---------+-------------+|		| | +---------+-------------+|
	| | | |		| | | |
	| |<-- - -- - QIR - -- - -- -+ |		| |<-- - -- - QIR - -- - -- -+ |
	| |(Initial Request,Decision | |		| |(Initial Request,Decision | |
	| |(QoS-Resources,Authz-time)| |		| |(QoS-Resources,Authz-time)| |
	| +-------+---------+ | |		| +-------+---------+ | |
	| |Install QoS state| | |		| |Install QoS State| | |
	| | + | | |		| | + | | |
	| | Authz. session | | |		| | Authz. Session | | |
	| | /Authz-time/ | | |		| | /Authz-time/ | | |
	| +-------+---------+ | |		| +-------+---------+ | |
	| + - - -- - QIA - - - - - ->| |		| + - - -- - QIA - - - - - ->| |
	| | (Result-Code, | |		| | (Result-Code, | |
	| | QoS-Resources) | |		| | QoS-Resources) | |
	| | +----------+------------+ |		| | +----------+------------+ |
	| | | Report for successful | |		| | | Successful | |
	| | | QoS reservation | |		| | | QoS Reservation | |
	| | |Update of reserved QoS | |
	| | | resources | |
	| | +----------+------------+ |		| | +----------+------------+ |
	. | | | Invite (SDP) | .		..|.............................................|..............|..
	. | | +-.-.-.....-.-.> .		. | | | | .
	. | 180 (Ringing) | | .
	. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.<.-.-.-.-.-.-.-+ .
	. | | | 200 OK (SDP)| .		. | | | 200 OK (SDP)| .
	. | | <-.-.-.....-.-.+ .		. | | <-.-.-.....-.-.+ .
	| | +--------+-----------+ |		. | | +--------+-----------+ | .
	| | |re-Authorize session| |
	| | | parameters | |		. | | | Activate Session | | .
	| | +--------+-----------+ |		. | | | Parameters | | .
			. | | +--------+-----------+ | .
			. | 200 (SDP) | | | .
			. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
			..|.............................................|..............|..
	| <- - - - - - RAR - - - - - + |		| <- - - - - - RAR - - - - - + |
	| +---------+--------+ | |		| +---------+--------+ | |
	| |Activate QoS state| | |		| |Activate QoS State| | |
	| +---------+--------+ | |		| +---------+--------+ | |
	| +- - - - - - RAA - - - - - > |		| +- - - - - - RAA - - - - - > |
	. | 200 (SDP answer) | | | .
	. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
	| | |		| | |
	/------------------+-----Data Flow---------------------------\		/------------------+-----Data Flow---------------------------\
	\------------------+-----------------------------------------/		\------------------+-----------------------------------------/
	| | |		| | |
	.-.-.-.-. SIP signaling		.-.-.-.-. SIP signaling
	- - - - - Diameter QoS Application messages		- - - - - Diameter QoS Application messages
	Figure 13: QoS Authorization Example - Push Mode		Figure 14: QoS Authorization Example - Push Mode
	The communication starts with SIP signaling between the two end		The communication starts with SIP signaling between the two end
	points and the SIP server for negotiation and authorization of the		points and the SIP proxy for negotiation and authorization of the
	requested service and its parameters (see Figure 13). As a part of		requested service and its parameters (see Figure 14). As a part of
	the process, the SIP server verifies whether the user at Host A is		the process, the SIP proxy verifies whether the user at Host A is
	authorized to use the requested service (and potentially the ability		authorized to use the requested service (and potentially the ability
	to be charged for the service usage). The DQA server is triggered to		to be charged for the service usage).
	authorize the QoS request based on session parameters (i.e., SDP
	offer), initiate a Diameter QoS authorization session and install
	authorized QoS state to the Network Element via QIR message.
	The DQA server may obtain the info of peer DQA client from pre-		A few implementation choices exist regarding the decision about when
	configured information or query the DNS based on Host A's identity or		to initiate the QoS reservation.
	IP address (In this case a DQA server is co-located with a SIP server		[I-D.ietf-mmusic-media-path-middleboxes] discusses this aspect with a
	and a DQA client is co-located with a NE). The identity of Network		focus on firewalling. In the example above the DQA server is
	Element is put into the Destination-Host AVP, the description of the		triggered to authorize the QoS request based on session parameters
	QoS resources is included into QoS-Resources AVP, as well as duration		from the SDP payload. It will use a QIR message to do so. For this
	of the authorization session (Authorization-Lifetime AVP). The NE		example message flow we assume a two-stage commit, i.e. the SIP proxy
	interacts with the traffic control function and reserves the		interacts with the NE twice. First, it only prepares the QoS
	authorized QoS resources accordingly, for instance, the NE may serve		reservation and then with the arrival of the 200 OK the QoS
	as a signaling proxy and process the QoS signaling (e.g., initiation		reservation is activated.
	or termination of QoS signaling) based on the QoS decision received
	from the authorizing entity.
	With successful QoS authorization, the SDP offer in SIP Invite is		This example does not describe how the DQA server learns which DQA
	forwarded to Host B. Host B sends back a 18x (ringing) message		client to contact. We assume pre-configuration in this example. In
	towards Host A and processes the SDP. Once Host B accepts the call,		any case, the address of DQA client is put into the Destination-Host
	it sends back a 200 OK, in which it includes description of the		AVP, the description of the QoS resources is included into QoS-
	accepted session parameters (i.e., SDP answer).		Resources AVP, and the duration of the authorization session is
			carried in the Authorization-Lifetime AVP.
	The DQA server may verify the accepted QoS against the pre-authorized		When the DQA client receives the QIR it interacts with the traffic
	QoS resources, and sends a Diameter RAR message to the DQA client in		control function and reserves the authorized QoS resources
	the NE for activating the installed policies and commit the resource		accordingly. At this point in time the QoS reservation is not yet
	allocation. With successful QoS enforcement, the 200 OK is forwarded		activated.
	towards Host A.
	Note that the examples above show a sender-initiated reservation from		When a 200 OK is returned the DQA server may verify the accepted QoS
	the end host towards the corresponding node and a receiver-initiated		against the pre-authorized QoS resources, and sends a Diameter RAR
	reservation from the correspondent node towards the end host.		message to the DQA client in the NE for activating the installed
			policies and commit the resource allocation.
	10. IANA Considerations		10. IANA Considerations
	This section contains the namespaces that have either been created in		This section contains the namespaces that have either been created in
	this specification or had their values assigned to existing		this specification or had their values assigned to existing
	namespaces managed by IANA.		namespaces managed by IANA.
	10.1. AVP Codes		10.1. AVP Codes
	IANA is requested to allocate two AVP codes to the registry defined		IANA is requested to allocate two AVP codes to the registry defined
	skipping to change at page 48, line 9 ¶		skipping to change at page 51, line 9 ¶
	-----------------------------------------------------------		-----------------------------------------------------------
	TBD QoS-Authorization-Request (QAR) Section 5.1		TBD QoS-Authorization-Request (QAR) Section 5.1
	TBD QoS-Authorization-Answer (QAA) Section 5.2		TBD QoS-Authorization-Answer (QAA) Section 5.2
	TBD QoS-Install-Request (QIR) Section 5.3		TBD QoS-Install-Request (QIR) Section 5.3
	TBD QoS-Install-Answer (QIA) Section 5.4		TBD QoS-Install-Answer (QIA) Section 5.4
	11. Security Considerations		11. Security Considerations
	This document describes a mechanism for performing authorization of a		This document describes a mechanism for performing authorization of a
	QoS reservation at a third party entity. The Authorizing Entity		QoS reservation at a third party entity. The Authorizing Entity
	needs sufficient information to make such an authorization decision.		needs sufficient information to make such an authorization decision
	Information may come from various sources, including the application		and this information may come from various sources, including the
	layer signaling, the Diameter protocol (with its security		application layer signaling, the Diameter protocol (with its security
	mechanisms), from policy information stored available with a AAA		mechanisms), from policy information stored available with a AAA
	server and from a QoS signaling protocol.		server and from a QoS signaling protocol.
	Below there is a discussion about considerations for the Diameter QoS		Below there is a discussion about considerations for the Diameter QoS
	interaction between an Authorizing Entity and a Network Element.		interaction between an Authorizing Entity and a Network Element.
	Security between the Authorizing Entity and the Network Element has a		Security between the Authorizing Entity and the Network Element has a
	number of components: authentication, authorization, integrity and		number of components: authentication, authorization, integrity and
	confidentiality.		confidentiality.
	Authentication refers to confirming the identity of an originator for		Authentication refers to confirming the identity of an originator for
	skipping to change at page 52, line 32 ¶		skipping to change at page 55, line 32 ¶
	[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,		[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
	"Diameter Network Access Server Application", RFC 4005,		"Diameter Network Access Server Application", RFC 4005,
	August 2005.		August 2005.
	[RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of		[RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
	Service Parameters for Usage with Diameter", RFC 5624,		Service Parameters for Usage with Diameter", RFC 5624,
	August 2009.		August 2009.
	14.2. Informative References		14.2. Informative References
			[I-D.ietf-mmusic-media-path-middleboxes]
			Stucker, B. and H. Tschofenig, "Analysis of Middlebox
			Interactions for Signaling Protocol Communication along
			the Media Path",
			draft-ietf-mmusic-media-path-middleboxes-02 (work in
			progress), March 2009.
	[I-D.ietf-nsis-ntlp]		[I-D.ietf-nsis-ntlp]
	Schulzrinne, H. and M. Stiemerling, "GIST: General		Schulzrinne, H. and M. Stiemerling, "GIST: General
	Internet Signalling Transport", draft-ietf-nsis-ntlp-20		Internet Signalling Transport", draft-ietf-nsis-ntlp-20
	(work in progress), June 2009.		(work in progress), June 2009.
	[I-D.ietf-nsis-qos-nslp]		[I-D.ietf-nsis-qos-nslp]
	Manner, J., Karagiannis, G., and A. McDonald, "NSLP for		Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
	Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18		Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
	(work in progress), January 2010.		(work in progress), January 2010.
End of changes. 32 change blocks.
	87 lines changed or deleted		153 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/