draft-alfano-aaa-qosprot-00.txt		draft-alfano-aaa-qosprot-01.txt
	Authentication, Authorization and F. Alfano		Authentication, Authorization and F. Alfano
	Accounting P. McCann		Accounting P. McCann
	Internet-Draft Lucent Technologies		Internet-Draft Lucent Technologies
	Expires: January 10, 2005 H. Tschofenig		Expires: April 23, 2005 H. Tschofenig
	Siemens		Siemens
	July 12, 2004		October 23, 2004
	Diameter Quality of Service Application		Diameter Quality of Service Application
	draft-alfano-aaa-qosprot-00.txt		draft-alfano-aaa-qosprot-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		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 become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 10, 2005.		This Internet-Draft will expire on April 23, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	This document describes a Diameter Application that performs		This document describes a Diameter Application that performs
	Authentication, Authorization, and Accounting for Quality-of-Service		Authentication, Authorization, and Accounting for Quality-of-Service
	reservations. This protocol is used by elements along the path of a		reservations. This protocol is used by elements along the path of a
	given application flow to authenticate a reservation request, ensure		given application flow to authenticate a reservation request, ensure
	that the reservation is authorized, and to account for resources used		that the reservation is authorized, and to account for resources used
	during the life of the application flow. This QoS AAA protocol may		during the life of the application flow. Clients that implement the
	be used between any bearer-level network element that lies on the		Diameter QoS Application contact an authorizing entity/application
	path of an application flow and an application server that lies		server that lies anywhere in the network, allowing for a wide variety
	anywhere in the network, allowing for a wide variety of flexible		of flexible service deployment models.
	service deployment models.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		1.1 Deployment architecture . . . . . . . . . . . . . . . . . 4
	3. QoS Authorization for a Session . . . . . . . . . . . . . . . 7		1.2 Network element functional model . . . . . . . . . . . . . 5
	3.1 Session Establishment . . . . . . . . . . . . . . . . . . 7		1.3 Requirements for QoS AAA protocol . . . . . . . . . . . . 6
	3.2 QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 7		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3 Session Termination . . . . . . . . . . . . . . . . . . . 7		3. QoS Application messages . . . . . . . . . . . . . . . . . . . 10
	4. Diameter QoS Messages . . . . . . . . . . . . . . . . . . . . 8		4. QoS Authorization session . . . . . . . . . . . . . . . . . . 11
	4.1 QoS-Request (QAR) Command . . . . . . . . . . . . . . . . 8		4.1 Authorization models . . . . . . . . . . . . . . . . . . . 11
	4.2 QoS-Answer (QAA) Command . . . . . . . . . . . . . . . . . 8		4.2 Session Initiation . . . . . . . . . . . . . . . . . . . . 12
	5. Diameter QoS AVPs . . . . . . . . . . . . . . . . . . . . . . 10		4.3 Session Establishment . . . . . . . . . . . . . . . . . . 13
	5.1 Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 10		4.4 QoS Re-Authorization . . . . . . . . . . . . . . . . . . . 13
	5.2 Credit Control . . . . . . . . . . . . . . . . . . . . . . 10		4.4.1 Client-side initiated Re-Authorization . . . . . . . . 13
	5.3 Authentication/Authorization . . . . . . . . . . . . . . . 11		4.4.2 Server-side initiated Re-Authorization . . . . . . . . 13
	5.4 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 11		4.5 Session Termination . . . . . . . . . . . . . . . . . . . 13
	5.5 Diameter QoS Application Defined AVPs . . . . . . . . . . 11		4.5.1 Client-side initiated session termination . . . . . . 14
	5.6 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 13		4.5.2 Server-side initiated session termination . . . . . . 14
	5.7 Security Considerations . . . . . . . . . . . . . . . . . 16		5. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 17		6. Diameter QoS Messages . . . . . . . . . . . . . . . . . . . . 16
	5.9 Open Issues . . . . . . . . . . . . . . . . . . . . . . . 17		6.1 QoS-Request (QAR) Command . . . . . . . . . . . . . . . . 16
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		6.2 QoS-Answer (QAA) Command . . . . . . . . . . . . . . . . . 16
	6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19		7. Diameter QoS AVPs . . . . . . . . . . . . . . . . . . . . . . 18
	6.2 Informative References . . . . . . . . . . . . . . . . . . . 19		7.1 Diameter Base Protocol AVPs . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21		7.2 Credit Control . . . . . . . . . . . . . . . . . . . . . . 18
	A. AVP Formats . . . . . . . . . . . . . . . . . . . . . . . . . 22		7.3 Authentication/Authorization . . . . . . . . . . . . . . . 19
	A.1 RSVP to Diameter QoS AVPs Mapping . . . . . . . . . . . . 22		7.4 Accounting AVPs . . . . . . . . . . . . . . . . . . . . . 19
	A.1.1 RSVP Objects for the QoS-RSVP AVP . . . . . . . . . . 22		7.5 Diameter QoS Application Defined AVPs . . . . . . . . . . 19
	A.1.2 RSVP Objects for the Filter-Rule AVP . . . . . . . . . 24		8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	A.1.3 RSVP Objects for the QoS-Auth-Resources . . . . . . . 26		9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
	A.2 NSIS to Diameter QoS AVPs Mapping . . . . . . . . . . . . 26		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27
	A.3 SIP to Diameter QoS AVPs Mapping . . . . . . . . . . . . . 27		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	Intellectual Property and Copyright Statements . . . . . . . . 28		12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
			13.1 Normative References . . . . . . . . . . . . . . . . . . . . 30
			13.2 Informative References . . . . . . . . . . . . . . . . . . . 30
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31
			A. AVP Formats . . . . . . . . . . . . . . . . . . . . . . . . . 33
			A.1 NSIS to Diameter QoS AVPs Mapping . . . . . . . . . . . . 33
			A.1.1 NSIS QSpecs Template structure . . . . . . . . . . . . 33
			A.1.2 AVP format . . . . . . . . . . . . . . . . . . . . . . 34
			A.2 SIP to Diameter QoS AVPs Mapping . . . . . . . . . . . . . 37
			Intellectual Property and Copyright Statements . . . . . . . . 38
	1. Introduction		1. Introduction
	To meet the quality-of-service needs of applications such as		To meet the quality-of-service needs of applications such as
	voice-over-IP, it will often be necessary to explicitly request		voice-over-IP in a heavily loaded network, packets belonging to
	resources from the network. This will allow the network to identify		real-time application flows must be identified and segregated from
	packets belonging to these application flows and ensure that		other traffic to ensure that bandwidth, delay, and loss rate
	bandwidth, delay, and error rate requirements are met. By performing		requirements are met. In addition, new flows should not be added to
	admission control on individual flows, the network can avoid		the network when it is at or near capacity, which would result in
	congestion and the resulting high packet drop rates.		degradation of quality for all flows carried by the network.
	When bandwidth is expensive and must be carefully managed, such as in		In some cases, these goals can be achieved with mechanisms such as
	wide-area cellular networks, and/or when applications and transport		differentiated services and/or end-to-end congestion and admission
	protocols lack the capability or cannot be trusted to perform		control. However, when bandwidth is scarce and must be carefully
	congestion control, explicit reservation techniques are required. A		managed, such as in wide-area cellular networks, or when applications
	variety of protocols could be used to make a reservation request,		and transport protocols lack the capability to perform end-to-end
	such as:		congestion control, explicit reservation techniques are required. In
			these cases, the endpoints will send reservation requests to edge
			and/or interior nodes along the communication path. In addition to
			verifying whether resources are available, the recipient of a
			reservation request must also authenticate and authorize the request,
			especially in an environment where the endpoints are not trusted. In
			addition, these nodes will generate accounting information about the
			resources used and attribute usage to the requesting endpoints. This
			will enable the owner of the network element to generate
			usage-sensitive billing records and to understand how to allocate new
			network capacity.
	o RSVP		A variety of protocols could be used to make a reservation request,
	o NSIS		including RSVP [RFC2210], NSIS [I-D.ietf-nsis-qos-nslp],
	o Link-specific means		link-specific messaging or even SIP/SDP [RFC2327]. This document
	o SIP/SDP		focuses on supporting the NSIS QoS NSLP. This will have an
	+------+ +------+		implication on the content and format of the flow identifiers and QoS
	| Subs | | |		attributes that represent a particular reservation request within the
	| DB | | AS |		Diameter QoS Application; however, other aspects of its operation
	| | | |		should be easily generalizable to other reservation protocols. The
	+---\--+ +---/--+		Diameter QoS Application could be used directly in the context of
	\ /		these other reservation protocols, given the definition of a suitable
	\ /		conversion between the representations used by those protocols and
	/-\----------/\		the ones used by NSIS.
			The Diameter QoS Application runs between a network element receiving
			QoS reservation requests (acting as a AAA client) and the resource
			authorizing entity (acting as a AAA server). A high-level picture of
			the resulting architecture is shown in Figure 1.
			+-------------+
			| Resource |
			| Authorizing |
			| Entity |
			+-----+-------+
			|
			|
			/\-----+-----/\
	//// \\\\		//// \\\\
	|| ||		|| ||
	| AAA Cloud |		| AAA Cloud |
	|| ||		|| ||
	\\\\ ////		\\\\ ////
	\-------+-----/		\-------+-----/
	|		|
	+---+--+		+---+--+ +---+--+ +---+--+
	Application | |		Application | | | | | |
	Flow ===============+ BE +==========>>		===============+ NE +===+ NE +===+ NE +========>>
	| |		Flow | | | | | |
	+------+		+------+ +------+ +------+
	Figure 1: An architecture supporting QoS-AAA		Figure 1: An Architecture supporting QoS-AAA
	Figure 1 depicts a bearer element through which application flows		1.1 Deployment architecture
	need to pass, a cloud of AAA servers, a database containing
	subscriber records, and an application server. Here the term "AAA
	Cloud" is used to refer to the network of AAA proxy/broker
	arrangements that may be in place. Also, note that there may be more
	than one bearer element that needs to interact with the AAA cloud
	along the path of a given application flow, although the figure only
	depicts one for clarity. Similarly, a given user may have subscriber
	records stored in more than one place and might make use of multiple
	application servers. In the simplest case, bearer elements will
	request authentication and authorization for QoS from the AAA cloud,
	which will route the request to the home network and consult a static
	subscriber record of the endpoint making the request and return a
	grant/deny decision. In more complex deployment models, the
	authorization will be based on dynamic application state, so the
	request must be authenticated and authorized based on information
	from one or more application servers. If defined properly, the
	interface between the bearer element and AAA cloud would be identical
	in both cases. Bearer elements are therefore insulated from the
	details of particular applications and need not know that application
	servers are involved at all. Also, the AAA cloud would naturally
	encompass business relationships such as those between network
	operators and third-party application providers, enabling flexible
	intra- or inter-domain authorization, accounting, and settlement.
	This document describes a Diameter Application protocol that is used		Figure 1 depicts network elements through which application flows
	for AAA in an environment where user applications request better than		need to pass, a cloud of AAA servers, and an authorizing entity.
	best effort Quality of Service. This Diameter QoS application		Note that there may be more than one router that needs to interact
	protocol when combined with [RFC3588], satisfies the QoS related		with the AAA cloud along the path of a given application flow,
	requirements defined in [I-D.alfano-aaa-qosreq].		although the figure only depicts one for clarity. Routers will
			request authorization for QoS from the AAA cloud, which will route
			the request to the home network where the home authorizing entity
			will return a grant/deny decision.
	This document first describes the operation of a Diameter QoS		In more complex deployment models, the authorization will be based on
	application. Then it defines the Diameter message Command-Codes.		dynamic application state, so the request must be authenticated and
	The following sections enumerate the AVPs used in these messages.		authorized based on information from one or more application servers.
			If defined properly, the interface between the routers and AAA cloud
			would be identical in both cases. Routers are therefore insulated
			from the details of particular applications and need not know that
			application servers are involved at all. Also, the AAA cloud would
			naturally encompass business relationships such as those between
			network operators and third-party application providers, enabling
			flexible intra- or inter-domain authorization, accounting, and
			settlement.
			1.2 Network element functional model
			Figure 2 depicts a logical operational model of resource management
			in a router.
			+-----------------------------------------------------+
			| DIAMETER Client |
			| Functionality |
			| +---------------++---------------++---------------+ |
			| | User || Authorization || Accounting | |
			| | Authentication|| of QoS || for QoS | |
			| +---------------+| Requests || Traffic | |
			| +---------------++---------------+ |
			+-----------------------------------------------------+
			^ ^
			v v
			+--------------+ +----------+
			|QoS Signaling | | Resource |
			|Msg Processing|<<<<<>>>>>>>|Management|
			+--------------+ +----------+
			. ^ | * ^
			| v . * ^
			+-------------+ * ^
			|Signaling msg| * ^
			| Processing | * V
			+-------------+ * V
			| | * V
			++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
			. . * V
			| | * .............................
			. . * . Traffic Control .
			| | * . +---------+.
			. . * . |Admission|.
			| | * . | Control |.
			+----------+ +------------+ . +---------+.
			<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
			| Packet | | Interface | .+----------+ +---------+.
			===>|Processing|====| Selection |===.| Packet |====| Packet |.=>
			| | |(Forwarding)| .|Classifier| Scheduler|.
			+----------+ +------------+ .+----------+ +---------+.
			.............................
			<.-.-> = signaling flow
			=====> = data flow (sender --> receiver)
			<<<>>> = control and configuration operations
			****** = routing table manipulation
			Figure 2: Network element functional model
			Processing of incoming QoS reservation requests include 3 actions:
			admission control, authorization and resource reservation.
			Admission control local function provides information for available
			resources and if they are enough to fulfill requested QoS.
			Authorization is performed by Diameter client function which involves
			contacting an authorization entity, lying anywhere in the network,
			through the AAA cloud introduced in Section 1.1. If both checks
			succeed, auhorized QoS parameters /they MIGHT be different from
			requested QoS/ are set in the Packet classifier and Packet scheduler
			to obtain the authorized QoS. Once the requested service is being
			provided, Resource management provides accounting information to the
			Authorizing entity using the Diameter client function.
			1.3 Requirements for QoS AAA protocol
			Intended deployment architecture and functionalities put a number of
			requirements on the Diameter QoS application. These requirements are
			reviewed in details in [I-D.alfano-aaa-qosreq]. A short list is
			provided here:
			Inter-domain support
			In particular, users may roam outside their home network, leading
			to a situation where the network element and authorizing entity
			are in different administrative domains.
			Identity-based Routing
			The QoS AAA protocol MUST route AAA requests to the authorizing
			entity based on the identity information given in the QoS
			signaling protocol.
			Flexible Authentication Support
			The QoS AAA protocol MUST support a variety of different
			authentication protocols for verification of authentication
			information present in QoS signaling messages.
			Making an Authorization Decision
			The QoS AAA protocol MUST exchange sufficient information between
			the authorizing entity and the enforcing entity (and vice versa)
			to compute an authorization decision and to execute this decision.
			Triggering an Authorization Process
			The QoS AAA protocol MUST allow periodic and event triggered
			execution of the authorization process, originated at the
			enforcing entity or even at the authorizing entity.
			Associating QoS Reservations and Application State
			The QoS AAA protocol MUST carry information sufficient for an
			application server to identify the appropriate application session
			and associate it with a particular QoS reservation.
			Dynamic Authorization
			It MUST be possible for QoS AAA protocol to push updates towards
			the network element(s) from authorizing entities.
			Bearer Gating
			The QoS AAA protocol MUST allow the authorizing entity to gate
			authorized application flows e.g. based on application state
			transitions.
			Accounting Records
			The QoS AAA protocol MUST define QoS accounting records containing
			duration, volume (byte count) usage information and description of
			the QoS attributes (e.g., bandwidth, delay, loss rate) that were
			supported for the flow.
			Sending Accounting Records
			The network element MUST send accounting records for a particular
			application flow to the authorizing entity for that flow or to
			another entity identified by the authorizing entity.
			Failure Notification
			The QoS AAA protocol MUST allow the network element to report
			failures(such as loss of connectivity due to movement of a mobile
			node or other reasons for packet loss) to the authorizing entity.
			Accounting Correlation
			The QoS AAA protocol MUST support the exchange of sufficient
			information to allow for correlation between accounting records
			generated by the network elements and accounting records generated
			by an application server.
			Interaction with other AAA Applications
			Interaction with other AAA applications such as
			[I-D.ietf-aaa-diameter-cc] and [I-D.ietf-aaa-diameter-nasreq] is
			required for exchange of authorization, authentication and
			accounting information.
			This document first defines used Diameter messages and Command-Codes.
			Then it describes the operation of a Diameter QoS Application. The
			following sections enumerate the Diameter message Command-Codes and
			AVPs used in these messages.
			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 [RFC2119].
			Application Server
			An application server is a network entity that exchanges signaling
			messages with an application endpoint. It may be a source of
			authorization for QoS-enhanced application flows. For example, a
			SIP server is one kind of application server.
			Application Endpoint
			An application endpoint is an entity in an end user device that
			exchanges signaling messages with application servers or directly
			with other application endpoints. Based on the result of this
			signaling, the endpoint will make a request for QoS from the
			network. For example, a SIP User Agent is one kind of application
			endpoint.
			Authorizing Entity
			The authorizing entity is that entity responsible for authorizing
			QoS requests for a particular application flow. This may be a AAA
			server (with a subscriber database) or an application server or
			some other entity.
			AAA Cloud
			A network of AAA proxy/broker arrangements.
			Furthermore, we use terminology defined in [RFC3588].
			3. QoS Application messages
			The purposes of QoS Authorization requires definition of new
			mandatory AVPs and Command-Codes for the QoS Diameter application.
			Two new Diameter messages are defined:
			Command-Name Abbrev. Code Reference
			QoS-Request QAR XXX 6.1
			QoS-Answer QAA XXX 6.2
			Also following Diameter-base messages are used:
			Command-Name Abbrev. Code Reference
			Accounting-Request ACR 271 [RFC3588]
			Accounting-Answer ACA 271 [RFC3588]
			Re-Auth-Request RAR 258 [RFC3588]
			Re-Auth-Answer RAA 258 [RFC3588]
			Abort-Session-Request ASR 274 [RFC3588]
			Abort-Session-Answer ACA 274 [RFC3588]
			Session-Term-Request STR 275 [RFC3588]
			Session-Term-Answer STA 275 [RFC3588]
	Diameter nodes conforming to this specification MAY advertise support		Diameter nodes conforming to this specification MAY advertise support
	by including the value of TBD in the Auth-Application-Id or the		by including the value of TBD in the Auth-Application-Id or the
	Acct-Application-Id AVP of the Capabilities-Exchange-Request and		Acct-Application-Id AVP of the Capabilities-Exchange-Request and
	Capabilities-Exchange-Answer commands [RFC3588].		Capabilities-Exchange-Answer commands [RFC3588].
	The value of TBD (TBD) MUST be used as the Application-Id in all QAR		The value of TBD (TBD) MUST be used as the Application-Id in all QAR
	and QAA commands. The value of TBD (TBD) MUST be used as the		and QAA commands. The value of TBD (TBD) MUST be used as the
	Application-Id in all ACR/ACA commands, because this application		Application-Id in all ACR/ACA commands, because this application
	defines new, mandatory AVPs for accounting. The value of zero (0)		defines new, mandatory AVPs for accounting. The value of zero (0)
	SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and		SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and
	RAR/RAA commands, because these are defined in the Diameter base		RAR/RAA commands, because these are defined in the Diameter base
	protocol and no additional mandatory AVPs for those commands are		protocol and no additional mandatory AVPs for those commands are
	defined in this document.		defined in this document.
	2. Terminology		4. QoS Authorization session
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		4.1 Authorization models
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC-2119 [RFC2119].
	Furthermore, we use terminology defined in [RFC3588].		In respect to NSIS signaling, different authorization models are
			present. They are discussed in details in
			[I-D.tschofenig-nsis-aaa-issues]. From the prospective of the
			Diameter QoS application these models differ in authentication and
			authorization information that need to be carried. Here we focus on
			the "Tree party approach" model(Figure 5) and its derivation "Token
			based three party approach"(fig-three-party-token-approach).
	3. QoS Authorization for a Session		+--------------+
			| Entity |
			| authorizing | <......+
			| resource | .
			| request | .
			+------------+-+ .
			--^----------|-- . .
			///// | | \\\\\ .
			// | | \\ .
			| QoS | QoS AAA | QoS |.
			| authz| protocol |authz |.
			| req.| | res. |.
			\\ | | // .
			\\\\\ | | ///// .
			QoS --|----------v-- . .
			+-------------+ request +-+------------+ .
			| Entity |----------------->| BE | .
			| requesting | | performing | .
			| resource |granted / rejected| QoS | <.....+
			| |<-----------------| reservation | financial
			+-------------+ +--------------+ settlement
			Figure 5: Three party approach
			In "Tree party approach" model, a resource request by the end host is
			received at the router in the local network and then forwarded to the
			user's home network where authorization is provided. The response is
			then returned and resources are granted (in case of a successful
			authorization decision). The interaction between the visited network
			and the home network establishes the necessary financial
			infrastructure to latter charge the user for the consumed resources.
			financial settlement
			...........................+
			Authorization V ------- .
			Token Request +--------------+ / QoS AAA \ .
			+-------------->| Entity | / protocol \ .
			| | authorizing +--------------+ \ .