draft-ietf-mboned-multiaaa-framework-06.txt		draft-ietf-mboned-multiaaa-framework-07.txt
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	Internet Draft Hiroaki Satou, NTT		Internet Draft Hiroaki Satou, NTT
	Intended Status: Hiroshi Ohta, NTT		Intended Status: Hiroshi Ohta, NTT
	Informational		Informational
	Expires: August Christian Jacquenet, France Telecom		Expires: January Christian Jacquenet, France Telecom
	22, 2008		3, 2009
	Tsunemasa Hayashi, NTT		Tsunemasa Hayashi, NTT
	Haixiang He, Nortel Networks		Haixiang He, Nortel Networks
	February 25, 2007		July 1, 2008
	AAA Framework for Multicasting		AAA and Admission Control Framework for Multicasting
	<draft-ietf-mboned-multiaaa-framework-06.txt>		<draft-ietf-mboned-multiaaa-framework-07.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author		By submitting this Internet-Draft, each author represents
	represents that any applicable patent or other IPR		that any applicable patent or other IPR claims of which he
	claims of which he or she is aware have been or will		or she is aware have been or will be disclosed, and any of
	be disclosed, and any of which he or she becomes		which he or she becomes aware will be disclosed, in
	aware will be disclosed, in accordance with Section		accordance with Section 6 of BCP 79.
	6 of BCP 79.
	Internet-Drafts are working documents of the		Internet-Drafts are working documents of the Internet
	Internet Engineering Task Force (IETF), its areas,		Engineering Task Force (IETF), its areas, and its working
	and its working groups. Note that other groups may		groups. Note that other groups may also distribute working
	also distribute working documents as Internet-		documents as Internet-Drafts.
	Drafts.
	Internet-Drafts are draft documents valid for a		Internet-Drafts are draft documents valid for a maximum of
	maximum of six months and may be updated, replaced,		six months and may be updated, replaced, or obsoleted by
	or obsoleted by other documents at any time. It is		other documents at any time. It is inappropriate to use
	inappropriate to use Internet-Drafts as reference		Internet-Drafts as reference material or to cite them other
	material or to cite them other than as "work in		than as "work in progress."
	progress."
	The list of current Internet-Drafts can be accessed		The list of current Internet-Drafts can be accessed at
	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		The list of Internet-Draft Shadow Directories can be
	accessed at http://www.ietf.org/shadow.html.		accessed at http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 22, 2008.		Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
			This Internet-Draft will expire on January 3, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008). This document		Copyright (C) The IETF Trust (2008). This document is
	is subject to the rights, licenses and restrictions		subject to the rights, licenses and restrictions contained
	contained in BCP 78, and except as set forth		in BCP 78, and except as set forth therein, the authors
	therein, the authors retain all their rights.		retain all their rights.
	Abstract		Abstract
	IP multicast-based services, such as TV broadcasting		IP multicast-based services, such as TV broadcasting or
	or videoconferencing raise the issue of making sure		videoconferencing raise the issue of making sure that
	that potential customers are fully entitled to		potential customers are fully entitled to access the
	access the corresponding contents. There is indeed a		corresponding contents. There is indeed a need for service
	need for service and content providers to identify		and content providers to identify users (if not
	(if not authenticate, especially within the context		authenticate, especially within the context of enforcing
	of enforcing electronic payment schemes) and to		electronic payment schemes) and to retrieve statistical
	invoice such customers in a reliable and efficient		information for accounting purposes, as far as content and
	manner. This memo describes the framework for		network usage are concerned. This memo describes the
	specifying the Authorization, Authentication and		framework for specifying the Authorization, Authentication
	Accounting (AAA) capabilities that could be		and Accounting (AAA) capabilities that could be activated
	activated within the context of the deployment and		within the context of the deployment and the operation of
	the operation of IP multicast-based services. This		IP multicast-based services. This framework addresses the
	framework addresses the requirements presented in		requirements presented in "Requirements for Accounting,
	draft-ietf-mboned-maccnt-req-04.txt, "Requirements		Authentication and Authorization in Well Managed IP
	for Accounting, Authentication and Authorization in		Multicasting Services" [I-D.mboned-maccnt-req]. The memo
	Well Managed IP Multicasting Services". The memo		provides a basic AAA enabled model as well as an extended
	provides a basic AAA enabled model as well as an		fully enabled model with resource and admission control
	extended fully enabled model with resource and		coordination.
	admission control coordination.
	Table of Contents		Table of Contents
	1. INTRODUCTION 4		1. INTRODUCTION 4
	1.1 PURPOSE AND BACKGROUND 4		1.1 PURPOSE AND BACKGROUND 4
	2. DEFINITIONS AND ABBREVIATIONS 5		2. DEFINITIONS AND ABBREVIATIONS 5
	2.1 DEFINITIONS 5		2.1 DEFINITIONS 5
	2.2 ABBREVIATIONS 6		2.2 ABBREVIATIONS 6
	3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7		3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7
	4. FRAMEWORK AND ROLES OF ENTITIES 8		4. FRAMEWORK AND ROLES OF ENTITIES 9
	4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 8		4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 9
	4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9		4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9
	4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 10		4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 11
	4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 10		4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11
	4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 10		4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11
	4.2 USER ID 11		4.2 USER ID 12
	4.2.1 CP-ASSIGNED USER ID 11		4.2.1 CP-ASSIGNED USER ID 12
	4.2.2 NSP-ASSIGNED USER ID 11		4.2.2 NSP-ASSIGNED USER ID 12
	4.3 ACCOUNTING 12		4.3 ACCOUNTING 13
	4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13		4.4 ACCESS CONTROL AND CP SELECTION BY NSP 14
	4.5 ADMISSION CONTROL INFORMATION BY NSP 13		4.5 ADMISSION CONTROL INFORMATION BY NSP 14
	4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14		4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 15
	4.7 AAA PROXY IN NSP 14		Internet Draft AAA and Admission Control Framework for
	5.1 BASIC CONNECTION MODEL 15		Multicasting July, 2008
			4.7 AAA PROXY IN NSP 15
			5.1 BASIC CONNECTION MODEL 16
	5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY		5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY
	ENABLED AAA FRAMEWORK 15		ENABLED AAA FRAMEWORK 17
	5.3 MODULARITY OF THE FRAMEWORK 19		5.3 MODULARITY OF THE FRAMEWORK 21
	6. IANA CONSIDERATIONS 19		6. IANA CONSIDERATIONS 21
	7. SECURITY CONSIDERATIONS 19		7. SECURITY CONSIDERATIONS 21
	8. CONCLUSION 19		8. CONCLUSION 21
	1. Introduction		1. Introduction
	1.1 Purpose and Background		1.1 Purpose and Background
	IP multicasting is designed to serve cases of group		IP multicasting is designed to serve cases of group
	communication schemes of any kind, such as 1-to-n (case of		communication schemes of any kind, such as one-to-many
	TV broadcasting services for example) or n-to-p (case of		(case of TV broadcasting services for example) or many-to-
	videoconferencing services, for example).		many (case of videoconferencing services, for example).
	In these environments, IP multicast provides a better		In these environments, IP multicast provides a better
	resource optimization than using a unicast transmission		resource optimization than using a unicast transmission
	scheme, where data need to be replicated as many times as		scheme, where data need to be replicated as many times as
	there are receivers. Activation of IP multicast		there are receivers. Activation of IP multicast
	capabilities in networks yields the establishment and the		capabilities in networks yields the establishment and the
	maintenance of multicast distribution trees that are		maintenance of multicast distribution trees that are
	receiver-initiated by nature: multicast-formatted data are		receiver-initiated by nature: multicast-formatted data are
	forwarded to receivers who explicitly request them.		forwarded to receivers who explicitly request them.
	IP multicast-based services, such as TV broadcasting or		IP multicast-based services, such as TV broadcasting or
	skipping to change at page 5, line 5		skipping to change at page 5, line 5
	corresponding contents. There is indeed a need for service		corresponding contents. There is indeed a need for service
	and content providers to identify (if not authenticate,		and content providers to identify (if not authenticate,
	especially within the context of enforcing electronic		especially within the context of enforcing electronic
	payment schemes) and to invoice such customers in a		payment schemes) and to invoice such customers in a
	reliable and efficient manner. Solutions should consider a		reliable and efficient manner. Solutions should consider a
	wide range of possible content delivery applications:		wide range of possible content delivery applications:
	content delivered over the multicast network may include		content delivered over the multicast network may include
	video, audio, images, games, software and information such		video, audio, images, games, software and information such
	as financial data, etc.		as financial data, etc.
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	This memo describes a framework for specifying the		This memo describes a framework for specifying the
	Authorization, Authentication and Accounting (AAA)		Authorization, Authentication and Accounting (AAA)
	capabilities that could be activated within the context of		capabilities that could be activated within the context of
	the deployment and the operation of IP multicast-based		the deployment and the operation of IP multicast-based
	services. This memo also describes a framework to realize		services. This memo also describes a framework to realize
	high-quality multicast transport using a Multicast		high-quality multicast transport using a Multicast
	Admission Control Function (MACF) with multicast		Admission Control Function (MACF) with multicast
	Authorization.		Authorization.
	Specifically, this framework addresses the requirements		Specifically, this framework addresses the requirements
	presented in draft-ietf-mboned-maccnt-req-05.txt,		presented in "Requirements for Multicast AAA coordinated
	"Requirements for Multicast AAA coordinated between Content		between Content Provider(s) and Network Service
	Provider(s) and Network Service Provider(s)" MACCNT-REQ-		Provider(s)" which describes the requirements in CDN
	draft describes the requirements in CDN services using IP		services using IP multicast. The requirements are derived
	multicast[1]. The requirements are derived from:		from:
	- need for user tracking and billing capabilities		- need for user tracking and billing capabilities
	- need for network access control to satisfy the		- need for network access control to satisfy the
	requirements of the Network Service Provider (NSP) and/or		requirements of the Network Service Provider (NSP) and/or
	content access control to satisfy the requirements of the		content access control to satisfy the requirements of the
	Content Provider (CP)		Content Provider (CP)
	- methods for sharing information between the network		- methods for sharing information between the network
	service provider and content provider to make it possible		service provider and content provider to make it possible
	to fulfill the above two requirements.		to fulfill the above two requirements. [I-D.mboned-maccnt-
			req]
	Detailed requirements are presented in MACCNT-REQ-draft.		Detailed requirements are presented in "Requirements for
			Accounting, Authentication and Authorization in Well
			Managed IP Multicasting Services" [I-D.mboned-maccnt-req].
	These requirements include mechanisms for recording end-		These requirements include mechanisms for recording end-
	user requests and provider responses for content-delivery,		user requests and provider responses for content-delivery,
	sharing user information (possibly anonymously depending on		sharing user information (possibly anonymously depending on
	the trust model) between content provider and network		the trust model) between content provider and network
	service provider, and protecting resources through the		service provider, and protecting resources through the
	prevention of network and content access by unauthorized		prevention of network and content access by unauthorized
	users, as well as other AAA related requirements.		users, as well as other AAA related requirements.
	The purpose of this memo is to provide a generalized		The purpose of this memo is to provide a generalized
	framework for specifying multicast-inferred AAA		framework for specifying multicast-inferred AAA
	skipping to change at page 5, line 50		skipping to change at page 6, line 5
	framework is to provide a basis for future work of		framework is to provide a basis for future work of
	investigating the applicability of existing AAA protocols		investigating the applicability of existing AAA protocols
	to provide these AAA capabilities in IP multicast specific		to provide these AAA capabilities in IP multicast specific
	context and/or if deemed necessary, the refining or		context and/or if deemed necessary, the refining or
	defining of protocols to provide these capabilities.		defining of protocols to provide these capabilities.
	2. Definitions and Abbreviations		2. Definitions and Abbreviations
	2.1 Definitions		2.1 Definitions
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	For the purpose of this memo the following definitions		For the purpose of this memo the following definitions
	apply:		apply:
	Accounting: The set of capabilities that allow the		Accounting: The set of capabilities that allow the
	retrieval of a set of statistical data that can be defined		retrieval of a set of statistical data that can be defined
	on a per customer and/or a per service basis, within the		on a per customer and/or a per service basis, within the
	context of the deployment of multicast-based services. Such		context of the deployment of multicast-based services. Such
	data are retrieved for billing purposes, and can be		data are retrieved for billing purposes, and can be
	retrieved on a regular basis or upon unsolicited requests.		retrieved on a regular basis or upon unsolicited requests.
	Such data include (but are not necessarily limited to) the		Such data include (but are not necessarily limited to) the
	volume of multicast-formatted data that have been forwarded		volume of multicast-formatted data that have been forwarded
	to the receiver over a given period of time, the volume of		to the receiver over a given period of time, the volume of
	multicast-formatted data that have been exchanged between a		multicast-formatted data that have been exchanged between a
	receiver (or set of) and a given source over a given period		receiver (or set of) and a given source over a given period
	of time (e.g. the duration of a multicast session), etc.		of time (e.g. the duration of a multicast session), etc.
	Authentication: action for identifying a user as a genuine		Authentication: action for identifying a user as a genuine
	one.		one.
	Authorization: The set of capabilities that need to be		Authorization: The set of capabilities that need to be
	activated to make sure a given requesting customer is (1)		activated to make sure an authenticated user is fully
	what he claims to be (identification purposes), and (2) is		entitled to access a set of services.
	fully entitled to access a set of services (authentication
	purposes).		Join: Signaling mechanism used by receivers to indicate
			they want to access a multicast group and receive the
			corresponding traffic.
			Leave: Signaling mechanism used by receivers to indicate
			they want to leave a multicast group and not receive the
			corresponding traffic anymore.
	Receiver: an end-host or end-client which receives content.		Receiver: an end-host or end-client which receives content.
	A receiver may be identified by a network ID such as MAC		A receiver may be identified by a network ID such as MAC
	address or IP address.		address or IP address.
	User: a human with a user account. A user may possibly use		User: a human with a user account. A user may possibly use
	multiple reception devices. Multiple users may use the		multiple reception devices. Multiple users may use the
	same reception device.		same reception device. (Note: The definition of a receiver
			(device) and a user (human) should not be confused.)
	Note: The definition of a receiver (device) and a user
	(human) should not be confused.
	2.2 Abbreviations		2.2 Abbreviations
	For the purpose of this draft the following abbreviations		For the purpose of this draft the following abbreviations
	apply:		apply:
			AAA: Authentication.Authorization.and Accounting
	ACL: Access Control List		ACL: Access Control List
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	AN: Access Node		AN: Access Node
	CDN: Content Delivery Network		CDN: Content Delivery Network
	CDS: Content Delivery Services		CDS: Content Delivery Services
	CP: Content Provider		CP: Content Provider
			CP-AAA: Authentication, Authorization, and Accounting
			functions used by a Content Provider
	CPE: Customer Premise Equipment		CPE: Customer Premise Equipment
			ID: Identifier
			IF: network interface
			mAAA: Authentication, Authorization, and Accounting
			functions activated in multicast-enabled environments
	MACF: Multicast Admission Control Function		MACF: Multicast Admission Control Function
			NAS: Network Access Server (RFC2881)
	NSP: Network Service Provider		NSP: Network Service Provider
	TS: Transport System		NSP-mAAA: Authentication, Authorization, and Accounting
			functions used by a Network Service provider
			QoS: Quality of Service
	3. Common use models and network architecture implications		3. Common use models and network architecture implications
	In some cases a single entity may design and be responsible		In some cases a single entity may design and be responsible
	for a system that covers the various common high-level		for a system that covers the various common high-level
	requirements of a multicasting system such as 1) content		requirements of a multicasting system such as 1) content
	serving, 2) the infrastructure to multicast it, 3) network		serving, 2) the infrastructure to multicast it, 3) network
	and content access control mechanisms. In many cases		and content access control mechanisms.
	however the content provision and network provision roles
	are divided between separate entities. The MACCNT-REQ-
	draft provides more detail of the multiple versus single
	entity CDS network models.
	As such it should not be assumed that the entity		In many cases however the content provision and network
	responsible for the multicasting structure and the entity		provision roles are divided between separate entities.
	responsible for content serving are the same. Indeed		Commonly, Content Providers (CP) do not build and maintain
	because the infrastructure for multicasting is expensive		their own multicast network infrastructure as this is not
	and many content holders are not likely to be competent at		their primary business area. CP often purchase transport
	building and maintaining complicated infrastructures		and management services from network service providers
	necessary for multicasting, many content holders would		instead. Similarly Network Service Providers (NSP) may not
	prefer to purchase transport and management services from a		make their business in providing content. [I-D.mboned-
	network service provider and thus share the infrastructure		maccnt-req] provides more detail of the multiple versus
	costs with other content holders.
	Similarly network service providers in many cases do not		Internet Draft AAA and Admission Control Framework for
	specialize in providing content and are unlikely to build		Multicasting July, 2008
	and maintain such a resource-intensive system without a
	certain level of demand from content holders.
	The use model of a single NSP providing multicasting		single-entity Content Delivery Service (CDS) network
	services to multiple CPs the following general requirements		models.
	from MACCNT-REQ-draft apply:
			In the usage model where a single NSP provides multicast
			services to multiple CPs, the following general
			requirements from [I-D.mboned-maccnt-req] apply:
	-Need for user tracking and billing capabilities		-Need for user tracking and billing capabilities
	-Need for QoS control such as resource management and		-Need for QoS control such as resource management and
	admission control		admission control
	-Need for conditional content access control		-Need for conditional multicast access control
	satisfactory to the requirements of the CP		satisfactory to the requirements of the CP
	-Methods for sharing information between the NSP and		-Methods for sharing information between the NSP and
	CP to make the above two possible		CP to make the above two possible
	When the NSP and CP are the same single entity the general		When the NSP and CP are the same single entity then the
	requirements are as follows.		general requirements are as follows.
	-Need for user tracking and user-billing capabilities		-Need for user tracking and user-billing capabilities
	-Need for access control and/or content protection at		-Need for access control and/or content protection at
	level the entity deems appropriate		level the entity deems appropriate
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	4. Framework and Roles of Entities		4. Framework and Roles of Entities
	4.1 "AAA Framework in Multicast-Enabled Environments		4.1 AAA Framework in Multicast-Enabled Environments
	A general high-level framework can be represented as		A general high-level framework is depicted in Figure 1.
	follows.
	+------------------------------+		+------------------------------+
	| user |		| user |
	| |		| |
	+------------------------------+		+------------------------------+
	| Access ^ Response		|
	| Request |		|
	V |		|
	+------------------------------+		+------------------------------+
	| NSP |		| NSP |
	| |		| |
	+------------------------------+		+------------------------------+
	| Access ^ Response		|
	| Request | (Success)		|
	v |		|
	+------------------------------+		+------------------------------+
	| CP |		| CP |
	| |		| |
	+------------------------------+		+------------------------------+
	Figure 1
			Figure 1: High-level AAA framework in Multicast-Enabled
			Environments
	For the sake of simplicity, the above diagram portrays a		For the sake of simplicity, the above diagram portrays a
	case where there is a single NSP entity and a single CP		case where there is a single NSP entity and a single CP
	entity, but multiple CPs can be connected to a single NSP		entity (one-to-one model), but multiple CPs can be
	(e.g. NSP may provide connections to multiple CPs to		connected to a single NSP (e.g. NSP may provide connections
	provide a wide selection of content categories.) It is also		to multiple CPs to provide a wide selection of content
	possible for a single CP to be connected to multiple NSP		categories: one-to-many model) It is also possible for a
	networks (e.g. network selection). Furthermore it is		single CP to be connected to multiple NSP networks (e.g.
	possible that the NSP and CP could be the same entity. A		network selection). Furthermore it is possible that the NSP
	NSP and CP authenticate and authorize each other when they		and CP could be the same entity. A NSP and CP authenticate
	establish connectivity. Below the general case of multiple		and authorize each other when they establish connectivity.
	NSPs with multiple CPs is explained. Then, the various		Below the general case of multiple NSPs with multiple CPs
	combinations of single and multiple CPs and NSPs are		is explained. Then, the various combinations of single and
	described in relation to the general case.		multiple CPs and NSPs are described in relation to the
			general case.
	4.1.1 Multiple CPs are connected to multiple NSPs		4.1.1 Multiple CPs are connected to multiple NSPs
	The user subscribes to multiple NSPs and multiple CPs in		The user subscribes to multiple NSPs and multiple CPs in
	this usage case. The user selects a CP and a NSP when the		this usage case. The user selects a CP and a NSP when the
	user requests content. The NSP may be automatically		user requests content. The NSP may be automatically
	selected by a user terminal: e.g. a fixed line NSP by a set		selected by a user terminal: e.g. a fixed line NSP by a set
	top box or a mobile NSP by a mobile phone. In some usage		top box or a mobile NSP by a mobile phone. In some usage
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	cases it is possible that the NSP used by a certain user		cases it is possible that the NSP used by a certain user
	will not always be the same. For example a user may have		will not always be the same. For example a user may have
	contracted with more than one NSP: one for fixed line		contracted with more than one NSP: one for fixed line
	access and another for mobile roaming access.		access and another for mobile roaming access.
	The content may be associated with (or managed by) a		The content may be associated with (or managed by) a
	specific CP. In this case, when the user selects content,		specific CP. In this case, when the user selects content,
	the CP is automatically selected.		the CP is automatically selected.
	The user should send an Access-Request to the selected NSP		Requests for multicast sent by the user to a selected NSP
	with enough information not only for authentication by the		should include enough information not only for
	CP but also for CP selection and admission control by the		authentication by the CP but also for CP selection and
	NSP.		admission control by the NSP.
	When an NSP receives an Access-Request from a user, the NSP		When an NSP receives a request for multicast from a user,
	selects the appropriate CP for the received Access-Request		the NSP requests the appropriate CP to make sure that the
	and relays the content request. As the NSP is responsible		user is entitled to access the corresponding content As
	for managing its network resources, the NSP may perform		the NSP is responsible for managing its network resources,
	admission control.The NSP will allow access to the network		the NSP may perform admission control.The NSP will allow
	and contents conditional to both the CP's content		access to the multicast service, depending on both the
	authorization result and the NSPs network availability.		response sent by the CP and the availability of resources
	That is, the NSP starts multicast flow only when it has		operated by the NSP. That is, the NSP will forward
	both 1) received an "accept" response from the CP and 2)		multicast traffic towards the user only when the NSP has 1)
	determined that the network resources (e.g. bandwidth) are		made sure the user is entitled to access the network
	sufficient to serve the multicast channel. When neither of		resources operated by the NSP, 2) received a confirmation
	these conditions are met, the NSP does not start the		from the CP that the user is entitled to access the content
	requested multicast channel. When the NSP already knows		and (possibly) 3) determined that the network resources
			(e.g. bandwidth) are sufficient to deliver the multicast
			traffic to the user with the relevant level of quality.
			When neither of the first two conditions are met, the NSP
			will not forward multicast traffic to the user. Condition
			#3 may also be a showstopper. When the NSP already knows
	that network resources are insufficient or there is a		that network resources are insufficient or there is a
	network failure, the NSP may choose to not relay the		network failure, the NSP may choose to not request the CP
	Access-Request to the CP. The NSP is also responsible for		about the user's ability to retrieve content. The NSP is
	relaying the Response message from the CP to the user		also responsible for notifiying the user whether he/she is
	whether the user is eligible to receive content (in		eligible to receive content depending on the response sent
	response to the corresponding Access-Request from the user		by the CP. In cases where the NSP does not start
	to the CP.) In cases that the NSP does not start
	multicasting because of its own network issues (e.g. lack		multicasting because of its own network issues (e.g. lack
	of network resources or network failure), the NSP notifies		of network resources or network failure), the NSP notifies
	the user with a reason for rejecting the request.		the user with a reason for rejecting the request.
	A CP receives an Access-Request relayed by the NSP. The CP		A CP receives an inquiry from the NSP. The CP authenticates
	authenticates the NSP's identity and makes an authorization		the NSP's identity and makes an authorization decision
	decision regarding the NSP's eligibility to provide users		regarding the user's eligibility to access the requested
	access to its contents. The CP is responsible for		contents. The CP is responsible for the authentication
	Authentication and Authorization of users' access to		and authorization of users so that they can access the
	content that the CP manages. The CP hopes to collect		content managed by the CP. The CP notifies the NSP
	accounting information related to the access of their		accordingly. When the CP cannot (e.g. error or resource
	content. The CP responds to the NSP regarding the relayed		issues) or decides not (e.g. policy issues) to deliver
	Access-Request. When the CP cannot (e.g. error or
	resource issues) or decides not (e.g. policy issues) to		Internet Draft AAA and Admission Control Framework for
	deliver content, the CP is responsible for notifying the		Multicasting July, 2008
	NSP of the reason. It is up to the NSP how to relay or
	translate the reasons for rejection to the user.		content, the CP is responsible for notifying the NSP about
			the reason. It is up to the NSP to relay or translate the
			reasons for rejection to the user.
			A CP may delegate AAA responsibility to a NSP. 'AAA proxy
			in NSP' is described in 4.7 for this case.
			As defined in [I-D.mboned-maccnt-req], the CP may require
			the retrieval of accounting information related to the
			access of its content.
	4.1.2 Multiple CPs are connected to a single NSP		4.1.2 Multiple CPs are connected to a single NSP
	The user subscribes to a single NSP which provides		The user subscribes to a single NSP which provides
	multicasting of channels from multiple CPs in this usage		multicasting from multiple CPs in this usage case. In this
	case. In this case the user does not select an NSP. The		case the user does not select an NSP. The user selects a
	user selects a CP when the user requests content. The		CP when the user requests content. The content may be
	content may be associated with (or managed by) the specific		associated with (or managed by) the specific CP, so that
	CP, so that when the user selects content, the CP is		when the user selects content, the CP is automatically
	automatically selected.		selected.
	The user should send an Access-Request to the specific NSP
	with enough information not only for authentication by the		The user should send a request for multicast to the
	CP but also for CP selection and admission control by the		specific NSP with enough information not only for
	NSP.		authentication by the CP but also for CP selection and
			admission control by the NSP.
	The role of the NSP is the same as that described in 4.1.1.		The role of the NSP is the same as that described in 4.1.1.
	The role of a CP is the same as that described in 4.1.1.		The role of a CP is the same as that described in 4.1.1.
	4.1.3 A single CP is connected to multiple NSPs		4.1.3 A single CP is connected to multiple NSPs
	A user subscribes to multiple NSPs but a single CP in this		In this usage case, a user subscribes to multiple NSPs but
	usage case. A user selects the NSP when the user requests		only a single CP. A user selects the NSP when the user
	content but the CP is fixed. The user should send an		requests multicast but the CP is fixed. The user should
	Access-Request to the selected NSP with enough information		send a request for multicast to the selected NSP with
	not only for authentication by the CP but also for		enough information not only for authentication by the CP
	admission control by the NSP.		but also for admission control by the NSP.
	The role of the NSP is similar to the description in 4.1.1,		The role of the NSP is similar to the description in 4.1.1,
	with the exception that when a NSP receives an Access-		with the exception that when a NSP receives a request from
	Request from a user, NSP relays it to the CP without CP		a user, NSP makes an inquiry to the CP without CP selection.
	selection.
	The role of the CP is the same as that described in 4.1.1.		The role of the CP is the same as that described in 4.1.1.
	4.1.4 A single CP is connected to single NSP		4.1.4 A single CP is connected to single NSP
	In this case, a user subscribes to only one NSP and one CP.		In this case, a user subscribes to only one NSP and one CP.
	The user does not select NSP and CP in this scenario. The		The user does not select a NSP and CP in this scenario.
	user should send an Access-Request to the NSP with enough		Requests for multicast sent by the user to a selected NSP
	information not only for authentication by the CP but also
	for admission control by the NSP.		Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
			should include enough information not only for
			authentication by the CP but also for admission control by
			the NSP.
	The role for the NSP is the same as 4.1.3		The role for the NSP is the same as 4.1.3
	The role of the CP is the same as the description in 4.1.1.		The role of the CP is the same as the description in 4.1.1.
	The NSP and CP could be the same entity. In this case, the		The NSP and CP could be the same entity. In this case, the
	roles of the NSP and CP may be combined.		roles of the NSP and CP may be combined.
	4.2 User ID		4.2 User ID
	Users may hold multiple user IDs: IDs which have been		Users may hold multiple user IDs: IDs which have been
	separately assigned for each subscription they may have for		separately assigned for each subscription to various NSPs
	various NSPs and CPs. The NSPs and CPs manage the user IDs		and CPs. The NSPs and CPs manage the user IDs for their
	for their respective domains. A CP identifies a user by a		respective domains. A CP identifies a user by a user ID
	user ID assigned by the CP itself. A NSP identifies a user		assigned by the CP itself. A NSP identifies a user by a
	by a user ID assigned by the NSP itself. The user IDs are		user ID assigned by the NSP itself. The user IDs are only
	only meaningful within the context of each domain. Users		meaningful within the context of each domain. Users may
	may hold multiple user IDs which have been separately		hold multiple user IDs which have been separately assigned
	assigned for each subscription they may have for various		for each subscription they may have for various NSPs and
	NSPs and CPs.		CPs.
	4.2.1 CP-assigned user ID		4.2.1 CP-assigned user ID
	CPs assign user IDs to their users. The user may have more		CPs assign user IDs to their users. The user may have more
	than one CP-assigned user ID per specific CP. A user sends		than one CP-assigned user ID per specific CP. A user
	an Access-Request to a NSP, the CP-assigned user ID should		requests multicast to a NSP, the CP-assigned user ID should
	be indicated so that the CP can identify the user		be indicated so that the CP can identify the user
	requesting content access. A NSP should relay the CP-		requesting content access. A NSP should notify the CP-
	assigned user ID from the user to the CP. A NSP should not		assigned user ID to the CP. A NSP should not share a CP-
	send a CP-assigned user ID to any CP except the one which		assigned user ID with any CP except the one which assigned
	assigned it and should not relay it at all if there is no		it and should not relay it at all if there is no
	appropriate CP that assigned the user ID.		appropriate CP that assigned the user ID.
	4.2.2 NSP-assigned user ID		4.2.2 NSP-assigned user ID
	NSPs assign user IDs to their users. A user may have more		NSPs assign user IDs to their users. A user may have more
	than one NSP-assigned user ID per a specific NSP. A user		than one NSP-assigned user ID per a specific NSP. A user
	sends an Access-Request to a NSP, the NSP-assigned user ID		requests for multicast to a NSP, the NSP-assigned user ID
	may be indicated in the request so that the NSP can		may be indicated in the request so that the NSP can
	identify the user. The NSP should not relay the NSP-		identify the user. The NSP should not inform the NSP-
	assigned user ID to the CP for security reasons. The NSP		assigned user ID to the CP for security reasons. The NSP
	may identify the multicast-access user by other methods		may identify the multicast-access user by other methods
	than the NSP-assigned userID, e.g. by the access port.		than the NSP-assigned userID, e.g. by the access port.
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	The actual mapping rules for NSP-assigned user IDs with CP-		The actual mapping rules for NSP-assigned user IDs with CP-
	user assigned IDs in account logs is a matter for the		user assigned IDs in account logs is a matter for the
	providers and out of the scope of this framework.		providers and out of the scope of this framework.
	4.3 Accounting		4.3 Accounting
	There are some accounting issues specific to multicasting.		There are some accounting issues specific to multicasting.
	An (S,G) should be recorded as a channel identifier. The		An (S,G) should be recorded as a channel identifier. The
	last hop device, such as an IGMP or MLD router or an IGMP		last hop device, such as an IGMP or MLD router or an IGMP
	or MLD proxy, notifies the NSP's AAA function of the (S,G)		or MLD proxy, notifies the NSP's mAAA function of the (S,G)
	channel identifier. The NSP should notify the CP of the		channel identifier. The NSP should notify the CP of the
	(S,G) information in the accounting report messages.		(S,G) information in the accounting report messages.
	A NSP records an accounting start corresponding to only the		A NSP records an accounting start corresponding to only the
	first Join for a specific user-access session. A NSP should		first Join for a specific user-access session. A NSP should
	not treat a "Join" response to a Query as the accounting		not treat a "Join" response to a Query as the accounting
	start.		start.
	A NSP records an accounting stop triggered by any of the		A NSP records an accounting stop triggered by any of the
	following: 1) a user requested Leave, 2) a timeout of a		following: 1) a user requested Leave, 2) a timeout of a
	multicast state or 3) a re-authentication failure. A NSP		multicast state or 3) a re-authentication failure. A NSP
	may also record an accounting stop due to network		may also record an accounting stop due to network
	availability reasons such as failure. The NSP logs the		availability reasons such as failure. The NSP logs the
	reason for each accounting stop.		reason for each accounting stop.
	Intermittent logs between the join and leave would allow		Intermittent logs between the join and leave would allow
	for finer diagnostics and therefore could serve useful in		for finer diagnostics and therefore could serve useful in
	billing discrepancies, and provide for a better estimation		billing discrepancies, and provide for a better estimation
	of the time-span that content was multicasted, in the event		of the time-span that content was multicast, in the event
	that users disconnect without sending leave messages.		that users disconnect without sending leave messages.
	There are two levels of accounting report messaging.		There are two levels of accounting report messaging.
	Messages in Accounting level 1 include a channel identifier,		Messages in Accounting level 1 include a channel identifier,
	a user identifier, and the accounting start and stop time		a user identifier, and the accounting start and stop time
	information. Accounting level 2 includes all information of		information. Accounting level 2 includes all information of
	Level 1, plus traffic volume information.		Level 1, plus traffic volume information.
	QoS class is an optional item for each accounting level.		QoS class is an optional item for each accounting level.
	Whether to send, and at what interval to send intermittent		Whether to send, and at what interval to send intermittent
	skipping to change at page 12, line 51		skipping to change at page 14, line 5
	may also agree to include additional option information in		may also agree to include additional option information in
	accounting messages of either level.		accounting messages of either level.
	The level of account report messaging between the NSP and		The level of account report messaging between the NSP and
	CP may be either configured statically or can be		CP may be either configured statically or can be
	dynamically requested by the CP in its response to the		dynamically requested by the CP in its response to the
	Access-Request relayed by the NSP to the CP. The		Access-Request relayed by the NSP to the CP. The
	determination of the actual level of report messaging is		determination of the actual level of report messaging is
	configured by the NSP at the NAS.		configured by the NSP at the NAS.
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	In case of very fast channel changes, the amount of items		In case of very fast channel changes, the amount of items
	logged by the NSP could become high. In order to reduce		logged by the NSP could become high. In order to reduce
	the number of report messages sent to the CP, the NSP can		the number of report messages sent to the CP, the NSP can
	consolidate multiple sets of accounting information inside		consolidate multiple sets of accounting information inside
	a single accounting report message. [4]		a single accounting report message. [I-D.ancp-framework]
	4.4 Access Control and CP selection by NSP		4.4 Access Control and CP selection by NSP
	When a NSP receives an access request from a user, the NSP		When a NSP receives an access request from a user, the NSP
	determines to which CP the request is to be directed. The		determines to which CP the request is to be directed. The
	NSP may select a CP based on CP-assigned userID with CP		NSP may select a CP based on CP-assigned userID with CP
	domain name or channel identifier (S,G). The user should		domain name or channel identifier (S,G). The user should
	include in the request sufficient information for CP		include in the request sufficient information for CP
	selection.		selection.
	4.5 Admission Control Information by NSP		4.5 Admission Control Information by NSP
	After authorizing a user request, the NSP may have further		After authorizing a user request, the NSP may have further
	conditions for determining its admission control decision.		conditions for determining its admission control decision.
	The NSP receives traffic parameters (such as QoS class,		The NSP receives parameters (such as QoS class, required
	required bandwidth, burst-size, etc.) of a multicast		bandwidth, burst-size, etc.) of multicast traffic. Such
	channel. Such parameters serve as information to be		parameters serve as information to be considered in the
	considered in the admission control decision. The traffic		admission control decision. The traffic parameters can be
	parameters can be communicated as follows:		communicated as follows:
	- A CP may notify a mapping between the channel		- A CP may notify a mapping between the channel
	identifier (S,G) and traffic parameters in the Response		identifier (S,G) and traffic parameters in the Response
	message when the CP authorizes an access request. Such		message when the CP authorizes an access request. Such
	parameters may include required bandwidth, burst-size, QoS		parameters may include required bandwidth, burst-size, QoS
	class downgrade policy, etc.		class downgrade policy, etc.
	- A user may indicate in the Request willingness to		- A user may indicate in the Request willingness to
	accept QoS class downgrade to best-effort streaming.		accept QoS class downgrade to best-effort streaming.
	- The NSP may maintain a mapping between channel		- The NSP may maintain a mapping between channel
	identifier (S,G) and traffic parameters in advance, for		identifier (S,G) and traffic parameters in advance, for
	example pre-configured by agreement between the CP and NSP		example pre-configured by agreement between the CP and NSP
	on a per channel basis.		on a per channel (S,G) basis.
	The ultimate admission decision is made by the NSP based on		The ultimate admission decision is made by the NSP based on
	required traffic parameters of the requested, and available		required traffic parameters of the requested, and available
	resources. In a case that it cannot guarantee the required		resources. In a case that it cannot guarantee the required
	network resources for the requested channel, streaming the		network resources for the requested multicast traffic,
	requested channel as best-effort traffic is optional.		streaming the requested multicast traffic as best-effort is
	The user may indicate in his/her Access Request whether		optional. The user may indicate in his/her Access
	he/she will accept best-effort grade streaming if		Request whether he/she will accept best-effort grade
	guaranteed class is not available. The CP's preference for		streaming if guaranteed class is not available. The CP's
	accepting downgrading to best-effort streaming may be		preference for accepting downgrading to best-effort
	either configured statically or can be dynamically		streaming may be either configured statically or can be
	requested by the CP in its response to the Access-Request		dynamically requested by the CP in its response to the
	relayed by the NSP to the CP. In the case that it cannot
	offered a guaranteed QoS stream, the NSP may decide to		Internet Draft AAA and Admission Control Framework for
	either to decline admission or to stream the requested		Multicasting July, 2008
	channel as best-effort traffic. The NSP should not stream
	best-effort traffic if either the user or CP has indicated		Access-Request relayed by the NSP to the CP. In the case
	against best-effort provision.		that it cannot be offered a guaranteed QoS stream, the NSP
			may decide either to decline admission or to stream the
			requested multicast traffic as best-effort. The NSP should
			not stream best-effort traffic if either the user or CP has
			indicated against best-effort provision.
	A NSP's admission control may manage integrated network		A NSP's admission control may manage integrated network
	resources for unicast usage, such as VoIP or unicast		resources for unicast usage, such as VoIP or unicast
	streaming, and multicast usage. Alternatively, it may		streaming, and multicast usage. Alternatively, it may
	manage network resources separately for unicast and		manage network resources separately for unicast and
	multicast usage. In either ease, AAA and admission control		multicast usage. In either ease, AAA and admission control
	framework for multicast usage is independent of unicast		framework for multicast usage is independent of unicast
	admission control.		admission control.
	Such QoS measurement and policy mechanisms themselves		Such QoS measurement and policy mechanisms themselves
	skipping to change at page 14, line 38		skipping to change at page 15, line 45
	A NSP may act as AAA proxy of a CP based upon an agreement		A NSP may act as AAA proxy of a CP based upon an agreement
	between the NSP and the CP. The AAA proxy would store		between the NSP and the CP. The AAA proxy would store
	information about permissions of a specific user to receive		information about permissions of a specific user to receive
	multicast data from specified channel(s) up to specified		multicast data from specified channel(s) up to specified
	expiration date(s) and time(s).		expiration date(s) and time(s).
	If such proxying is implemented, the NSP may receive		If such proxying is implemented, the NSP may receive
	authorization conditions from a CP in advance and		authorization conditions from a CP in advance and
	statically hold them, or a CP may send them dynamically in		statically hold them, or a CP may send them dynamically in
	the Response message. In either case, the user has		the Response message. In either case, the user has
	permission to receive multicast channel and therefore the		permission to receive multicast traffic and therefore the
	NSP starts the multicasting without querying the CP.		NSP starts the multicasting without querying the CP.
	The CP may send unsolicited requests to the NSP to refresh		The CP may send unsolicited requests to the NSP to refresh
	or change the permissions for a user for specific		or change the permissions for a user for specific group(s)
	channel(s).		or channel(s).
	When a user is receiving multicast content and the		When a user is receiving multicast traffic while the
	permission is about to expire, the NSP may send a		permission is about to expire, the NSP may send a
	notification to the user client that his session is about		notification to the user client that his session is about
	to expire, and that he will need to reauthenticate. In such		to expire, and that he will need to re-authenticate. In
	a case, the user will have to send the Access-Request. In		such a case, the user will have to send the Access-Request.
	the case that the user still has permission to the content,		In the case that the user still has permission to the
	they should be able to continue to receive the content
	without interruption.		Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
			content, they should be able to continue to receive the
			multicast traffic without interruption.
	When re-authentication fails, the NSP should stop the		When re-authentication fails, the NSP should stop the
	multicast channel and record accounting stop.		multicast traffic and record accounting stop.
	5. Network Connection Model and Functional Components		5. Network Connection Model and Functional Components
	Section 3.1 introduces the high-level AAA framework for		Section 3.1 introduced the high-level AAA framework for
	multicasting. This section provides more detail on the		multicasting. This section provides more detail on the
	network connection model and constituent functional		network connection model and constituent functional
	components.		components.
	5.1 Basic Connection Model		5.1 Basic Connection Model
			+------------------------------+
			| receiver |
			| |
			+------------------------------+
			| ^ Response
			| Request |
			V |
			+------------------------------+
			| NSP's network |
			| |
			+------------------------------+
			| ^ Response
			| Request | (Success)
			v |
			+------------------------------+
			| CP's network |
			| |
			+------------------------------+
			Figure 2: Basic Connection Model
	In the simple case represented in Figure 1 the NSP is the		In the simple case represented in Figure 1 the NSP is the
	sole entity providing network resources including network		sole entity providing network resources including network
	access to the User. First a user that requests content		access to the multicast receiver. First a receiver sends a
	sends an Access request to an NSP which then forwards it on		request for multicast (e.g. an IGMP Report message) to an
	to the appropriate CP for Authentication and Authorization		NSP which may then forward a mAAA request towards the
	purposes. The CP responds with either "success" or		appropriate CP for authentication and authorization
	"failure". If "success", the NSP may forward a success		purposes. The receiver gets information about a given
	response and stream multicast data to the user.		multicast group (*,G) or channel (S,G) corresponding to the
			content beforehand for generating the request. The CP
			responds with either "success" or "failure". If "success",
			the NSP grants access to the receiver and forwards
			multicast traffic accordingly.
	In this model the user selects the NSP to which to send its		Internet Draft AAA and Admission Control Framework for
	content request. Based on this request the NSP selects an		Multicasting July, 2008
	appropriate CP to which it forwards the request. The CP
	responds to the NSP's request: it may not respond to
	another NSP in regards to the request.
	In this model, as described in section 3.1, the		In this model the receiver selects the NSP to which the
	relationship between NSP and CP can be 1:1, 1:N or M:N.		Join request will be sent. Based on this request the NSP
	Users may connect to multiple networks, and networks have		selects an appropriate CP to which it forwards the
	multiple users.		corresponding mAAA request. The CP responds to the NSP's m
			AAA request: it may not respond to another NSP in regards
			to the request.
			In this model, as described in section 4.1, the
			relationship between NSP and CP can be one-to-one, one-to-
			many or many-to-many. Receivers may connect to multiple
			networks.
	5.2 Constituent Logical Functional Components of the fully		5.2 Constituent Logical Functional Components of the fully
	enabled AAA Framework		enabled AAA Framework
	Requirements for "fully AAA and QoS enabled" IP		Requirements for "fully AAA and QoS enabled" IP
	multicasting networks were defined in MACCNT-REQ-draft. To		multicasting networks were defined in MACCNT-REQ-draft. To
	allow for levels of enablement, this memo defines two		allow for levels of enablement, this memo defines two
	models within the framework: "AAA enabled" multicasting and		models within the framework: "AAA enabled" multicasting and
	"Fully enabled AAA" multicasting which means "AAA enabled"		"Fully enabled AAA" multicasting which means "AAA enabled"
	with added admission control functions.		with added admission control functions.
	Section 3.1 introduces the high-level AAA framework for		Section 3.1 introduces the high-level AAA framework for
	multicasting. Below is a diagram of a AAA enabled		multicasting. Below is a diagram of a AAA enabled
	multicasting network with AAA, including the logical		multicasting network with AAA, including the logical
	components within the various entities.		components within the various entities.
	AAA enabled framework (basic model)		Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	|| CPE ||		|| CPE ||
	|| ||		|| ||
	|+- - - - - | - - - - - - - - -+|		|+- - - - - | - - - - - - - - -+|
	+-----------|-------------------+		+-----------|-------------------+
	|		|
	-------|------ IFa		-------|------ IFa
	|		|
	skipping to change at page 16, line 39		skipping to change at page 18, line 41
	||+- - - - - - - + | |		||+- - - - - - - + | |
	+-----------------------|--------+		+-----------------------|--------+
	|		|
	-------|------ IFc		-------|------ IFc
	|		|
	+-----------------------|-------+		+-----------------------|-------+
	| CP +---------+ |		| CP +---------+ |
	| | CP-AAA | |		| | CP-AAA | |
	| +---------+ |		| +---------+ |
	+-------------------------------+		+-------------------------------+
	Figure 2		Figure 3: AAA enabled framework (basic model)
	The user entity includes the CPE (Customer Premise		The user entity includes the CPE (Customer Premise
	Equipment) which includes the user host(s) and optionally a		Equipment) which connects the receiver (s).
	multicast proxy (not shown in the Figure 2.)
	The NSP (Network Service Provider) in the basic model		The NSP (Network Service Provider) in the basic model
	includes the transport system and a logical element for		includes the transport system and a logical element for
	multicast AAA functionality. The transport system is		multicast AAA functionality. The TS (transport system) is
	comprised of the access node and NAS (network access		comprised of the access node and NAS (Network Access
	server.) An AN may be connected directory to mAAA or a NAS		Server) An AN (Access Node) may be connected directly to
	relays AAA information between an AN and a mAAA		mAAA or a NAS relays AAA information between an AN and a
	Descriptions of AN and its interfaces are out of scope for		mAAA. Descriptions of AN and its interfaces are out of the
	this memo. The multicast AAA function may be provided by a		scope for this memo. The multicast AAA function may be
	multicast AAA server (mAAA) which may include the function		provided by a mAAA which may include the function that
	by which the access policy is downloaded to the NAS
	(conditional access policy control function.) The interface		Internet Draft AAA and Admission Control Framework for
	between mAAA and the NAS is labeled IFb in Figure 2. Over		Multicasting July, 2008
	IFb the NAS makes an access request to the NSP-mAAA and the
	mAAA replies. The mAAA may push conditional access policy
	to the NAS.
			downloads Join access control lists to the NAS (this
			function is referred to conditional access policy control
			function.)
			Interface between mAAA and NAS
			The interface between mAAA and the NAS is labeled IFb in
			Figure 2. Over IFb the NAS sends an access request to the
			NSP-mAAA and the mAAA replies. The mAAA may push
			conditional access policy to the NAS.
			CP-AAA
	The content provider may have its own AAA server which has		The content provider may have its own AAA server which has
	the authority over access policy for its contents.		the authority over access policy for its contents.
			Interface between user and NSP
	The interface between the user and the NSP is labeled IFa		The interface between the user and the NSP is labeled IFa
	in Figure 2. Over IFa the user makes a multicasting		in Figure 3. Over IFa the user makes a multicasting
	request to the NSP. The NSP may in reply send multicast		request to the NSP. The NSP may in return forward
	traffic depending on the NSP and CP's policy decisions.		multicast traffic depending on the NSP and CP's policy
			decisions.
			Interface between NSP and CP
	The interface between the NSP and CP is labeled IFc. Over		The interface between the NSP and CP is labeled IFc. Over
	IFc the NSP requests to the CP-AAA for access to contents		IFc the NSP requests to the CP-AAA for access to contents
	and the CP replies. CP may also send conditional access		and the CP replies. CP may also send conditional access
	policy over this interface for AAA-proxying.		policy over this interface for AAA-proxying.
	Fully enabled framework		Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	|| CPE ||		|| CPE ||
	|| ||		|| ||
	|+- - - - - | - - - - - - - - -+|		|+- - - - - | - - - - - - - - -+|
	+-----------|-------------------+		+-----------|-------------------+
	|		|
	-------|------ IFa		-------|------ IFa
	|		|
	+-----------|-----------------------+		+-----------|-----------------------+
	|+- - - - - |- - _+ + - - - - - + |		|+- - - - - |- - _+ + - - - - - + |
	||TS | | | | | |		|| | | | | | |
	| +------|-+ | +--------+ |		| +------|-+ | +--------+ |
	|| | AN | | | | | MACF || |		|| | AN | | | | | MACF || |
	| | | | | | |		| | | | | | |
	|| +------|-+ | | | +---|----+| |		|| +------|-+ | | | +---|----+| |
	| | | | | |		| | | | | |
	| | | | IFd----- | |		| | | | IFd----- | |
	| | | IFb | | |		| | | IFb | | |
	|| +------|---+ | | | +---|----+| |		|| +------|---+ | | | +---|----+| |
	| | |---|---| mAAA | |		| | |---|---| mAAA | |
	|| | NAS | | | | |(MACF *)|| | * optional		|| | NAS | | | | |(MACF *)|| | * optional
	skipping to change at page 18, line 40		skipping to change at page 20, line 42
	||+- - - - - - - -+ - - |- - - - -+ |		||+- - - - - - - -+ - - |- - - - -+ |
	+-----------------------|-----------+		+-----------------------|-----------+
	|		|
	-------|------ IFc		-------|------ IFc
	|		|
	+-----------------------|-------+		+-----------------------|-------+
	| CP +---------+ |		| CP +---------+ |
	| | CP-AAA | |		| | CP-AAA | |
	| +---------+ |		| +---------+ |
	+-------------------------------+		+-------------------------------+
	Figure 3
			Figure 4: Fully enabled framework
	In the fully enabled model the NSP also includes a		In the fully enabled model the NSP also includes a
	component that provides network resource management (e.g.		component that provides network resource management (e.g.
	QoS management), as described in section 3.4, "Network		QoS management), as described in section 3.4, "Network
	Resource Management by NSP". In the fully enabled model		Resource Management by NSP". In the fully enabled model
	(Figure 3) resource management and admission control is		(Figure 3) resource management and admission control is
	provided by MACF (multicast admission control function.)		provided by MACF (Multicast Admission Control Function).
	This means that Before replying to the user's multicast		This means that, before replying to the user's multicast
	request the mAAA queries the MACF for a network resource		request, the mAAA queries the MACF for a network resource
	access decision over the interface IFd. The MACF is		access decision over the interface IFd. The MACF is
	responsible for allocating network resources for multicast		responsible for allocating network resources for forwarding
	traffic. So that MACF has the necessary network resource		multicast traffic. MACF also receives Leave information
	availability information, NAS notifies MACF via mAAA of the		from NAS so that MACF releases corresponding reserved
	stopping of multicast traffic.		resources.
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	5.3 Modularity of the framework		5.3 Modularity of the framework
	In the interest of flexibility, this framework is modular		In the interest of flexibility, this framework is modular
	so that it is possible that partially enabled versions of		so that it is possible that partially enabled versions of
	the models are supported. A AAA-enabled version provides		the models are supported. A AAA-enabled version provides
	AAA functionality without Network Resource management. A		AAA functionality without Network Resource management. A
	Network-Resource-Management-enabled (QoS-enabled) version		Network-Resource-Management-enabled (QoS-enabled) version
	provides Network Resource management without AAA		provides Network Resource management without AAA
	functionality. Similarly, the possibility of one or more		functionality. Similarly, the possibility of one or more
	layers of transit provision between an NSP and CP is in the		layers of transit provision between an NSP and CP is in the
	interest of modularity and extendibility.		interest of modularity and extendibility.
	6. IANA considerations		6. IANA considerations
	This memo does not raise any IANA consideration issues.		This memo does not raise any IANA consideration issues.
	7. Security considerations		7. Security considerations
	Refer to section 3.3. Also the user information related to		The user information related to authentication with the CP
	authentication with the CP must be protected in some way.		and the information related to user accounting shared
			between the NSP and the CP must be protected in some way.
	Otherwise, this memo does not raise any new security issues		Otherwise, this memo does not raise any new security issues
	which are not already addressed by the original protocols.		which are not already addressed by the original protocols.
	Enhancement of multicast access control capabilities should		Enhancement of multicast access control capabilities should
	enhance security performance.		enhance security performance.
	8. Conclusion		8. Conclusion
	This memo provides a generalized framework for solution		This memo provides a generalized framework for solution
	standards to meet the requirements. Further work should be		standards to meet the requirements. Further work should be
	done to specify the interfaces between the user and NSP,		done to specify the interfaces between the user and NSP,
	NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA		NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA
	(presented in 5.2.)		(presented in 5.2.)
	Normative References		Normative References
	[1] Hayashi, et. al., "Requirements for Multicast AAA		[I-D.mboned-maccnt-req]
			Hayashi, et. al., "Requirements for Multicast AAA
	coordinated between Content Provider(s) and Network		coordinated between Content Provider(s) and Network
	Service Provider(s)", draft-ietf-mboned-maccnt-req-		Service Provider(s)", draft-ietf-mboned-maccnt-req-
	05.txt, September 2007, Work in Progress.		06.txt, June 2008, Work in Progress.
	[2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener		[I-D.ancp-framework]
	Discovery Version 2 (MLDv2) for IPv6", June 2004.		Ooghe, et. al, "Framework and Requirements for an
			Access Node Control Mechanism in Broadband Multi-
	[3] RFC-3376, Cain B., et.al., "Internet Group Management		Internet Draft AAA and Admission Control Framework for
	Protocol, Version 3", October 2002.		Multicasting July, 2008
	[4] Ooghe, et. al, "Framework and Requirements for an		Service Networks", draft-ietf-ancp-framework-04.txt,
	Access Node Control Mechanism in Broadband Multi-		November 2007, Work in Progress.
	Service Networks", draft-ietf-ancp-framework-05.txt,
	February 2008, Work in Progress.
	Authors' Addresses		Authors' Addresses
	Hiroaki Satou		Hiroaki Satou
	NTT Network Service Systems Laboratories		NTT Network Service Systems Laboratories
	3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585		3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
	Japan		Japan
	Phone : +81 422 59 4683		Phone : +81 422 59 4683
	Email : satou.hiroaki@lab.ntt.co.jp		Email : satou.hiroaki@lab.ntt.co.jp
	skipping to change at page 20, line 33		skipping to change at page 22, line 31
	NTT Network Service Systems Laboratories		NTT Network Service Systems Laboratories
	3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585		3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
	Japan		Japan
	Phone : +81 422 59 3617		Phone : +81 422 59 3617
	Email: ohta.hiroshi@lab.ntt.co.jp		Email: ohta.hiroshi@lab.ntt.co.jp
	Christian Jacquenet		Christian Jacquenet
	France Telecom		France Telecom
	3, avenue Francois Chateau		3, avenue Francois Chateau
	CS 36901, 35069 Rennes Cedex, France		CS 36901, 35069 Rennes Cedex, France
	Phone: +33 2 99 87 63 31		Phone: +33 2 99 87 61 92
	Email: christian.jacquenet@francetelecom.com		Email: christian.jacquenet@orange-ftgroup.com
	Tsunemasa Hayashi		Tsunemasa Hayashi
	NTT Network Innovation Laboratories		NTT Network Innovation Laboratories
	1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847		1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847
	Japan		Japan
	Phone: +81 46 859 8790		Phone: +81 46 859 8790
	Email: tsunemasa@gmail.com		Email: tsunemasa@gmail.com
	Haixiang He		Haixiang He
	Nortel		Nortel
	600 Technology Park Drive		600 Technology Park Drive
	Billerica, MA 01801, USA		Billerica, MA 01801, USA
	Phone: +1 978 288 7482		Phone: +1 978 288 7482
	Email: haixiang@nortel.com		Email: haixiang@nortel.com
	Comments		Comments
	Comments are solicited and should be addressed to the		Comments are solicited and should be addressed to the
	mboned working group's mailing list at		mboned working group's mailing list at
	mboned@lists.uoregon.edu_and/or the authors.		mboned@lists.uoregon.edu_and/or the authors.
			Internet Draft AAA and Admission Control Framework for
			Multicasting July, 2008
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and		This document is subject to the rights, licenses and
	restrictions contained in BCP 78, and except as set forth		restrictions contained in BCP 78, and except as set forth
	therein, the authors retain all their rights.		therein, the authors retain all their rights.
	This document and the information contained herein are		This document and the information contained herein are
	provided on an "AS IS" basis and THE CONTRIBUTOR, THE		provided on an "AS IS" basis and THE CONTRIBUTOR, THE
	skipping to change at page 22, line 51		skipping to change at page 23, line 54
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its		The IETF invites any interested party to bring to its
	attention any copyrights, patents or patent applications,		attention any copyrights, patents or patent applications,
	or other proprietary rights that may cover technology that		or other proprietary rights that may cover technology that
	may be required to implement this standard. Please		may be required to implement this standard. Please
	address the information to the IETF at ietf-ipr@ietf.org.		address the information to the IETF at ietf-ipr@ietf.org.
	Expiration		Expiration
	This Internet-Draft will expire on August 22, 2008.		This Internet-Draft will expire on January 3, 2009.
	Acknowledgement		Acknowledgement
	Funding for the RFC Editor function is currently provided		Funding for the RFC Editor function is currently provided
	by the Internet Society.		by the Internet Society.
End of changes. 97 change blocks.
	303 lines changed or deleted		433 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/