draft-ietf-mboned-multiaaa-framework-03.txt		draft-ietf-mboned-multiaaa-framework-04.txt
	MBONED WG Hiroaki Satou, NTT		Internet Draft AAA Framework for Multicasting
	Internet-Draft Hiroshi Ohta, NTT		Hiroaki Satou, NTT
	Proposed Status: Informational Christian Jacquenet, France Telecom		Internet Draft Hiroshi Ohta, NTT
	Expires: September 2, 2007 Tsunemasa Hayashi, NTT		Expires: Jan 10, 2008 Christian Jacquenet, France Telecom
			Intended status: Informational Tsunemasa Hayashi, NTT
	Haixiang He, Nortel Networks		Haixiang He, Nortel Networks
	March 4, 2007
			July 9, 2007
	AAA Framework for Multicasting		AAA Framework for Multicasting
	<draft-ietf-mboned-multiaaa-framework-03.txt>		<draft-ietf-mboned-multiaaa-framework-04.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author
	applicable patent or other IPR claims of which he or she is aware		represents that any applicable patent or other IPR
	have been or will be disclosed, and any of which he or she becomes		claims of which he or she is aware have been or will
	aware will be disclosed, in accordance with Section 6 of BCP 79.		be disclosed, and any of which he or she becomes
			aware will be disclosed, in accordance with Section 6
			of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet
	Task Force (IETF), its areas, and its working groups. Note that		Engineering Task Force (IETF), its areas, and its
	other groups may also distribute working documents as Internet-		working groups. Note that other groups may also
	Drafts.		distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a
	and may be updated, replaced, or obsoleted by other documents at any		maximum of six months and may be updated, replaced,
	time. It is inappropriate to use Internet-Drafts as reference		or obsoleted by other documents at any time. It is
	material or to cite them other than as "work in progress."		inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in
			progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed
	http://www.ietf.org/ietf/1id-abstracts.txt.		at http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		Internet Draft AAA Framework for Multicasting
	http://www.ietf.org/shadow.html.		The list of Internet-Draft Shadow Directories can be
			accessed at http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 2, 2007.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007). This document
			is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth
			therein, the authors retain all their rights.
	Abstract		Abstract
	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 potential		or videoconferencing raise the issue of making sure
	customers are fully entitled to access the corresponding		that potential customers are fully entitled to access
	contents. There is indeed a need for service and content		the corresponding contents. There is indeed a need
	providers to identify (if not authenticate, especially within the		for service and content providers to identify (if not
	context of enforcing electronic payment schemes) and to invoice		authenticate, especially within the context of
	such customers in a reliable and efficient manner. This memo		enforcing electronic payment schemes) and to invoice
	describes the framework for specifying the Authorization,		such customers in a reliable and efficient manner.
	Authentication and Accounting (AAA) capabilities that could be		This memo describes the framework for specifying the
	activated within the context of the deployment and the operation		Authorization, Authentication and Accounting (AAA)
	of IP multicast-based services. This framework addresses the		capabilities that could be activated within the
	requirements presented in draft-ietf-mboned-maccnt-req-04.txt,		context of the deployment and the operation of IP
	"Requirements for Accounting, Authentication and Authorization in		multicast-based services. This framework addresses
	Well Managed IP Multicasting Services".		the requirements presented in draft-ietf-mboned-
			maccnt-req-04.txt, "Requirements for Accounting,
			Authentication and Authorization in Well Managed IP
			Multicasting Services". The memo provides a basic AAA
			enabled model as well as an extended fully enabled
			model with resource and admission control
			coordination.
	1. Introduction		1. Introduction
	1.1 Purpose and Background		1.1 Purpose and Background
	IP multicasting is designed to serve cases of group communication		IP multicasting is designed to serve cases of group
	schemes of any kind, such as 1-to-n (case of TV broadcasting		communication schemes of any kind, such as 1-to-n (case of
	services for example) or n-to-p (case of videoconferencing services,		TV broadcasting services for example) or n-to-p (case of
	for example).		videoconferencing services, for example).
	In these environments, IP multicast provides a better resource		In these environments, IP multicast provides a better
	optimization than using a unicast transmission scheme, where data		resource optimization than using a unicast transmission
	need to be replicated as many times as there are receivers.		scheme, where data need to be replicated as many times as
	Activation of IP multicast capabilities in networks yields the		there are receivers. Activation of IP multicast
	establishment and the maintenance of multicast distribution trees		capabilities in networks yields the establishment and the
	that are receiver-initiated by nature: multicast-formatted data are		maintenance of multicast distribution trees that 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 potential		or videoconferencing raise the issue of making sure that
	customers are fully entitled to access the corresponding contents.		potential customers are fully entitled to access the
	There is indeed a need for service and content providers to identify		corresponding contents.
	(if not authenticate, especially within the context of enforcing		There is indeed a need for service and content providers to
	electronic payment schemes) and to invoice such customers in a		identify (if not authenticate, especially within the
	reliable and efficient manner. This memo describes the framework for		context of enforcing electronic payment schemes) and to
	specifying the Authorization, Authentication and Accounting (AAA)		invoice such customers in a reliable and efficient manner.
	capabilities that could be activated within the context of the		Solutions should consider a wide range of possible content
	deployment and the operation of IP multicast-based services.		delivery applications: content delivered over the multicast
			network may include video, audio, images, games, software
			and information such as financial data, etc.
			This memo describes a framework for specifying the
			Authorization, Authentication and Accounting (AAA)
			capabilities that could be activated within the context of
			the deployment and the operation of IP multicast-based
			services. This memo also describes a framework to realize
			high-quality multicast transport using a Resource and
			Admission Control System (RACS) with multicast
			Authorization.
	Specifically, this framework addresses the requirements		Specifically, this framework addresses the requirements
	presented in draft-ietf-mboned-maccnt-req-04.txt, "Requirements for		presented in draft-ietf-mboned-maccnt-req-04.txt,
	Accounting, Authentication and Authorization in Well Managed IP		"Requirements for Accounting, Authentication and
	Multicasting Services" MACCNT-REQ-draft describes the requirements		Authorization in Well Managed IP Multicasting Services"
	in CDN services using IP multicast[1]. The requirements are derived		MACCNT-REQ-draft describes the requirements in CDN services
	from:		using IP 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 requirements		- need for network access control to satisfy the
	of the Network Service Provider (NSP) and/or content access control		requirements of the Network Service Provider (NSP) and/or
	to satisfy the requirements of the Content Provider (CP)		content access control to satisfy the requirements of the
	- methods for sharing information between the network service		Content Provider (CP)
	provider and content provider to make it possible to fulfill the		- methods for sharing information between the network
	above two requirements.		service provider and content provider to make it possible
			to fulfill the above two requirements.
	Detailed requirements are presented in MACCNT-REQ-draft. These		Detailed requirements are presented in MACCNT-REQ-draft.
	requirements include mechanisms for recording end-user requests and		These requirements include mechanisms for recording end-
	provider responses for content-delivery, sharing user information		user requests and provider responses for content-delivery,
	(possibly anonymously depending on the trust model) between content		sharing user information (possibly anonymously depending on
	provider and network service provider, and protecting resources		the trust model) between content provider and network
	through the prevention of network and content access by unauthorized		service provider, and protecting resources through the
			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 for		The purpose of this memo is to provide a generalized framework
	specifying multicast-inferred AAA capabilities that can meet these		for specifying multicast-inferred AAA capabilities that can
	requirements. This framework is to provide a basis for future work		meet these requirements. This framework is to provide a
	of investigating the applicability of existing AAA protocols to		basis for future work of investigating the applicability of
	provide these AAA capabilities in IP multicast specific context		existing AAA protocols to provide these AAA capabilities in
	and/or if deemed necessary, the refining or defining of protocols to		IP multicast specific context and/or if deemed necessary,
	provide these capabilities.		the refining or defining of protocols to provide these
			capabilities.
	This draft's scope is limited to discussing SSM, 1-to-n IP
	multicasting exclusively.
	2. Definitions and Abbreviations		2. Definitions and Abbreviations
	2.1 Definitions		2.1 Definitions
	For the purpose of this memo the following definitions apply:		For the purpose of this memo the following definitions
			apply:
	Accounting: The set of capabilities that allow the retrieval of a		Accounting: The set of capabilities that allow the
	set of statistical data that can be defined on a per customer and/or		retrieval of a set of statistical data that can be defined
	a per service basis, within the context of the deployment of		on a per customer and/or a per service basis, within the
	multicast-based services. Such data are retrieved for billing		context of the deployment of multicast-based services. Such
	purposes, and can be retrieved on a regular basis or upon		data are retrieved for billing purposes, and can be
	unsolicited requests. Such data include (but are not necessarily		retrieved on a regular basis or upon unsolicited requests.
	limited to) the volume of multicast-formatted data that have been		Such data include (but are not necessarily limited to) the
	forwarded to the receiver over a given period of time, the volume of		volume of multicast-formatted data that have been forwarded
	multicast-formatted data that have been exchanged between a receiver		to the receiver over a given period of time, the volume of
	(or set of) and a given source over a given period of time (e.g. the		multicast-formatted data that have been exchanged between a
	duration of a multicast session), etc.		receiver (or set of) and a given source over a given period
			of time (e.g. the duration of a multicast session), etc.
	Authentication: action for identifying a user as a genuine one.		Authentication: action for identifying a user as a genuine
			one.
	Authorization: The set of capabilities that need to be activated to		Authorization: The set of capabilities that need to be
	make sure a given requesting customer is (1) what he claims to be		activated to make sure a given requesting customer is (1)
	(identification purposes), and (2) is fully entitled to access a set		what he claims to be (identification purposes), and (2) is
	of services (authentication purposes).		fully entitled to access a set of services (authentication
			purposes).
	Receiver: an end-host or end-client which receives content. A		Receiver: an end-host or end-client which receives content.
	receiver may be identified by a network ID such as MAC address or IP		A receiver may be identified by a network ID such as MAC
	address.		address or IP address.
	User: a human with a user account. A user may possibly use multiple		User: a human with a user account. A user may possibly use
	reception devices. Multiple users may use the same reception		multiple reception devices. Multiple users may use the
	device.		same reception device.
	Note: The definition of a receiver (device) and a user (human)		Note: The definition of a receiver (device) and a user
	should not be confused.		(human) should not be confused.
	2.2 Abbreviations		2.2 Abbreviations
	For the purpose of this draft the following abbreviations apply:		For the purpose of this draft the following abbreviations
			apply:
	ACL: Access Control List		ACL: Access Control List
			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
			mRACF: Multicast Resource and Admission Control Function
	NSP: Network Service Provider		NSP: Network Service Provider
	TP: Transit Provider		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 for a		In some cases a single entity may design and be responsible
	system that covers the various common high-level requirements of a		for a system that covers the various common high-level
	multicasting system such as 1) content serving, 2) the		requirements of a multicasting system such as 1) content
	infrastructure to multicast it, 3) network and content access		serving, 2) the infrastructure to multicast it, 3) network
	control mechanisms. In many cases however the content provision and		and content access control mechanisms. In many cases
	network provision roles are divided between separate entities. The		however the content provision and network provision roles
	MACCNT-REQ-draft provides more detail of the multiple versus single		are divided between separate entities. The MACCNT-REQ-
			draft provides more detail of the multiple versus single
	entity CDS network models.		entity CDS network models.
	As such it should not be assumed that the entity responsible for the		As such it should not be assumed that the entity
	multicasting structure and the entity responsible for content		responsible for the multicasting structure and the entity
	serving are the same. Indeed because the infrastructure for		responsible for content serving are the same. Indeed
	multicasting is expensive and many content holders are not likely to		because the infrastructure for multicasting is expensive
	be competent at building and maintaining complicated infrastructures		and many content holders are not likely to be competent at
	necessary for multicasting, many content holders would prefer to		building and maintaining complicated infrastructures
	purchase transport and management services from a network service		necessary for multicasting, many content holders would
	provider and thus share the infrastructure costs with other content		prefer to purchase transport and management services from a
	holders.		network service provider and thus share the infrastructure
			costs with other content holders.
	Similarly network service providers in many cases do not specialize		Similarly network service providers in many cases do not
	in providing content and are unlikely to build and maintain such a		specialize in providing content and are unlikely to build
	resource-intensive system without a certain level of demand from		and maintain such a resource-intensive system without a
	content holders.		certain level of demand from content holders.
	The use model of a single NSP providing multicasting services to		The use model of a single NSP providing multicasting
	multiple CPs the following general requirements from MACCNT-REQ-		services to multiple CPs the following general requirements
	draft apply:		from MACCNT-REQ-draft apply:
	-Need for user tracking and billing capabilities		-Need for user tracking and billing capabilities
	-Need for network access control and/or content access control		-Need for QoS control such as resource management and
			admission control
			-Need for conditional content access control
	satisfactory to the requirements of the CP		satisfactory to the requirements of the CP
	-Methods for sharing information between the NSP and CP to make		-Methods for sharing information between the NSP and
	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 level the		-Need for access control and/or content protection at
	entity deems appropriate		level the entity deems appropriate
	4. Framework and Roles of Entities		4. Framework and Roles of Entities
	4.1 Framework for multicast AAA		4.1 Framework for multicast AAA
	A general high-level framework can be represented as follows.
			A general high-level framework can be represented as
			follows.
	+------------------------------+		+------------------------------+
	| user |		| user |
	| |		| |
	+------------------------------+		+------------------------------+
	| Access ^ Response		| Access ^ Response
	| Request | & Multicast Data		| Request | & Multicast Data
	V |		V |
	+------------------------------+		+------------------------------+
	| NSP |		| NSP |
	| |		| |
	+------------------------------+		+------------------------------+
	| Access ^ Response		| Access ^ Response
	| Request | (Success)		| Request | (Success)
	v |		v |
	+------------------------------+		+------------------------------+
	| CP |		| CP |
	| |		| |
	+------------------------------+		+------------------------------+
			Figure 1
	For the sake of simplicity, the above diagram portrays a case where		For the sake of simplicity, the above diagram portrays a
	there is a single NSP entity and a single CP entity, but multiple		case where there is a single NSP entity and a single CP
	CPs can be connected to the same NSP. It is also possible for the		entity, but multiple CPs can be connected to the same NSP.
	same CP to be connected to multiple NSP networks (e.g. network		It is also possible for the same CP to be connected to
	selection). In other words the relationship of NSP:CP can be		multiple NSP networks (e.g. network selection). In other
	described as 1:1, 1:N or M:N. Furthermore it is possible that the		words the relationship of NSP:CP can be described as 1:1,
	NSP and CP could be the same entity.		1:N or M:N. Furthermore it is possible that the NSP and CP
			could be the same entity.
	Description of Roles:		Description of Roles:
	The user (or the user's device) selects a CP and a NSP when the user		The user (or the user's device) selects a CP and a NSP when
	requests content. The NSP may be automatically selected by a user		the user requests content. The NSP may be automatically
	terminal: e.g. a fixed line NSP for STB or a mobile NSP for mobile		selected by a user terminal: e.g. a fixed line NSP for STB
	phone. In some usage cases it is possible that the NSP used by the		or a mobile NSP for mobile phone. In some usage cases it
	user terminal will not always be the same. For example a user may		is possible that the NSP used by the user terminal will not
	have contracted with different NSPs for fixed line or mobile roaming		always be the same. For example a user may have contracted
	access.		with different NSPs for fixed line or mobile roaming access.
	The CP is responsible for Authentication and Authorization of users'		The CP is responsible for Authentication and Authorization
	access to content that the CP manages. The CP hopes to collect		of users' access to content that the CP manages. The CP
	accounting information related to the access of their content. The		hopes to collect accounting information related to the
	CP may choose to authenticate and authorize NSPs which are eligible		access of their content. The CP may choose to authenticate
	to provide users access to its contents. When the CP cannot (e.g.		and authorize NSPs which are eligible to provide users
	error or resource issues) or decides not (e.g. policy issues) to		access to its contents. When the CP cannot (e.g. error or
	deliver content, the CP is responsible for notifying the NSP of the		resource issues) or decides not (e.g. policy issues) to
	reason. It is up to the NSP how to relay or translate the messages		deliver content, the CP is responsible for notifying the
	to the user.		NSP of the reason. It is up to the NSP how to relay or
			translate the messages to the user.
	The NSP is responsible for managing its network resources. The NSP		The NSP is responsible for managing its network resources.
	may perform admission control. It is also responsible for relaying		The NSP may perform admission control. It is also
	the AAA messages from the CP whether the user is eligible to receive		responsible for relaying the AAA messages from the CP
	content (authentication by proxy), and the NSPs relevant AAA server		whether the user is eligible to receive content
	will make the final decision of whether the connection can be		(authentication by proxy), and the NSP's relevant AAA
	established. When the NSP cannot or decides not to multicast to		server will allow access to the network and contents
	users, the NSP is responsible for notifying the users of the reason.		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		4.2 Multiple User IDs
	Users may hold multiple user IDs: IDs which have been separately		Users may hold multiple user IDs: IDs which have been
	assigned for each subscription they may have for various NSPs and		separately assigned for each subscription they may have for
	CPs. The NSPs and CPs control the user IDs for their respective		various NSPs and CPs. The NSPs and CPs control the user
	domains. The user IDs are only meaningful in the context of each		IDs for their respective domains. The user IDs are only
	domain.		meaningful in the context of each domain.
	When the user wants to access content, the user registers the		When the user wants to access content, the user registers
	corresponding user ID (including its CP domain information) with a		the corresponding user ID (including its CP domain
	request for content, etc: web authentication is one possible method.		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 issued to		Each CP may identify users by the user IDs that it has
	them.		issued to them.
	Terminal portability can be realized if the NSP authenticates a user		Terminal portability can be realized if the NSP
	using a NSP-domained user ID. This allows the user to access the		authenticates a user using a NSP-assigned user ID. A NSP-
	content from various network access points.		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 id for the		The NSP and CP do not need to know the corresponding user
	same user in the other provider's domain, and it is not necessary		id for the same user in the other provider's domain, and it
	that there is a one to one relationship. It is quite possible for		is not necessary that there is a one to one relationship.
	one person to hold multiple user ids for the same provider.		It is quite possible for one person to hold multiple user
			ids for the same provider.
	The actual mapping rules for NSPs and CPs to map user IDs with the		The actual mapping rules for NSPs and CPs to map user IDs
	IDs in other provider domains is a matter for the providers. A		with the IDs in other provider domains is a matter for the
	solution should provide an API between the providers to flexibly		providers. A solution should provide an API between the
	support various mapping methods.		providers to flexibly support various mapping methods.
	4.3 Accounting		4.3 Accounting
	MACCNT-REQ-draft defines requirements for Accounting and Billing.		MACCNT-REQ-draft defines requirements for Accounting and
	These include the requirement for the NSP to log user behavior such		Billing. These include the requirement for the NSP to log
	as the join action and the leave action, as well as the result of		user behavior such as the join action and the leave action,
	the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ-		as well as the result of the access-control decision.
	draft also specifies that there should be a standardized format for		(MACCNT-REQ-draft, 4.5) MACCNT-REQ-draft also specifies
	sharing with the CP the user behavior and content reception		that there should be a standardized way to sharing with the
	information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)		CP the user behavior and content reception information
	In order to provide the granularity of user-behavior and actual		which the NSP is logging.(MACCNT-REQ-draft, 4.5.1)
	content reception information as specified in MACCNT-REQ-draft, the		Standardization of the logs or messages to share content
	NSP should not manage multicast states on a subnet basis, but on a		usage information is important to support a single NSP
	user basis (see in MACCNT-REQ-draft, 4.1 "User identification")		sharing accounting information with multiple CPs or a
	because the NSP needs to be able to notify the CP of a user's start		single CP receiving from multiple NSPs.
	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.
	This framework specifies an accounting API provided by the NSP and		In order to provide the granularity of user-behavior and
	accessed by the CP to allow for sharing user-behavior and content-		actual content reception information as specified in
	reception information between the NSP AAA and CP AAA. This		MACCNT-REQ-draft, the NSP should not manage multicast
	accounting API should be configurable to allow the CP to request		states on a subnet basis, but on a user basis (see in
	only the logging information it actually requires. Such an API		MACCNT-REQ-draft, 4.1 "User identification") because the
	would allow for realtime accounting information sharing by the NSP		NSP needs to be able to notify the CP of a user's start and
	to the CP. When logging information is shared through the accounting		stop times for accounting purposes. This means that the NSP
	API, it is important that the CP be able to match the user as		sends to the CP AAA an indication for Join and Leave on a
	described in the database operated by the NSP to the user as		user basis. User-based multicast state management is
	described in the database operated by the CP.		equivalent to explicit membership tracking in RFC3376 and
			per-host tracking in RFC3810.
			This framework specifies an accounting API provided by the
			NSP and accessed by the CP to allow for sharing user-
			behavior and content-reception information between the NSP
			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		The NSP requires the capability to log both user and host
	information for each join and leave, indicating the corresponding		information for each join and leave, indicating the
	multicast source for each action. When either a CP source stops		corresponding multicast source for each action. When either
	sending, or the NSP stops multicasting, in an unsolicited manner,		a CP source stops sending, or the NSP stops multicasting,
	there is also a need to notify the AAA servers accordingly about the		in an unsolicited manner, there is also a need to notify
	users who are impacted by this event.		the AAA servers accordingly about the users who are
			impacted by this event.
	Also, intermittent logs between the join and leave would allow for		Also, intermittent logs between the join and leave would
	finer diagnostics and therefore could serve useful in billing		allow for finer diagnostics and therefore could serve
	discrepancies, and provide for a better estimation of the time span		useful in billing discrepancies, and provide for a better
	that content was multicasted in the even that users disconnect		estimation of the time span that content was multicasted in
	without sending leave messages.		the even that users disconnect without sending leave
			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 necessary		When a NSP receives an access request from a user, it is
	for the NSP to determine to which CP the request is to be directed.		necessary for the NSP to determine to which CP the request
	It is necessary for the NSP to ensure that it is not spoofed by an		is to be directed. It is necessary for the NSP to ensure
	inappropriate CP or user.		that it is not spoofed by an inappropriate CP or user.
	4.5 API for Admission Control Information by NSP		4.5 API for 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. MACCNT-		conditions for determining its admission control decision.
	REQ-draft defines requirements for providing the network capability		MACCNT-REQ-draft defines requirements for providing the
	to conduct admission control based on the network bandwidth usage		network capability to conduct admission control based on
	status and bandwidth management policy. (MACCNT-REQ-draft, 4.2.2,		the network bandwidth usage status and bandwidth management
	4.2.3 & 4.9) Such QoS measurement and policy mechanisms themselves		policy. (MACCNT-REQ-draft, 4.2.2, 4.2.3 & 4.9) Such QoS
	are out of the scope of this memo. However the NSP's AAA Server		measurement and policy mechanisms themselves are out of the
	should be provided with an Admission control API that allows for		scope of this memo. However the NSP's AAA Server should be
	interfacing so that additional conditions can be added to the		provided with an Admission control API that allows for
	admission control decision.		interfacing so that additional conditions can be added to
			the admission control decision.
	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 user, as		transparently by the NSP so that the CP can distinguish the
	well as authenticate and authorize the request.		user, as well as authenticate and authorize the request.
	4.7 Caching of AAA results		4.7 Caching of AAA results
	An NSP should be able to cache AAA results based upon an agreement		An NSP should be able to cache AAA results based upon an
	between the NSP and a CP. The AAA cache would store information		agreement between the NSP and a CP. The AAA cache would
	about permissions of a specific user to receive multicast data from		store information about permissions of a specific user to
	specified channel(s) up to specified expiration date(s) and time(s).		receive multicast data from specified channel(s) up to
	If such caching is implemented, a method must exist for the CP to		specified expiration date(s) and time(s).
	communicate this permission information to the NSP. The NSP refers		If such caching is implemented, a method must exist for the
	to the AAA cache and if the cache indicates that the user has		CP to communicate this permission information to the NSP.
	permission to receive multicast data from a specific channel at that		The NSP refers to the AAA cache and if the cache indicates
	time, the NSP may forward the data without querying the CP.		that the user has permission to receive multicast data from
			a specific channel at that time, the NSP may forward the
			data without querying the CP.
	It should be possible for a CP to send unsolicited requests to the		It should be possible for a CP to send unsolicited requests
	NSP to refresh or change the permissions for a user for specific		to the NSP to refresh or change the permissions for a user
	channel(s).		for specific channel(s).
	When a user is receiving multicast content and the permission is		When a user is receiving multicast content and the
	about to expire, the NSP may send a notification to the user client		permission is about to expire, the NSP may send a
	that his session is about to expire, and that he will need to re-		notification to the user client that his session is about
	connect. The user will have to reestablish a connection. In the		to expire, and that he will need to re-connect. The user
	case that the user still has permission to the content, they should		will have to reestablish a connection. In the case that
	be able to continue to receive the content without interruption.		the user still has permission to the content, they should
			be able to continue to receive the content without
			interruption.
	5. Network Connection Model and Functional Components		5. Network Connection Model and Functional Components
	Section 3.1 introduces the high-level AAA framework for multicasting.		Section 3.1 introduces the high-level AAA framework for
	This section provides more detail on the network connection model		multicasting. This section provides more detail on the
	and constituent functional components.		network connection model and constituent functional
			components.
	5.1 Basic Connection Model		5.1 Basic Connection Model
	+-------------+		In the simple case represented in Figure 1 the NSP is the
	| user |		sole entity providing network resources including network
	| |		access to the User. First a user that requests content
	+-------------+		sends an Access request to an NSP which then forwards it on
	^ Access & Resource		to the appropriate CP for Authentication and Authorization
	| Request		purposes. The CP responds with either "success" or
	v		"failure". If "success", the NSP may forward a success
	+-------------+		response and stream multicast data to the user.
	| NSP= NAP |
	| |
	+-------------+
	^ Access
	| Request
	v
	+-------------+
	| CP |
	| |
	+-------------+
	In this case the NSP is the sole entity providing Network Service
	Provision including Network Access Provision to the User. First a
	user that requests content sends an Access request to an NSP which
	then forwards it on to the appropriate CP for Authentication and
	Authorization purposes. The CP responds with either "success" or
	"failure". If "success", the NSP may forward a success response and
	stream multicast data to the user.
	In this model the user selects the NSP to which to send its content
	request. Based on this request the NSP selects an appropriate CP to
	which it forwards the request. The CP responds to the NSP's request:
	it may not respond to another NSP in regards to the request.
	In this model, as described in section 3.1, the relationship between
	NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple
	networks, and networks have multiple users.
	5.2 Transit Provision
	The diagram below shows that Network Service Provision may include
	both Network Access Provision to the User and also Transit Provision
	(request relay) between the Network Access Provider (NAP) and the CP.
	Transit Provision is the responsibility of the NSP which may or may
	not contract out this service to a separate NSP that acts as the
	Transit Provider. The existence of the Transit Provider is
	transparent to the user.
	+-------------+
	| user |
	| |
	+-------------+
	^ Access & Resource
	| Request
	v
	+- - - - - - - - - - - - - - +
	|+----------------+
	| Network Access | |
	|| Provision | Network Service
	+----------------+ | Provision
	| ^ Access & Resource
	| Request |
	| v
	+-------------+ |
	|| Transit |
	| Provision | |
	|+-------------+
	+- - - - - - - - - - - - - - +
	^ Access
	| Request
	v
	+-------------+
	| CP |
	| |
	+-------------+
	For the sake of simplification the above diagram shows a 1-1
	relationship between an NAP and a TP. However it is also possible
	for a single NAP to connect to multiple TPs, and a single TP to
	multiple NAPs.
	A single TP may connect to one or more CPs. Similarly just as a		In this model the user selects the NSP to which to send its
	single CP may connect to multiple NAPs (as described in the general		content request. Based on this request the NSP selects an
	high-level framework, section 3.1), a single CP may connect to one		appropriate CP to which it forwards the request. The CP
	or more TPs.		responds to the NSP's request: it may not respond to
			another NSP in regards to the request.
	A solution will include a mechanism through which the NAPs know		In this model, as described in section 3.1, the
	which TP(s) are to be used to communicate with which CP(s), and CPs		relationship between NSP and CP can be 1:1, 1:N or M:N.
	know which TP(s) to use for which NAP(s). When a TP receives an
	access or resource request from an NAP or CP, it must relay the
	request to the correct CP or NSP, respectively. Minimally, this
	means that it must reconstruct the request with translated address
	information. In this model therefore a TP must understand the
	format and meaning of the requests.
	There may be multiple TPs between a NAP and CP so that a TP is		Users may connect to multiple networks, and networks have
	actually receiving from and/or sending requests to another TP and		multiple users.
	not directly from/to a NAP or CP.
	5.3 Transit with Tunnels		5.2 Constituent Logical Functional Components of the fully
			enabled AAA Framework
	In addition to the above model of request relaying, a TP may		MACCNT-REQ-draft defined requirements for "well managed"
	communicate requests through tunneling based on the contract between		multicasting which this memo calls "AAA enabled"
	the TP and the NAP and/or between the TP and the CP. So in this		multicasting. "Fully enabled AAA" multicasting in this memo
	case the TP will not directly need to process the contents of the		means "AAA enabled" with added QoS functions.
	access and resource request (such as, header information), but
	instead pass the request directly to the correct NSP or CP, using a
	separate protocol to wrap the original requests.
	Below is a diagram, representing how a TP can provide tunneling		Section 3.1 introduces the high-level AAA framework for
	between NAP(s) and CP(s).		multicasting. Below is a diagram of a AAA enabled
			multicasting network with AAA, including the logical
			components within the various entities.
	+-----------------+		AAA enabled framework (basic model)
			+-------------------------------+
	| user |		| user |
	| |		|+- - - - - - - - - - - - - - -+|
	+-----------------+		|| CPE ||
	^ Access & Resource		|| ||
	| Request		|+- - - - - | - - - - - - - - -+|
	v		+-----------|-------------------+
	+ - - - - - - - - - - +		|
	+------------------+		-------|------ IFa
	|| NAP | |		|
	| |		+-----------|-------------------+
	|+------------------+ | Network		| NSP | |
	|^|		|+- - - - - |- -_+ |
	| |:| | Service		||TS | | |
	|:|		| +------|-+ |
	|+-|:|--------------+ | Provision		|| | AN | | |
	| |:| TP |		| | | |
	|| |:| | |		|| +------|-+ | |
	+-|:|--------------+		| | IFb |
	+ -|:|- - - - - - - - +		|| +------|-+ | | +---------+|
	|:| Tunnel		| | |----|-|mAAA ||
	|:|		|| | NAS | | | | (CAPCF*)|| * optional
	|V|		| +--------+ +---------+|
	+------------------+		||+- - - - - - - + | |
	| CP |		+-----------------------|--------+
	| |		|
	+------------------+		-------|------ IFc
			|
			+-----------------------|-------+
			| CP +---------+ |
			| | CP-AAA | |
			| +---------+ |
			+-------------------------------+
			Figure 2
			The user entity includes the CPE (Customer Premise
			Equipment) which includes the user host(s) and optionally a
			multicast proxy (not shown in the Figure 2.)
	In this model too, the relationship between NAP and TP and between		The NSP (Network Service Provider) in the basic model
	TP and CP can be 1:1, 1:N or M:N.		includes the transport system and a logical element for
			multicast AAA functionality. The transport system is
			comprised of the access node and NAS (network access
			server.) Descriptions of AN and its interfaces are out of
			scope for this memo. The multicast AAA function may be
			provided by a multicast AAA server (mAAA) which may include
			a function by which the access policy is downloaded to the
			NAS (conditional access policy control function.) The
			interface between mAAA and NAS is labeled IFb in Figure 2.
			Over IFb the NAS makes an access request to the NSP-mAAA
			and the mAAA replies. The mAAA may push conditional access
			policy to the NAS.
	5.4 Constituent Logical Functional Components of the fully enabled AAA		The content provider may have its own AAA server which has
	Framework		the authority over access policy for its contents.
	Section 3.1 introduces the high-level AAA framework for multicasting.		The interface between the user and the NSP is labeled IFa
	Below is a diagram of a fully enabled multicasting network with AAA,		in Figure 2. Over IFa the user makes a multicasting
	including the logical components within the various entities.		request to the NSP. The NSP may in reply send multicast
			traffic depending on the NSP and CP's policy decisions.
			The interface between the NSP and CP is labeled IFc. Over
			IFc the NSP requests to the CP-AAA for access to contents
			and the CP replies. CP may also send conditional access
			policy over this interface for AAA-caching.
			Fully enabled framework (c)
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	| |		|+- - - - - - - - - - - - - - -+|
	+-------------------------------+		|| CPE ||
	^		|| ||
	| Access & resource request		|+- - - - - | - - - - - - - - -+|
	v		+-----------|-------------------+
	+-------------------------------+		|
	| NSP |		-------|------ IFa
	| |		|
	|+--------------+ +---------+|		+-----------|-----------------------+
	||NR Management |<-->|AAA Proxy|| (NR= network resource)		|+- - - - - |- - _+ + - - - - - + |
	|+--------------+ RR +---------+| (RR= resource request)		||TS | | | | | |
	+-------------------------------+		| +------|-+ | +--------+ |
	^		|| | AN | | | | | mRACF || |
	| Access request		| | | | | | |
	v		|| +------|-+ | | | +---|----+| |
	+------------------------------+		| | | | | |
	| CP |		| | | | IFd----- | |
	| |		| | | IFb | | |
	| +---------+ |		|| +------|---+ | | | +---|----+| |
	| | AAA | |		| | |---|---| mAAA | |
			|| | NAS | | | | |(CAPCF*)|| | * optional
			| +----------+ | +--------+ |
			||+- - - - - - - -+ - - |- - - - -+ |
			+-----------------------|-----------+
			|
			-------|------ IFc
			|
			+-----------------------|-------+
			| CP +---------+ |
			| | CP-AAA | |
	| +---------+ |		| +---------+ |
	+------------------------------+		+-------------------------------+
			Figure 3
	In the fully enabled model the NSP provides proxying of		In the fully enabled model the NSP also includes a
	authentication and authorization between the NSP and CP, as well as		component that provides network resource management (e.g.
	user-based accounting. The AAA proxy server of the NSP communicates		QoS management), as described in section 3.4, "Network
	with the CP's AAA server. Although not shown in the above diagram		Resource Management by NSP". In the fully enabled model
	for the sake of simplicity, in addition to direct proxying between a		(Figure 3) resource management and admission control is
	NSP and CP, this proxying may be done through a TP. This means that		provided by mRACF (multicast resource and admission control
	the transit provider is also cable of supporting AAA proxying.		function.) This means that mRACF and Authorization portion
			of mAAA comprise RACS. Before replying to the user's
			multicast request the mAAA queries the mRACF for a network
			resource access decision over the interface IFd. The mRACF
			is responsible for allocating network resources for multicast
			traffic. So that mRACF has the necessary network resource
			availability information, NAS notifies mRACF via mAAA of the
			stopping of multicast traffic.
	In the fully enabled model the NSP also includes a component that		5.3 Modularity of the framework
	provides network resource management (e.g. QoS management), as
	described in section 3.4, "Network Resource Management by NSP".
	When a transit provider is used it may also provide Network Resource
	management of its own resources.
	5.5 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		so that it is possible that partially enabled versions of
	is possible that partially enabled versions of the models are		the models are supported. A AAA-enabled version provides
	supported. A AAA-enabled version provides AAA functionality without		AAA functionality without Network Resource management. A
	Network Resource management. A Network-Resource-Management-enabled		Network-Resource-Management-enabled (QoS-enabled) version
	(QoS-enabled) version provides Network Resource management without		provides Network Resource management without AAA
	AAA functionality. Similarly, the possibility of one or more layers		functionality. Similarly, the possibility of one or more
	of transit provision between an NSP and CP is in the interest of		layers of transit provision between an NSP and CP is in the
	modularity and extendibility.		interest of modularity and extendibility.
	6. IANA considerations		6. IANA considerations
	This memo does not raise any IANA consideration issues.		This memo does not raise any IANA consideration issues.
	7. Security considerations		7. Security considerations
	Refer to section 3.3. Also the user information related to		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 which		Otherwise, this memo does not raise any new security issues
	are not already addressed by the original protocols. Enhancement of		which are not already addressed by the original protocols.
	multicast access control capabilities should enhance security		Enhancement of multicast access control capabilities should
	performance.		enhance security performance.
	8. Conclusion		8. Conclusion
	This memo provides a generalized framework for solution standards to		This memo provides a generalized framework for solution
	meet the requirements presented in MACCNT-REQ-draft. Further work		standards to meet the requirements presented in MACCNT-REQ-
	should be done to break down the content provider and network		draft. Further work should be done to specify the
	service provider entities into their functional objects such as edge		interfaces between the user and NSP, NAS and mAAA, mAAA and
	devices, AAA servers, etc.		mRACF and NSP-mAAA and CP-AAA (presented in 5.2.)
	Normative References		Normative References
	[1] Hayashi, et. al., "Accounting, Authentication and Authorization		[1] Hayashi, et. al., "Accounting, Authentication and
	Issues in Well Managed IP Multicasting Services", draft-ietf-		Authorization Issues in Well Managed IP Multicasting
	mboned-maccnt-req-04.txt, February 2006, Work in Progress.		Services", draft-ietf-mboned-maccnt-req-04.txt,
			February 2006, Work in Progress.
			[2] RFC-3810, Vida, R. and L. Costa, "Multicast Listener
			Discovery Version 2 (MLDv2) for IPv6", June 2004.
			[3] RFC-3376, Cain B., et.al., "Internet Group Management
			Protocol, Version 3", October 2002.
	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 Japan		3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
			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 Japan		3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
			Japan
	Phone : +81 422 59 3617		Phone : +81 422 59 3617
	Email: ohta.hiroshi@lab.ntt.co.jp		Email: ohta.hiroshi@lab.ntt.co.jp
	Christian Jacquenet		Christian Jacquenet
	France Telecom		France Telecom
	3, avenue Francois Chateau		3, avenue Francois Chateau
	CS 36901, 35069 Rennes Cedex, France		CS 36901, 35069 Rennes Cedex, France
	Phone: +33 2 99 87 63 31		Phone: +33 2 99 87 63 31
	Email: christian.jacquenet@francetelecom.com		Email: christian.jacquenet@francetelecom.com
	Tsunemasa Hayashi		Tsunemasa Hayashi
	NTT Network Innovation Laboratories		NTT Network Innovation Laboratories
	1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan		1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847
			Japan
	Phone: +81 46 859 8790		Phone: +81 46 859 8790
	Email: tsunemasa@gmail.com		Email: tsunemasa@gmail.com
	Haixiang He		Haixiang He
	Nortel		Nortel
	600 Technology Park Drive		600 Technology Park Drive
	Billerica, MA 01801, USA		Billerica, MA 01801, USA
	Phone: +1 978 288 7482		Phone: +1 978 288 7482
	Email: haixiang@nortel.com		Email: haixiang@nortel.com
	Comments		Comments
	Comments are solicited and should be addressed to the mboned working		Comments are solicited and should be addressed to the
	group's mailing list at mboned@lists.uoregon.edu_and/or the authors.		mboned working group's mailing list at
			mboned@lists.uoregon.edu_and/or the authors.
	Intellectual Property Statement		Full Copyright Statement
	The IETF takes no position regarding the validity or scope of any		Copyright (C) The IETF Trust (2007).
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any		This document is subject to the rights, licenses and
	assurances of licenses to be made available, or the result of an		restrictions contained in BCP 78, and except as set forth
	attempt made to obtain a general license or permission for the use of		therein, the authors retain all their rights.
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		"This document and the information contained herein are
	copyrights, patents or patent applications, or other proprietary		provided on an "AS IS" basis and THE CONTRIBUTOR, THE
	rights that may cover technology that may be required to implement		ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
	this standard. Please address the information to the IETF at		THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
	ietf-ipr@ietf.org.		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
			IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
			USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS
			OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR
			A PARTICULAR PURPOSE.".
	Disclaimer of Validity		Intellectual Property
	This document and the information contained herein are provided on an		The IETF takes no position regarding the validity or scope
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		of any Intellectual Property Rights or other rights that
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		might be claimed to pertain to the implementation or use
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		of the technology described in this document or the extent
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		to which any license under such rights might or might not
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		be available; nor does it represent that it has made any
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		independent effort to identify any such rights.
			Information on the procedures with respect to rights in RFC
			documents can be found in BCP 78 and BCP 79.
	Copyright Statement		Copies of IPR disclosures made to the IETF Secretariat and
			any assurances of licenses to be made available, or the
			result of an attempt made to obtain a general license or
			permission for the use of such proprietary rights by
			implementers or users of this specification can be
			obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	Copyright (C) The IETF Trust (2007). This document is subject to the		The IETF invites any interested party to bring to its
	rights, licenses and restrictions contained in BCP 78, and except as		attention any copyrights, patents or patent applications,
	set forth therein, the authors retain all their rights.		or other proprietary rights that may cover technology that
			may be required to implement this standard. Please
			address the information to the IETF at ietf-ipr@ietf.org.
	Acknowledgment		Expiration
	Funding for the RFC Editor function is currently provided by the		This Internet-Draft will expire on January 10, 2008.
	Internet Society.
			Acknowledgement
			Funding for the RFC Editor function is currently provided
			by the Internet Society.
End of changes. 93 change blocks.
	491 lines changed or deleted		561 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/