draft-ietf-mboned-multiaaa-framework-05.txt		draft-ietf-mboned-multiaaa-framework-06.txt
			Internet Draft Hiroaki Satou, NTT
	Internet Draft AAA Framework for Multicasting November		Intended Status: Hiroshi Ohta, NTT
	2007		Informational
			Expires: August Christian Jacquenet, France Telecom
	Hiroaki Satou, NTT		22, 2008
	Internet Draft Hiroshi Ohta, NTT
	Expires: May 17, Christian Jacquenet, France Telecom
	2008
	Tsunemasa Hayashi, NTT		Tsunemasa Hayashi, NTT
	Haixiang He, Nortel Networks		Haixiang He, Nortel Networks
	November 19, 2007		February 25, 2007
	AAA Framework for Multicasting		AAA Framework for Multicasting
	<draft-ietf-mboned-multiaaa-framework-05.txt>		<draft-ietf-mboned-multiaaa-framework-06.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author		By submitting this Internet-Draft, each author
	represents that any applicable patent or other IPR		represents that any applicable patent or other IPR
	claims of which he or she is aware have been or will		claims of which he or she is aware have been or will
	be disclosed, and any of which he or she becomes		be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section		aware will be disclosed, in 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 Engineering Task Force (IETF), its areas,		Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may		and its working groups. Note that other groups may
	also distribute working documents as Internet-Drafts.		also distribute working documents as Internet-
			Drafts.
	Internet-Drafts are draft documents valid for a		Internet-Drafts are draft documents valid for a
	maximum of six months and may be updated, replaced,		maximum of six months and may be updated, replaced,
	or obsoleted by other documents at any time. It is		or obsoleted by other documents at any time. It is
	inappropriate to use Internet-Drafts as reference		inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in		material or to cite them other 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 http://www.ietf.org/ietf/1id-abstracts.txt.		at http://www.ietf.org/ietf/1id-abstracts.txt.
	Internet Draft AAA Framework for Multicasting November
	2007
	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 May 17, 2008.		This Internet-Draft will expire on August 22, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007). This document		Copyright (C) The IETF Trust (2008). This document
	is subject to the rights, licenses and restrictions		is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein,		contained in BCP 78, and except as set forth
	the authors retain all their rights.		therein, the authors retain all their rights.
	Abstract		Abstract
	IP multicast-based services, such as TV broadcasting		IP multicast-based services, such as TV broadcasting
	or videoconferencing raise the issue of making sure		or videoconferencing raise the issue of making sure
	that potential customers are fully entitled to		that potential customers are fully entitled to
	access the corresponding contents. There is indeed a		access the corresponding contents. There is indeed a
	need for service and content providers to identify		need for service and content providers to identify
	(if not authenticate, especially within the context		(if not authenticate, especially within the context
	of enforcing electronic payment schemes) and to		of enforcing electronic payment schemes) and to
	invoice such customers in a reliable and efficient		invoice such customers in a reliable and efficient
	manner. This memo describes the framework for		manner. This memo describes the framework for
	specifying the Authorization, Authentication and		specifying the Authorization, Authentication and
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	activated within the context of the deployment and		activated within the context of the deployment and
	the operation of IP multicast-based services. This		the operation of IP multicast-based services. This
	framework addresses the requirements presented in		framework addresses the requirements presented in
	draft-ietf-mboned-maccnt-req-04.txt, "Requirements		draft-ietf-mboned-maccnt-req-04.txt, "Requirements
	for Accounting, Authentication and Authorization in		for Accounting, Authentication and Authorization in
	Well Managed IP Multicasting Services". The memo		Well Managed IP Multicasting Services". The memo
	provides a basic AAA enabled model as well as an		provides a basic AAA enabled model as well as an
	extended fully enabled model with resource and		extended fully enabled model with resource and
	admission control coordination.		admission control coordination.
	STATUS OF THIS MEMO 1		Table of Contents
	COPYRIGHT NOTICE 2		1. INTRODUCTION 4
	ABSTRACT 2		1.1 PURPOSE AND BACKGROUND 4
	1. INTRODUCTION 5		2. DEFINITIONS AND ABBREVIATIONS 5
	1.1 PURPOSE AND BACKGROUND 5		2.1 DEFINITIONS 5
	2. DEFINITIONS AND ABBREVIATIONS 6		2.2 ABBREVIATIONS 6
	2.1 DEFINITIONS 6
	2.2 ABBREVIATIONS 7
	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 8
	4.1 FRAMEWORK FOR MULTICAST AAA 8		4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 8
	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 10
	4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11		4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 10
	4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11		4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 10
	4.2 USER ID 11		4.2 USER ID 11
	4.2.1 CP-ASSIGNED USER ID 12		4.2.1 CP-ASSIGNED USER ID 11
	4.2.2 NSP-ASSIGNED USER ID 12		4.2.2 NSP-ASSIGNED USER ID 11
	4.3 ACCOUNTING 12		4.3 ACCOUNTING 12
	4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13		4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13
	4.5 ADMISSION CONTROL INFORMATION BY NSP 13		4.5 ADMISSION CONTROL INFORMATION BY NSP 13
	4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14		4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14
	4.7 AAA PROXY IN NSP 14		4.7 AAA PROXY IN NSP 14
	5.1 BASIC CONNECTION MODEL 14		5.1 BASIC CONNECTION MODEL 15
	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 15
	5.3 MODULARITY OF THE FRAMEWORK 19		5.3 MODULARITY OF THE FRAMEWORK 19
	6. IANA CONSIDERATIONS 19		6. IANA CONSIDERATIONS 19
	7. SECURITY CONSIDERATIONS 19		7. SECURITY CONSIDERATIONS 19
	8. CONCLUSION 19		8. CONCLUSION 19
	NORMATIVE REFERENCES 19
	AUTHORS' ADDRESSES 20
	COMMENTS 20
	FULL COPYRIGHT STATEMENT 21
	COPYRIGHT (C) THE IETF TRUST (2007). 21
	INTELLECTUAL PROPERTY 21
	EXPIRATION 21
	ACKNOWLEDGEMENT 22
	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 1-to-n (case of
	TV broadcasting services for example) or n-to-p (case of		TV broadcasting services for example) or n-to-p (case of
	videoconferencing services, for example).		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		videoconferencing raise the issue of making sure that
	or videoconferencing raise the issue of making sure that
	potential customers are fully entitled to access the		potential customers are fully entitled to access the
	corresponding contents.		corresponding contents. There is indeed a need for service
	There is indeed a need for service and content providers to		and content providers to identify (if not authenticate,
	identify (if not authenticate, especially within the		especially within the context of enforcing electronic
	context of enforcing electronic payment schemes) and to		payment schemes) and to invoice such customers in a
	invoice such customers in a reliable and efficient manner.		reliable and efficient manner. Solutions should consider a
	Solutions should consider a wide range of possible content		wide range of possible content delivery applications:
	delivery applications: content delivered over the multicast		content delivered over the multicast network may include
	network may include video, audio, images, games, software		video, audio, images, games, software and information such
	and information such as financial data, etc.		as financial data, etc.
	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 Resource and		high-quality multicast transport using a Multicast
	Admission Control System (RACS) 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 draft-ietf-mboned-maccnt-req-05.txt,
	"Requirements for Multicast AAA coordinated between Content		"Requirements for Multicast AAA coordinated between Content
	Provider(s) and Network Service Provider(s)" MACCNT-REQ-		Provider(s) and Network Service Provider(s)" MACCNT-REQ-
	draft describes the requirements in CDN services using IP		draft describes the requirements in CDN services using IP
	multicast[1]. The requirements are derived from:		multicast[1]. The requirements are derived 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
	skipping to change at page 6, line 18		skipping to change at page 5, line 38
	Detailed requirements are presented in MACCNT-REQ-draft.		Detailed requirements are presented in MACCNT-REQ-draft.
	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		framework for specifying multicast-inferred AAA
	specifying multicast-inferred AAA capabilities that can		capabilities that can meet these requirements. This
	meet these requirements. This framework is to provide a		framework is to provide a basis for future work of
	basis for future work of investigating the applicability of		investigating the applicability of existing AAA protocols
	existing AAA protocols to provide these AAA capabilities in		to provide these AAA capabilities in IP multicast specific
	IP multicast specific context and/or if deemed necessary,		context and/or if deemed necessary, the refining or
	the refining or defining of protocols to provide these		defining of protocols to provide these capabilities.
	capabilities.
	2. Definitions and Abbreviations		2. Definitions and Abbreviations
	2.1 Definitions		2.1 Definitions
	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
	skipping to change at page 7, line 28		skipping to change at page 6, line 47
	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:
	ACL: Access Control List		ACL: Access Control List
	AN: Access Node		AN: Access Node
	CAPCF: Conditional Access Policy Control Function
	CDN: Content Delivery Network		CDN: Content Delivery Network
	CDS: Content Delivery Services		CDS: Content Delivery Services
	CP: Content Provider		CP: Content Provider
	CPE: Customer Premise Equipment		CPE: Customer Premise Equipment
	MACF: Multicast Admission Control Function		MACF: Multicast Admission Control Function
	NSP: Network Service Provider		NSP: Network Service Provider
	TS: Transport System		TS: Transport System
	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
	skipping to change at page 8, line 42		skipping to change at page 8, line 9
	-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 the general
	requirements are as follows.		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
	4. Framework and Roles of Entities4.1 Framework for multicast		4. Framework and Roles of Entities
	AAA
			4.1 "AAA Framework in Multicast-Enabled Environments
	A general high-level framework can be represented as		A general high-level framework can be represented as
	follows.		follows.
	+------------------------------+		+------------------------------+
	| user |		| user |
	| |		| |
	+------------------------------+		+------------------------------+
	| Access ^ Response		| Access ^ Response
	| Request |		| Request |
	skipping to change at page 10, line 15		skipping to change at page 9, line 34
	NSP.		NSP.
	When an NSP receives an Access-Request from a user, the NSP		When an NSP receives an Access-Request from a user, the NSP
	selects the appropriate CP for the received Access-Request		selects the appropriate CP for the received Access-Request
	and relays the content request. As the NSP is responsible		and relays the content request. As the NSP is responsible
	for managing its network resources, the NSP may perform		for managing its network resources, the NSP may perform
	admission control.The NSP will allow access to the network		admission control.The NSP will allow access to the network
	and contents conditional to both the CP's content		and contents conditional to both the CP's content
	authorization result and the NSPs network availability.		authorization result and the NSPs network availability.
	That is, the NSP starts multicast flow only when it has		That is, the NSP starts multicast flow only when it has
	both 1) received an ‘‘accept’’ response from the CP and 2)		both 1) received an "accept" response from the CP and 2)
	determined that the network resources (e.g. bandwidth) are		determined that the network resources (e.g. bandwidth) are
	sufficient to serve the multicast channel. When neither of		sufficient to serve the multicast channel. When neither of
	these conditions are met, the NSP does not start the		these conditions are met, the NSP does not start the
	requested multicast channel. When the NSP already knows		requested multicast channel. 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 relay the
	Access-Request to the CP. The NSP is also responsible for		Access-Request to the CP. The NSP is also responsible for
	relaying the Response message from the CP to the user		relaying the Response message from the CP to the user
	whether the user is eligible to receive content (in		whether the user is eligible to receive content (in
	response to the corresponding Access-Request from the user		response to the corresponding Access-Request from the user
	to the CP.) In cases that the NSP does not start multicast		to the CP.) In cases that the NSP does not start
	because of its own network issues (e.g. lack of network		multicasting because of its own network issues (e.g. lack
	resources or network failure), the NSP notifies the user		of network resources or network failure), the NSP notifies
	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 Access-Request relayed by the NSP. The CP
	authenticates the NSP’s identity and makes an authorization		authenticates the NSP's identity and makes an authorization
	decision regarding the NSP’s eligibility to provide users		decision regarding the NSP's eligibility to provide users
	access to its contents. The CP is responsible for		access to its contents. The CP is responsible for
	Authentication and Authorization of users' access to		Authentication and Authorization of users' access to
	content that the CP manages. The CP hopes to collect		content that the CP manages. The CP hopes to collect
	accounting information related to the access of their		accounting information related to the access of their
	content. The CP responds to the NSP regarding the relayed		content. The CP responds to the NSP regarding the relayed
	Access-Request. When the CP cannot (e.g. error or		Access-Request. When the CP cannot (e.g. error or
	resource issues) or decides not (e.g. policy issues) to		resource issues) or decides not (e.g. policy issues) to
	deliver content, the CP is responsible for notifying the		deliver content, the CP is responsible for notifying the
	NSP of the reason. It is up to the NSP how to relay or		NSP of the reason. It is up to the NSP how to relay or
	translate the reasons for rejection to the user.		translate the reasons for rejection to the user.
	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 of channels from multiple CPs in this usage
	case. In this case the user does not select an NSP. The		case. In this case the user does not select an NSP. The
	user selects a CP when the user requests content. The		user selects a CP when the user requests content. The
	content may be associated with (or managed by) the specific		content may be associated with (or managed by) the specific
	CP, when the user selects content, the CP is automatically		CP, so that when the user selects content, the CP is
	selected.		automatically selected.
	The user should send an Access-Request to the specific NSP		The user should send an Access-Request to the specific NSP
	with enough information not only for authentication by the		with enough information not only for authentication by the
	CP but also for CP selection and admission control by the		CP but also for CP selection and admission control by the
	NSP.		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
	skipping to change at page 11, line 32		skipping to change at page 10, line 49
	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 an Access-
	Request from a user, NSP relays it to the CP without CP		Request from a user, NSP relays it 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		In this case, a user subscribes to only one NSP and one CP.
	CP. The user does not select NSP and CP in this scenario.		The user does not select NSP and CP in this scenario. The
	The user should send an Access-Request to the NSP with		user should send an Access-Request to the NSP with enough
	enough information not only for authentication by the CP		information not only for authentication by the CP but also
	but also for admission control by the NSP.		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 they may have for
	various NSPs and CPs. The NSPs and CPs manage the user IDs		various NSPs and CPs. The NSPs and CPs manage the user IDs
	for their respective domains. A CP identifies a user by a		for their respective domains. A CP identifies a user by a
	user ID assigned by CP itself. A NSP identifies a user by a		user ID assigned by the CP itself. A NSP identifies a user
	user ID assigned by NSP itself. The user IDs are only		by a user ID assigned by the NSP itself. The user IDs are
	meaningful in the context of each domain. Users may hold		only meaningful within the context of each domain. Users
	multiple user IDs which have been separately assigned for		may hold multiple user IDs which have been separately
	each subscription they may have for various NSPs and CPs.		assigned for each subscription they may have for various
			NSPs and 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 a specific CP. A user		than one CP-assigned user ID per specific CP. A user sends
	sends an Access-Request to a NSP, the CP-assigned user ID		an Access-Request to a NSP, the CP-assigned user ID should
	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 relay the CP-
	assigned user ID from the user to the CP. A NSP should not		assigned user ID from the user to the CP. A NSP should not
	send a CP-assigned user ID to any CP except the one which		send a CP-assigned user ID to any CP except the one which
	assigned it and should not relay it all if there is no		assigned 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		sends an Access-Request to a NSP, the NSP-assigned user ID
	may be indicated in it so that the NSP can identify the		may be indicated in the request so that the NSP can
	user. The NSP should not relay the NSP-assigned user ID to		identify the user. The NSP should not relay the NSP-
	the CP for security reasons. The NSP may identify the		assigned user ID to the CP for security reasons. The NSP
	multicast-access user by other methods than the NSP-		may identify the multicast-access user by other methods
	assigned userID, e.g. by the access port.		than the NSP-assigned userID, e.g. by the access port.
	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 specific accounting issues for multicasting.		There are some accounting issues specific to multicasting.
	A (S,G) should be recorded as a channel identifier. The		An (S,G) should be recorded as a channel identifier. The
	last hop devices, such as a IGMP or MLD router and a IGMP		last hop device, such as an IGMP or MLD router or an IGMP
	or MLD proxy, notify a (S,G) to AAA function in the NSP.		or MLD proxy, notifies the NSP's AAA function of the (S,G)
	The (S,G) information should be notified to the CP as part		channel identifier. The NSP should notify the CP of the
	of the accounting log.		(S,G) information in the accounting report messages.
	A NSP records 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 Query-responded Join as the accounting start.		not treat a "Join" response to a Query as the accounting
			start.
	A NSP records accounting stop triggered by not only user		A NSP records an accounting stop triggered by any of the
	requested Leave but also timeout of a multicast state or		following: 1) a user requested Leave, 2) a timeout of a
	re-authentication failure. A NSP may also record an		multicast state or 3) a re-authentication failure. A NSP
	accounting stop due to network availability reasons such as		may also record an accounting stop due to network
	failure. The NSP logs the reason for each accounting stop.		availability reasons such as failure. The NSP logs the
			reason for each accounting stop.
	Also, intermittent logs between the join and leave would		Intermittent logs between the join and leave would allow
	allow for finer diagnostics and therefore could serve		for finer diagnostics and therefore could serve useful in
	useful in billing discrepancies, and provide for a finer		billing discrepancies, and provide for a better estimation
	estimation of the time spent for delivering the content in		of the time-span that content was multicasted, in the event
	the event that users disconnect without sending leave		that users disconnect without sending leave messages.
	messages.
			There are two levels of accounting report messaging.
			Messages in Accounting level 1 include a channel identifier,
			a user identifier, and the accounting start and stop time
			information. Accounting level 2 includes all information of
			Level 1, plus traffic volume information.
			QoS class is an optional item for each accounting level.
			Whether to send, and at what interval to send intermittent
			log information is optional for both levels. CP and NSPs
			may also agree to include additional option information in
			accounting messages of either level.
			The level of account report messaging between the NSP and
			CP may be either configured statically or can be
			dynamically requested by the CP in its response to the
			Access-Request relayed by the NSP to the CP. The
			determination of the actual level of report messaging is
			configured by the NSP at the NAS.
			In case of very fast channel changes, the amount of items
			logged by the NSP could become high. In order to reduce
			the number of report messages sent to the CP, the NSP can
			consolidate multiple sets of accounting information inside
			a single accounting report message. [4]
	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 needs to know traffic parameters of a multicast		The NSP receives traffic parameters (such as QoS class,
	channel for admission control. The traffic parameter		required bandwidth, burst-size, etc.) of a multicast
	information may be either indicated by the user or CP		channel. Such parameters serve as information to be
	within the access request and responses, or otherwise		considered in the admission control decision. The traffic
	shared between the NSP and CP outside the access-request		parameters can be communicated as follows:
	message mechanism:
	- A user may declare traffic parameters for each
	Access-Request.
	- 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.		message when the CP authorizes an access request. Such
			parameters may include required bandwidth, burst-size, QoS
			class downgrade policy, etc.
			- A user may indicate in the Request willingness to
			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 basis.
	A NSPs admission control may manage integrated network		The ultimate admission decision is made by the NSP based on
			required traffic parameters of the requested, and available
			resources. In a case that it cannot guarantee the required
			network resources for the requested channel, streaming the
			requested channel as best-effort traffic is optional.
			The user may indicate in his/her Access Request whether
			he/she will accept best-effort grade streaming if
			guaranteed class is not available. The CP's preference for
			accepting downgrading to best-effort streaming may be
			either configured statically or can be dynamically
			requested by the CP in its response to the Access-Request
			relayed by the NSP to the CP. In the case that it cannot
			offered a guaranteed QoS stream, the NSP may decide to
			either to decline admission or to stream the requested
			channel as best-effort traffic. 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
	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 case, 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
	depend on NSP policies and are out of the scope of this		depend on NSP policies and are out of the scope of this
	memo.		memo.
	4.6 Access Control and Distinguishing of Users by CP		4.6 Access Control and Distinguishing of Users by CP
	The user ID and authentication information are forwarded		The user ID and authentication information are forwarded
	skipping to change at page 14, line 22		skipping to change at page 14, line 33
	transparently by the NSP so that the CP can distinguish the		transparently by the NSP so that the CP can distinguish the
	user, as well as authenticate and authorize the request.		user, as well as authenticate and authorize the request.
	4.7 AAA proxy in NSP		4.7 AAA proxy in NSP
	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. The user has permission to receive		the Response message. In either case, the user has
	multicast channel at that time. The NSP starts the		permission to receive multicast channel and therefore 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
	channel(s).		channel(s).
	When a user is receiving multicast content and the		When a user is receiving multicast content and 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 reauthenticate. In such
	a case, the user will have to send the Access-Request. In		a case, the user will have to send the Access-Request. In
	skipping to change at page 14, line 41		skipping to change at page 15, line 4
	channel(s).		channel(s).
	When a user is receiving multicast content and the		When a user is receiving multicast content and 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 reauthenticate. In such
	a case, the user will have to send the Access-Request. In		a case, the user will have to send the Access-Request. In
	the case that the user still has permission to the content,		the case that the user still has permission to the content,
	they should be able to continue to receive the content		they should be able to continue to receive the content
	without interruption.		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 channel 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 introduces the high-level AAA framework for
	multicasting. This section provides more details 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
	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 User. First a user that requests content
	sends an Access request to an NSP which then forwards it on		sends an Access request to an NSP which then forwards it on
	to the appropriate CP for Authentication and Authorization		to the appropriate CP for Authentication and Authorization
	skipping to change at page 16, line 5		skipping to change at page 16, line 22
	+-----------|-------------------+		+-----------|-------------------+
	|		|
	-------|------ IFa		-------|------ IFa
	|		|
	+-----------|-------------------+		+-----------|-------------------+
	| NSP | |		| NSP | |
	|+- - - - - |- -_+ |		|+- - - - - |- -_+ |
	||TS | | |		||TS | | |
	| +------|-+ |		| +------|-+ |
	|| | AN | | |		|| | AN | | |
	| | | |		| | |---------+ |
	|| +------|-+ | |		|| +------|-+ | | |
	| | IFb |		| | IFb | |
	|| +------|-+ | | +---------+|		|| +------|-+ | | +---------+|
	| | |----|-|mAAA ||		| | |----|-|mAAA ||
	|| | NAS | | | |(MACF *) || * optional		|| | NAS | | | |(MACF *) || * optional
	| +--------+ +---------+|		| +--------+ +---------+|
	||+- - - - - - - + | |		||+- - - - - - - + | |
	+-----------------------|--------+		+-----------------------|--------+
	|		|
	-------|------ IFc		-------|------ IFc
	|		|
	+-----------------------|-------+		+-----------------------|-------+
	skipping to change at page 16, line 32		skipping to change at page 16, line 49
	Figure 2		Figure 2
	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 includes the user host(s) and optionally a
	multicast proxy (not shown in the Figure 2.)		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 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 directly to mAAA or a NAS		server.) An AN may be connected directory to mAAA or a NAS
	relays AAA information between an AN and a mAAA		relays AAA information between an AN and a mAAA
	Descriptions of AN and its interfaces are out of scope for		Descriptions of AN and its interfaces are out of scope for
	this memo. The multicast AAA function may be provided by a		this memo. The multicast AAA function may be provided by a
	multicast AAA server (mAAA) which may include the function		multicast AAA server (mAAA) which may include the function
	by which the access policy is downloaded to the NAS		by which the access policy is downloaded to the NAS
	(Multicast access control function.) The interface between		(conditional access policy control function.) The interface
	mAAA and the NAS is labeled IFb in Figure 2. Over IFb the		between mAAA and the NAS is labeled IFb in Figure 2. Over
	NAS makes an access request to the NSP-mAAA and the mAAA		IFb the NAS makes an access request to the NSP-mAAA and the
	replies. The mAAA may push conditional access policy to the		mAAA replies. The mAAA may push conditional access policy
	NAS.		to the NAS.
	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.
	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 2. 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 reply send multicast
	traffic depending on the NSP and CP’s policy decisions.		traffic depending on the NSP and CP's policy decisions.
	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 within the context of proxying		policy over this interface for AAA-proxying.
	multicast AAA messagescaching.
	Fully enabled framework		Fully enabled framework
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	|| CPE ||		|| CPE ||
	|| ||		|| ||
	|+- - - - - | - - - - - - - - -+|		|+- - - - - | - - - - - - - - -+|
	+-----------|-------------------+		+-----------|-------------------+
	|		|
	skipping to change at page 18, line 47		skipping to change at page 18, line 47
	| | CP-AAA | |		| | CP-AAA | |
	| +---------+ |		| +---------+ |
	+-------------------------------+		+-------------------------------+
	Figure 3		Figure 3
	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.)
	Before replying to the user's multicast request the mAAA		This means that Before replying to the user's multicast
	queries the MACF for a network resource access decision		request the mAAA queries the MACF for a network resource
	over the interface IFd. The MACF is responsible for		access decision over the interface IFd. The MACF is
	allocating network resources for multicast traffic. To		responsible for allocating network resources for multicast
	provide MACF with the relevant network resource		traffic. So that MACF has the necessary network resource
	availability information, NAS notifies MACF via mAAA that		availability information, NAS notifies MACF via mAAA of the
	sending multicast traffic has ceased.		stopping of multicast traffic.
	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. An 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.
	skipping to change at page 19, line 42		skipping to change at page 19, line 42
	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		[1] 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.		05.txt, September 2007, Work in Progress.
	[2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener		[2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener
	Discovery Version 2 (MLDv2) for IPv6", June 2004.		Discovery Version 2 (MLDv2) for IPv6", June 2004.
	[3] RFC-3376, Cain B., et.al., "Internet Group Management		[3] RFC-3376, Cain B., et.al., "Internet Group Management
	Protocol, Version 3", October 2002.		Protocol, Version 3", October 2002.
			[4] Ooghe, et. al, "Framework and Requirements for an
			Access Node Control Mechanism in Broadband Multi-
			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
	Hiroshi Ohta		Hiroshi Ohta
	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 R&D		France Telecom
	4, rue du Clos Courtel -		3, avenue Francois Chateau
	- BP 91226		CS 36901, 35069 Rennes Cedex, France
	35512 Cesson-Sévign�ECedex, France		Phone: +33 2 99 87 63 31
	Phone: +33 2 99 12 49 40		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
	skipping to change at page 20, line 47		skipping to change at page 21, line 4
	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.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		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
	ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),		ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
	THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET		THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
	IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE		IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
	USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS		USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
	OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR		OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
	A PARTICULAR PURPOSE.".		A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope		The IETF takes no position regarding the validity or scope
	of any Intellectual Property Rights or other rights that		of any Intellectual Property Rights or other rights that
	might be claimed to pertain to the implementation or use		might be claimed to pertain to the implementation or use
	of the technology described in this document or the extent		of the technology described in this document or the extent
	to which any license under such rights might or might not		to which any license under such rights might or might not
	be available; nor does it represent that it has made any		be available; nor does it represent that it has made any
	independent effort to identify any such rights.		independent effort to identify any such rights.
	skipping to change at page 21, line 51		skipping to change at page 22, line 51
	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 May 17, 2008.		This Internet-Draft will expire on August 22, 2008.
	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. 61 change blocks.
	164 lines changed or deleted		199 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/