draft-ietf-mboned-multiaaa-framework-04.txt		draft-ietf-mboned-multiaaa-framework-05.txt
	Internet Draft AAA Framework for Multicasting		Internet Draft AAA Framework for Multicasting November
			2007
	Hiroaki Satou, NTT		Hiroaki Satou, NTT
	Internet Draft Hiroshi Ohta, NTT		Internet Draft Hiroshi Ohta, NTT
	Expires: Jan 10, 2008 Christian Jacquenet, France Telecom		Expires: May 17, Christian Jacquenet, France Telecom
	Intended status: Informational Tsunemasa Hayashi, NTT		2008
			Tsunemasa Hayashi, NTT
	Haixiang He, Nortel Networks		Haixiang He, Nortel Networks
	July 9, 2007		November 19, 2007
	AAA Framework for Multicasting		AAA Framework for Multicasting
	<draft-ietf-mboned-multiaaa-framework-04.txt>		<draft-ietf-mboned-multiaaa-framework-05.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 6		aware will be disclosed, in accordance with Section
	of BCP 79.		6 of BCP 79.
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the
	Engineering Task Force (IETF), its areas, and its		Internet Engineering Task Force (IETF), its areas,
	working groups. Note that other groups may also		and its working groups. Note that other groups may
	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		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 January 10, 2008.		This Internet-Draft will expire on May 17, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007). This document		Copyright (C) The IETF Trust (2007). 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		contained in BCP 78, and except as set forth therein,
	therein, the authors retain all their rights.		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 access		that potential customers are fully entitled to
	the corresponding contents. There is indeed a need		access the corresponding contents. There is indeed a
	for service and content providers to identify (if not		need for service and content providers to identify
	authenticate, especially within the context of		(if not authenticate, especially within the context
	enforcing electronic payment schemes) and to invoice		of enforcing electronic payment schemes) and to
	such customers in a reliable and efficient manner.		invoice such customers in a reliable and efficient
	This memo describes the framework for specifying the		manner. This memo describes the framework for
	Authorization, Authentication and Accounting (AAA)		specifying the Authorization, Authentication and
	capabilities that could be activated within the		Accounting (AAA) capabilities that could be
	context of the deployment and the operation of IP		activated within the context of the deployment and
	multicast-based services. This framework addresses		the operation of IP multicast-based services. This
	the requirements presented in draft-ietf-mboned-		framework addresses the requirements presented in
	maccnt-req-04.txt, "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". The memo provides a basic AAA		Well Managed IP Multicasting Services". The memo
	enabled model as well as an extended fully enabled		provides a basic AAA enabled model as well as an
	model with resource and admission control		extended fully enabled model with resource and
	coordination.		admission control coordination.
			STATUS OF THIS MEMO 1
			COPYRIGHT NOTICE 2
			ABSTRACT 2
			1. INTRODUCTION 5
			1.1 PURPOSE AND BACKGROUND 5
			2. DEFINITIONS AND ABBREVIATIONS 6
			2.1 DEFINITIONS 6
			2.2 ABBREVIATIONS 7
			3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7
			4. FRAMEWORK AND ROLES OF ENTITIES 8
			4.1 FRAMEWORK FOR MULTICAST AAA 8
			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.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11
			4.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP 11
			4.2 USER ID 11
			4.2.1 CP-ASSIGNED USER ID 12
			4.2.2 NSP-ASSIGNED USER ID 12
			4.3 ACCOUNTING 12
			4.4 ACCESS CONTROL AND CP SELECTION BY NSP 13
			4.5 ADMISSION CONTROL INFORMATION BY NSP 13
			4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 14
			4.7 AAA PROXY IN NSP 14
			5.1 BASIC CONNECTION MODEL 14
			5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY
			ENABLED AAA FRAMEWORK 15
			5.3 MODULARITY OF THE FRAMEWORK 19
			6. IANA CONSIDERATIONS 19
			7. SECURITY CONSIDERATIONS 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
	skipping to change at page 3, line 43		skipping to change at page 5, line 42
	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 Resource and
	Admission Control System (RACS) with multicast		Admission Control System (RACS) with multicast
	Authorization.		Authorization.
	Specifically, this framework addresses the requirements		Specifically, this framework addresses the requirements
	presented in draft-ietf-mboned-maccnt-req-04.txt,		presented in draft-ietf-mboned-maccnt-req-05.txt,
	"Requirements for Accounting, Authentication and		"Requirements for Multicast AAA coordinated between Content
	Authorization in Well Managed IP Multicasting Services"		Provider(s) and Network Service Provider(s)" MACCNT-REQ-
	MACCNT-REQ-draft describes the requirements in CDN services		draft describes the requirements in CDN services using IP
	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
	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.
	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 framework		The purpose of this memo is to provide a generalized
	for specifying multicast-inferred AAA capabilities that can		framework for
			specifying multicast-inferred AAA capabilities that can
	meet these requirements. This framework is to provide a		meet these requirements. This framework is to provide a
	basis for future work of investigating the applicability of		basis for future work of investigating the applicability of
	existing AAA protocols to provide these AAA capabilities in		existing AAA protocols to provide these AAA capabilities in
	IP multicast specific context and/or if deemed necessary,		IP multicast specific context and/or if deemed necessary,
	the refining or defining of protocols to provide these		the refining or defining of protocols to provide these
	capabilities.		capabilities.
	2. Definitions and Abbreviations		2. Definitions and Abbreviations
	2.1 Definitions		2.1 Definitions
	skipping to change at page 5, line 38		skipping to change at page 7, line 38
	CAPCF: Conditional Access Policy Control Function		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
	mRACF: Multicast Resource and 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
	requirements of a multicasting system such as 1) content		requirements of a multicasting system such as 1) content
	skipping to change at page 6, line 42		skipping to change at page 8, line 42
	-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 Entities		4. Framework and Roles of Entities4.1 Framework for multicast
			AAA
	4.1 Framework for multicast AAA
	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 | & Multicast Data		| Request |
	V |		V |
	+------------------------------+		+------------------------------+
	| NSP |		| NSP |
	| |		| |
	+------------------------------+		+------------------------------+
	| Access ^ Response		| Access ^ Response
	| Request | (Success)		| Request | (Success)
	v |		v |
	+------------------------------+		+------------------------------+
	| CP |		| CP |
	| |		| |
	+------------------------------+		+------------------------------+
	Figure 1		Figure 1
	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 the same NSP.		entity, but multiple CPs can be connected to a single NSP
	It is also possible for the same CP to be connected to		(e.g. NSP may provide connections to multiple CPs to
	multiple NSP networks (e.g. network selection). In other		provide a wide selection of content categories.) It is also
	words the relationship of NSP:CP can be described as 1:1,		possible for a single CP to be connected to multiple NSP
	1:N or M:N. Furthermore it is possible that the NSP and CP		networks (e.g. network selection). Furthermore it is
	could be the same entity.		possible that the NSP and CP could be the same entity. A
			NSP and CP authenticate and authorize each other when they
			establish connectivity. Below the general case of multiple
			NSPs with multiple CPs is explained. Then, the various
			combinations of single and multiple CPs and NSPs are
			described in relation to the general case.
	Description of Roles:		4.1.1 Multiple CPs are connected to multiple NSPs
	The user (or the user's device) selects a CP and a NSP when		The user subscribes to multiple NSPs and multiple CPs in
	the user requests content. The NSP may be automatically		this usage case. The user selects a CP and a NSP when the
	selected by a user terminal: e.g. a fixed line NSP for STB		user requests content. The NSP may be automatically
	or a mobile NSP for mobile phone. In some usage cases it		selected by a user terminal: e.g. a fixed line NSP by a set
	is possible that the NSP used by the user terminal will not		top box or a mobile NSP by a mobile phone. In some usage
	always be the same. For example a user may have contracted		cases it is possible that the NSP used by a certain user
	with different NSPs for fixed line or mobile roaming access.		will not always be the same. For example a user may have
			contracted with more than one NSP: one for fixed line
			access and another for mobile roaming access.
	The CP is responsible for Authentication and Authorization		The content may be associated with (or managed by) a
	of users' access to content that the CP manages. The CP		specific CP. In this case, when the user selects content,
	hopes to collect accounting information related to the		the CP is automatically selected.
	access of their content. The CP may choose to authenticate
	and authorize NSPs which are eligible to provide users		The user should send an Access-Request to the selected NSP
	access to its contents. When the CP cannot (e.g. error or		with enough information not only for authentication by the
			CP but also for CP selection and admission control by the
			NSP.
			When an NSP receives an Access-Request from a user, the NSP
			selects the appropriate CP for the received Access-Request
			and relays the content request. As the NSP is responsible
			for managing its network resources, the NSP may perform
			admission control.The NSP will allow access to the network
			and contents conditional to both the CP's content
			authorization result and the NSPs network availability.
			That is, the NSP starts multicast flow only when it has
			both 1) received an ‘‘accept’’ response from the CP and 2)
			determined that the network resources (e.g. bandwidth) are
			sufficient to serve the multicast channel. When neither of
			these conditions are met, the NSP does not start the
			requested multicast channel. When the NSP already knows
			that network resources are insufficient or there is a
			network failure, the NSP may choose to not relay the
			Access-Request to the CP. The NSP is also responsible for
			relaying the Response message from the CP to the user
			whether the user is eligible to receive content (in
			response to the corresponding Access-Request from the user
			to the CP.) In cases that the NSP does not start multicast
			because of its own network issues (e.g. lack of network
			resources or network failure), the NSP notifies the user
			with a reason for rejecting the request.
			A CP receives an Access-Request relayed by the NSP. The CP
			authenticates the NSP’s identity and makes an authorization
			decision regarding the NSP’s eligibility to provide users
			access to its contents. The CP is responsible for
			Authentication and Authorization of users' access to
			content that the CP manages. The CP hopes to collect
			accounting information related to the access of their
			content. The CP responds to the NSP regarding the relayed
			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 messages to the user.		translate the reasons for rejection to the user.
	The NSP is responsible for managing its network resources.		4.1.2 Multiple CPs are connected to a single NSP
	The NSP may perform admission control. It is also
	responsible for relaying the AAA messages from the CP
	whether the user is eligible to receive content
	(authentication by proxy), and the NSP's relevant AAA
	server will allow access to the network and contents
	conditional to both the CP AAA server's content
	authorization result and the NSPs network utilization
	authorization result. In certain cases the CP and NSP may
	have a contractual relationship in which the NSP is
	authorized to make the content authorization decision based
	on mutually predetermined criteria: in such cases the NSP-
	AAA may also make the content authorization decision
	without querying the CP-AAA. When the NSP cannot or
	decides not to multicast to users, the NSP may notify the
	users of the reason. It is recommended that the NSP notify
	eligible users of the reason for not multicasting content
	when it is due network or content unavailability, for
	example. The NSP may choose not to notify ineligible users
	of the reason for any case.
	4.2 Multiple User IDs		The user subscribes to a single NSP which provides
			multicasting of channels from multiple CPs in this usage
			case. In this case the user does not select an NSP. The
			user selects a CP when the user requests content. The
			content may be associated with (or managed by) the specific
			CP, when the user selects content, the CP is automatically
			selected.
			The user should send an Access-Request to the specific NSP
			with enough information not only for 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 a CP is the same as that described in 4.1.1.
			4.1.3 A single CP is connected to multiple NSPs
			A user subscribes to multiple NSPs but a single CP in this
			usage case. A user selects the NSP when the user requests
			content but the CP is fixed. The user should send an
			Access-Request to the selected NSP with enough information
			not only for authentication by the CP but also for
			admission control by the NSP.
			The role of the NSP is similar to the description in 4.1.1,
			with the exception that when a NSP receives an Access-
			Request from a user, NSP relays it to the CP without CP
			selection.
			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
			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 user should send an Access-Request to the NSP with
			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 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
			roles of the NSP and CP may be combined.
			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 control the user		various NSPs and CPs. The NSPs and CPs manage the user IDs
	IDs for their respective domains. The user IDs are only		for their respective domains. A CP identifies a user by a
	meaningful in the context of each domain.		user ID assigned by CP itself. A NSP identifies a user by a
			user ID assigned by NSP itself. The user IDs are only
			meaningful in the context of each domain. Users may hold
			multiple user IDs which have been separately assigned for
			each subscription they may have for various NSPs and CPs.
	When the user wants to access content, the user registers		4.2.1 CP-assigned user ID
	the corresponding user ID (including its CP domain
	information) with a request for content, etc: web
	authentication is one possible method.
	Each CP may identify users by the user IDs that it has		CPs assign user IDs to their users. The user may have more
	issued to them.		than one CP-assigned user ID per a specific CP. A user
			sends an Access-Request to a NSP, the CP-assigned user ID
			should be indicated so that the CP can identify the user
			requesting content access. A NSP should relay the CP-
			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
			assigned it and should not relay it all if there is no
			appropriate CP that assigned the user ID.
	Terminal portability can be realized if the NSP		4.2.2 NSP-assigned user ID
	authenticates a user using a NSP-assigned user ID. A NSP-
	assigned user ID is an access-line independent unique ID
	assigned to users which allows user identification from any
	access point within the network and possibly roaming to
	other networks. This allows the user to access the content
	from various network access points.
	The NSP and CP do not need to know the corresponding user		NSPs assign user IDs to their users. A user may have more
	id for the same user in the other provider's domain, and it		than one NSP-assigned user ID per a specific NSP. A user
	is not necessary that there is a one to one relationship.		sends an Access-Request to a NSP, the NSP-assigned user ID
	It is quite possible for one person to hold multiple user		may be indicated in it so that the NSP can identify the
	ids for the same provider.		user. The NSP should not relay the NSP-assigned user ID to
			the CP for security reasons. The NSP may identify the
			multicast-access user by other methods than the NSP-
			assigned userID, e.g. by the access port.
	The actual mapping rules for NSPs and CPs to map user IDs		The actual mapping rules for NSP-assigned user IDs with CP-
	with the IDs in other provider domains is a matter for the		user assigned IDs in account logs is a matter for the
	providers. A solution should provide an API between the		providers and out of the scope of this framework.
	providers to flexibly support various mapping methods.
	4.3 Accounting		4.3 Accounting
	MACCNT-REQ-draft defines requirements for Accounting and		There are some specific accounting issues for multicasting.
	Billing. These include the requirement for the NSP to log		A (S,G) should be recorded as a channel identifier. The
	user behavior such as the join action and the leave action,		last hop devices, such as a IGMP or MLD router and a IGMP
	as well as the result of the access-control decision.		or MLD proxy, notify a (S,G) to AAA function in the NSP.
	(MACCNT-REQ-draft, 4.5) MACCNT-REQ-draft also specifies		The (S,G) information should be notified to the CP as part
	that there should be a standardized way to sharing with the		of the accounting log.
	CP the user behavior and content reception information
	which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)
	Standardization of the logs or messages to share content
	usage information is important to support a single NSP
	sharing accounting information with multiple CPs or a
	single CP receiving from multiple NSPs.
	In order to provide the granularity of user-behavior and
	actual content reception information as specified in
	MACCNT-REQ-draft, the NSP should not manage multicast
	states on a subnet basis, but on a user basis (see in
	MACCNT-REQ-draft, 4.1 "User identification") because the
	NSP needs to be able to notify the CP of a user's start and
	stop times for accounting purposes. This means that the NSP
	sends to the CP AAA an indication for Join and Leave on a
	user basis. User-based multicast state management is
	equivalent to explicit membership tracking in RFC3376 and
	per-host tracking in RFC3810.
	This framework specifies an accounting API provided by the		A NSP records accounting start corresponding to only the
	NSP and accessed by the CP to allow for sharing user-		first Join for a specific user access session. A NSP should
	behavior and content-reception information between the NSP		not treat a Query-responded Join as the accounting start.
	AAA and CP AAA. This accounting API should be configurable
	to allow the CP to request only the logging information it
	actually requires. Such an API would allow for realtime
	accounting information sharing by the NSP to the CP. When
	logging information is shared through the accounting API,
	it is important that the CP be able to match the user as
	described in the database operated by the NSP to the user
	as described in the database operated by the CP.
	The NSP requires the capability to log both user and host		A NSP records accounting stop triggered by not only user
	information for each join and leave, indicating the		requested Leave but also timeout of a multicast state or
	corresponding multicast source for each action. When either		re-authentication failure. A NSP may also record an
	a CP source stops sending, or the NSP stops multicasting,		accounting stop due to network availability reasons such as
	in an unsolicited manner, there is also a need to notify		failure. The NSP logs the reason for each accounting stop.
	the AAA servers accordingly about the users who are
	impacted by this event.
	Also, intermittent logs between the join and leave would		Also, intermittent logs between the join and leave would
	allow for finer diagnostics and therefore could serve		allow for finer diagnostics and therefore could serve
	useful in billing discrepancies, and provide for a better		useful in billing discrepancies, and provide for a finer
	estimation of the time span that content was multicasted in		estimation of the time spent for delivering the content in
	the even that users disconnect without sending leave		the event that users disconnect without sending leave
	messages.		messages.
	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, it is		When a NSP receives an access request from a user, the NSP
	necessary for the NSP to determine to which CP the request		determines to which CP the request is to be directed. The
	is to be directed. It is necessary for the NSP to ensure		NSP may select a CP based on CP-assigned userID with CP
	that it is not spoofed by an inappropriate CP or user.		domain name or channel identifier (S,G). The user should
			include in the request sufficient information for CP
			selection.
	4.5 API for 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.
	MACCNT-REQ-draft defines requirements for providing the
	network capability to conduct admission control based on		The NSP needs to know traffic parameters of a multicast
	the network bandwidth usage status and bandwidth management		channel for admission control. The traffic parameter
	policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS		information may be either indicated by the user or CP
	measurement and policy mechanisms themselves are out of the		within the access request and responses, or otherwise
	scope of this memo. However the NSP's AAA Server should be		shared between the NSP and CP outside the access-request
	provided with an Admission control API that allows for		message mechanism:
	interfacing so that additional conditions can be added to		- A user may declare traffic parameters for each
	the admission control decision.		Access-Request.
			- A CP may notify a mapping between the channel
			identifier (S,G) and traffic parameters in the Response
			message when the CP authorizes an access request.
			- The NSP may maintain a mapping between channel
			identifier (S,G) and traffic parameters in advance, for
			example pre-configured by agreement between the CP and NSP
			on a per channel basis.
			A NSPs admission control may manage integrated network
			resources for unicast usage, such as VoIP or unicast
			streaming, and multicast usage. Alternatively, it may
			manage network resources separately for unicast and
			multicast usage. In either case, AAA and admission control
			framework for multicast usage is independent of unicast
			admission control.
			Such QoS measurement and policy mechanisms themselves
			depend on NSP policies and are out of the scope of this
			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
	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 Caching of AAA results		4.7 AAA proxy in NSP
	An NSP should be able to cache AAA results based upon an		A NSP may act as AAA proxy of a CP based upon an agreement
	agreement between the NSP and a CP. The AAA cache would		between the NSP and the CP. The AAA proxy would store
	store information about permissions of a specific user to		information about permissions of a specific user to receive
	receive multicast data from specified channel(s) up to		multicast data from specified channel(s) up to specified
	specified expiration date(s) and time(s).		expiration date(s) and time(s).
	If such caching is implemented, a method must exist for the		If such proxying is implemented, the NSP may receive
	CP to communicate this permission information to the NSP.		authorization conditions from a CP in advance and
	The NSP refers to the AAA cache and if the cache indicates		statically hold them, or a CP may send them dynamically in
	that the user has permission to receive multicast data from		the Response message. The user has permission to receive
	a specific channel at that time, the NSP may forward the		multicast channel at that time. The NSP starts the
	data without querying the CP.		multicasting without querying the CP.
	It should be possible for a CP to send unsolicited requests		The CP may send unsolicited requests to the NSP to refresh
	to the NSP to refresh or change the permissions for a user		or change the permissions for a user for specific
	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 re-connect. The user		to expire, and that he will need to reauthenticate. In such
	will have to reestablish a connection. In the case that		a case, the user will have to send the Access-Request. In
	the user still has permission to the content, they should		the case that the user still has permission to the content,
	be able to continue to receive the content without		they should be able to continue to receive the content
	interruption.		without interruption.
			When re-authentication fails, the NSP should stop the
			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 detail on the		multicasting. This section provides more details 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 12, line 4		skipping to change at page 15, line 19
	response and stream multicast data to the user.		response and stream multicast data to the user.
	In this model the user selects the NSP to which to send its		In this model the user selects the NSP to which to send its
	content request. Based on this request the NSP selects an		content request. Based on this request the NSP selects an
	appropriate CP to which it forwards the request. The CP		appropriate CP to which it forwards the request. The CP
	responds to the NSP's request: it may not respond to		responds to the NSP's request: it may not respond to
	another NSP in regards to the request.		another NSP in regards to the request.
	In this model, as described in section 3.1, the		In this model, as described in section 3.1, the
	relationship between NSP and CP can be 1:1, 1:N or M:N.		relationship between NSP and CP can be 1:1, 1:N or M:N.
	Users may connect to multiple networks, and networks have		Users may connect to multiple networks, and networks have
	multiple users.		multiple users.
	5.2 Constituent Logical Functional Components of the fully		5.2 Constituent Logical Functional Components of the fully
	enabled AAA Framework		enabled AAA Framework
	MACCNT-REQ-draft defined requirements for "well managed"		Requirements for "fully AAA and QoS enabled" IP
	multicasting which this memo calls "AAA enabled"		multicasting networks were defined in MACCNT-REQ-draft. To
	multicasting. "Fully enabled AAA" multicasting in this memo		allow for levels of enablement, this memo defines two
	means "AAA enabled" with added QoS functions.		models within the framework: "AAA enabled" multicasting and
			"Fully enabled AAA" multicasting which means "AAA enabled"
			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)		AAA enabled framework (basic model)
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	skipping to change at page 13, line 40		skipping to change at page 16, line 10
	| NSP | |		| NSP | |
	|+- - - - - |- -_+ |		|+- - - - - |- -_+ |
	||TS | | |		||TS | | |
	| +------|-+ |		| +------|-+ |
	|| | AN | | |		|| | AN | | |
	| | | |		| | | |
	|| +------|-+ | |		|| +------|-+ | |
	| | IFb |		| | IFb |
	|| +------|-+ | | +---------+|		|| +------|-+ | | +---------+|
	| | |----|-|mAAA ||		| | |----|-|mAAA ||
	|| | NAS | | | | (CAPCF*)|| * optional		|| | NAS | | | |(MACF *) || * optional
	| +--------+ +---------+|		| +--------+ +---------+|
	||+- - - - - - - + | |		||+- - - - - - - + | |
	+-----------------------|--------+		+-----------------------|--------+
	|		|
	-------|------ IFc		-------|------ IFc
	|		|
	+-----------------------|-------+		+-----------------------|-------+
	| CP +---------+ |		| CP +---------+ |
	| | CP-AAA | |		| | CP-AAA | |
	| +---------+ |		| +---------+ |
	skipping to change at page 14, line 4		skipping to change at page 16, line 23
	+-----------------------|--------+		+-----------------------|--------+
	|		|
	-------|------ IFc		-------|------ IFc
	|		|
	+-----------------------|-------+		+-----------------------|-------+
	| CP +---------+ |		| CP +---------+ |
	| | CP-AAA | |		| | CP-AAA | |
	| +---------+ |		| +---------+ |
	+-------------------------------+		+-------------------------------+
	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.) Descriptions of AN and its interfaces are out of		server) An AN may be connected directly to mAAA or a NAS
	scope for this memo. The multicast AAA function may be		relays AAA information between an AN and a mAAA
	provided by a multicast AAA server (mAAA) which may include		Descriptions of AN and its interfaces are out of scope for
	a function by which the access policy is downloaded to the		this memo. The multicast AAA function may be provided by a
	NAS (conditional access policy control function.) The		multicast AAA server (mAAA) which may include the function
	interface between mAAA and NAS is labeled IFb in Figure 2.		by which the access policy is downloaded to the NAS
	Over IFb the NAS makes an access request to the NSP-mAAA		(Multicast access control function.) The interface between
	and the mAAA replies. The mAAA may push conditional access		mAAA and the NAS is labeled IFb in Figure 2. Over IFb the
	policy to the NAS.		NAS makes an access request to the NSP-mAAA and the mAAA
			replies. The mAAA may push conditional access policy 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 for AAA-caching.		policy over this interface within the context of proxying
			multicast AAA messagescaching.
	Fully enabled framework (c)		Fully enabled framework
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	|| CPE ||		|| CPE ||
	|| ||		|| ||
	|+- - - - - | - - - - - - - - -+|		|+- - - - - | - - - - - - - - -+|
	+-----------|-------------------+		+-----------|-------------------+
	|		|
	-------|------ IFa		-------|------ IFa
	|		|
	+-----------|-----------------------+		+-----------|-----------------------+
	|+- - - - - |- - _+ + - - - - - + |		|+- - - - - |- - _+ + - - - - - + |
	||TS | | | | | |		||TS | | | | | |
	| +------|-+ | +--------+ |		| +------|-+ | +--------+ |
	|| | AN | | | | | mRACF || |		|| | AN | | | | | MACF || |
	| | | | | | |		| | | | | | |
	|| +------|-+ | | | +---|----+| |		|| +------|-+ | | | +---|----+| |
	| | | | | |		| | | | | |
	| | | | IFd----- | |		| | | | IFd----- | |
	| | | IFb | | |		| | | IFb | | |
	|| +------|---+ | | | +---|----+| |		|| +------|---+ | | | +---|----+| |
	| | |---|---| mAAA | |		| | |---|---| mAAA | |
	|| | NAS | | | | |(CAPCF*)|| | * optional		|| | NAS | | | | |(MACF *)|| | * optional
	| +----------+ | +--------+ |		| +----------+ | +--------+ |
	||+- - - - - - - -+ - - |- - - - -+ |		||+- - - - - - - -+ - - |- - - - -+ |
	+-----------------------|-----------+		+-----------------------|-----------+
	|		|
	-------|------ IFc		-------|------ IFc
	|		|
	+-----------------------|-------+		+-----------------------|-------+
	| CP +---------+ |		| CP +---------+ |
	| | 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 mRACF (multicast resource and admission control		provided by MACF (multicast admission control function).
	function.) This means that mRACF and Authorization portion		Before replying to the user's multicast request the mAAA
	of mAAA comprise RACS. Before replying to the user's		queries the MACF for a network resource access decision
	multicast request the mAAA queries the mRACF for a network		over the interface IFd. The MACF is responsible for
	resource access decision over the interface IFd. The mRACF		allocating network resources for multicast traffic. To
	is responsible for allocating network resources for multicast		provide MACF with the relevant network resource
	traffic. So that mRACF has the necessary network resource		availability information, NAS notifies MACF via mAAA that
	availability information, NAS notifies mRACF 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. A AAA-enabled version provides		the models are supported. An 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 17, line 33		skipping to change at page 19, line 35
	Refer to section 3.3. Also the user information related to		Refer to section 3.3. Also the user information related to
	authentication with the CP must be protected in some way.		authentication with 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 presented in MACCNT-REQ-		standards to meet the requirements. Further work should be
	draft. Further work should be done to specify the		done to specify the interfaces between the user and NSP,
	interfaces between the user and NSP, NAS and mAAA, mAAA and		NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA
	mRACF and NSP-mAAA and CP-AAA (presented in 5.2.)		(presented in 5.2.)
	Normative References		Normative References
	[1] Hayashi, et. al., "Accounting, Authentication and		[1] Hayashi, et. al., Requirements for Multicast AAA
	Authorization Issues in Well Managed IP Multicasting		coordinated between Content Provider(s) and Network
	Services", draft-ietf-mboned-maccnt-req-04.txt,		Service Provider(s)", draft-ietf-mboned-maccnt-req-
	February 2006, 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.
	Authors' Addresses		Authors' Addresses
	Hiroaki Satou		Hiroaki Satou
	skipping to change at page 18, line 25		skipping to change at page 20, line 25
	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		France Telecom R&D
	3, avenue Francois Chateau		4, rue du Clos Courtel -
	CS 36901, 35069 Rennes Cedex, France		- BP 91226
	Phone: +33 2 99 87 63 31		35512 Cesson-Sévign�ECedex, France
	Email: christian.jacquenet@francetelecom.com		Phone: +33 2 99 12 49 40
			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 19, line 51		skipping to change at page 21, 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 January 10, 2008.		This Internet-Draft will expire on May 17, 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. 57 change blocks.
	236 lines changed or deleted		354 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/