draft-ietf-mboned-multiaaa-framework-07.txt		draft-ietf-mboned-multiaaa-framework-08.txt
	Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008
	Internet Draft Hiroaki Satou, NTT		Internet Draft Hiroaki Satou, NTT
	Intended Status: Hiroshi Ohta, NTT		Intended Status: Informational Hiroshi Ohta, NTT
	Informational		Expires: August 1, 2009 Christian Jacquenet, France Telecom
	Expires: January Christian Jacquenet, France Telecom
	3, 2009
	Tsunemasa Hayashi, NTT		Tsunemasa Hayashi, NTT
	Haixiang He, Nortel Networks		Haixiang He, Nortel Networks
	July 1, 2008		January 28, 2009
	AAA and Admission Control Framework for Multicasting		AAA and Admission Control Framework for Multicasting
	<draft-ietf-mboned-multiaaa-framework-07.txt>		<draft-ietf-mboned-multiaaa-framework-08.txt>
	Status of this Memo		Status of this Memo
			This Internet-Draft is submitted to IETF in full conformance
	By submitting this Internet-Draft, each author represents		with the provisions of BCP 78 and BCP 79.
	that any applicable patent or other IPR claims of which he
	or she is aware have been or will be disclosed, and any of
	which he or she becomes aware will be disclosed, in
	accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working		groups. Note that other groups may also distribute working
	documents as Internet-Drafts.		documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of		Internet-Drafts are draft documents valid for a maximum of
	six months and may be updated, replaced, or obsoleted by		six months and may be updated, replaced, or obsoleted by
	other documents at any time. It is inappropriate to use		other documents at any time. It is inappropriate to use
	Internet-Drafts as reference material or to cite them other		Internet-Drafts as reference material or to cite them other
	than as "work in progress."		than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be		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.
	Internet Draft AAA and Admission Control Framework for		This Internet-Draft will expire on August 1, 2009.
	Multicasting July, 2008
	This Internet-Draft will expire on January 3, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008). This document is		Copyright (c) 2009 IETF Trust and the persons identified as the
	subject to the rights, licenses and restrictions contained		document authors. All rights reserved.
	in BCP 78, and except as set forth therein, the authors
	retain all their rights.		Internet Draft AAA and Admission Control Framework for
			Multicasting January, 2009
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with
			respect to this document.
	Abstract		Abstract
	IP multicast-based services, such as TV broadcasting or		IP multicast-based services, such as TV broadcasting or
	videoconferencing raise the issue of making sure that		videoconferencing raise the issue of making sure that
	potential customers are fully entitled to access the		potential customers are fully entitled to access the
	corresponding contents. There is indeed a need for service		corresponding contents. There is indeed a need for service
	and content providers to identify users (if not		and content providers to identify users (if not
	authenticate, especially within the context of enforcing		authenticate, especially within the context of enforcing
	electronic payment schemes) and to retrieve statistical		electronic payment schemes) and to retrieve statistical
	skipping to change at page 3, line 5		skipping to change at page 3, line 5
	and Accounting (AAA) capabilities that could be activated		and Accounting (AAA) capabilities that could be activated
	within the context of the deployment and the operation of		within the context of the deployment and the operation of
	IP multicast-based services. This framework addresses the		IP multicast-based services. This framework addresses the
	requirements presented in "Requirements for Accounting,		requirements presented in "Requirements for Accounting,
	Authentication and Authorization in Well Managed IP		Authentication and Authorization in Well Managed IP
	Multicasting Services" [I-D.mboned-maccnt-req]. The memo		Multicasting Services" [I-D.mboned-maccnt-req]. The memo
	provides a basic AAA enabled model as well as an extended		provides a basic AAA enabled model as well as an extended
	fully enabled model with resource and admission control		fully enabled model with resource and admission control
	coordination.		coordination.
			Multicasting January, 2009
	Table of Contents		Table of Contents
	1. INTRODUCTION 4		1. INTRODUCTION..................................................4
	1.1 PURPOSE AND BACKGROUND 4		1.1 PURPOSE AND BACKGROUND.......................................4
	2. DEFINITIONS AND ABBREVIATIONS 5		2. DEFINITIONS AND ABBREVIATIONS.................................5
	2.1 DEFINITIONS 5		2.1 DEFINITIONS..................................................5
	2.2 ABBREVIATIONS 6		2.2 ABBREVIATIONS................................................6
	3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS 7		3. COMMON USE MODELS AND NETWORK ARCHITECTURE IMPLICATIONS.......7
	4. FRAMEWORK AND ROLES OF ENTITIES 9		4. FRAMEWORK AND ROLES OF ENTITIES...............................9
	4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS 9		4.1 "AAA FRAMEWORK IN MULTICAST-ENABLED ENVIRONMENTS.............9
	4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS 9		4.1.1 MULTIPLE CPS ARE CONNECTED TO MULTIPLE NSPS................9
	4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP 11		4.1.2 MULTIPLE CPS ARE CONNECTED TO A SINGLE NSP................11
	4.1.3 A SINGLE CP IS CONNECTED TO MULTIPLE NSPS 11		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.1.4 A SINGLE CP IS CONNECTED TO SINGLE NSP....................11
	4.2 USER ID 12		4.2 USER ID.....................................................12
	4.2.1 CP-ASSIGNED USER ID 12		4.2.1 CP-ASSIGNED USER ID.......................................12
	4.2.2 NSP-ASSIGNED USER ID 12		4.2.2 NSP-ASSIGNED USER ID......................................12
	4.3 ACCOUNTING 13		4.3 ACCOUNTING..................................................13
	4.4 ACCESS CONTROL AND CP SELECTION BY NSP 14		4.4 ACCESS CONTROL AND CP SELECTION BY NSP......................14
	4.5 ADMISSION CONTROL INFORMATION BY NSP 14		4.5 ADMISSION CONTROL INFORMATION BY NSP........................14
	4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP 15		4.6 ACCESS CONTROL AND DISTINGUISHING OF USERS BY CP............15
			4.7 AAA PROXY IN NSP............................................15
			5.1 BASIC CONNECTION MODEL......................................16
			5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY
			ENABLED AAA FRAMEWORK...........................................17
			5.3 MODULARITY OF THE FRAMEWORK.................................21
			6. IANA CONSIDERATIONS..........................................21
			7. SECURITY CONSIDERATIONS......................................21
			8. CONCLUSION...................................................21
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	4.7 AAA PROXY IN NSP 15
	5.1 BASIC CONNECTION MODEL 16
	5.2 CONSTITUENT LOGICAL FUNCTIONAL COMPONENTS OF THE FULLY
	ENABLED AAA FRAMEWORK 17
	5.3 MODULARITY OF THE FRAMEWORK 21
	6. IANA CONSIDERATIONS 21
	7. SECURITY CONSIDERATIONS 21
	8. CONCLUSION 21
	1. Introduction		1. Introduction
	1.1 Purpose and Background		1.1 Purpose and Background
	IP multicasting is designed to serve cases of group		IP multicasting is designed to serve cases of group
	communication schemes of any kind, such as one-to-many		communication schemes of any kind, such as one-to-many
	(case of TV broadcasting services for example) or many-to-		(case of TV broadcasting services for example) or many-to-
	many (case of videoconferencing services, for example).		many (case of videoconferencing services, for example).
	skipping to change at page 5, line 6		skipping to change at page 5, line 6
	and content providers to identify (if not authenticate,		and content providers to identify (if not authenticate,
	especially within the context of enforcing electronic		especially within the context of enforcing electronic
	payment schemes) and to invoice such customers in a		payment schemes) and to invoice such customers in a
	reliable and efficient manner. Solutions should consider a		reliable and efficient manner. Solutions should consider a
	wide range of possible content delivery applications:		wide range of possible content delivery applications:
	content delivered over the multicast network may include		content delivered over the multicast network may include
	video, audio, images, games, software and information such		video, audio, images, games, software and information such
	as financial data, etc.		as financial data, etc.
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	This memo describes a framework for specifying the		This memo describes a framework for specifying the
	Authorization, Authentication and Accounting (AAA)		Authorization, Authentication and Accounting (AAA)
	capabilities that could be activated within the context of		capabilities that could be activated within the context of
	the deployment and the operation of IP multicast-based		the deployment and the operation of IP multicast-based
	services. This memo also describes a framework to realize		services. This memo also describes a framework to realize
	high-quality multicast transport using a Multicast		high-quality multicast transport using a Multicast
	Admission Control Function (MACF) with multicast		Admission Control Function (MACF) with multicast
	Authorization.		Authorization.
	skipping to change at page 6, line 6		skipping to change at page 6, line 6
	investigating the applicability of existing AAA protocols		investigating the applicability of existing AAA protocols
	to provide these AAA capabilities in IP multicast specific		to provide these AAA capabilities in IP multicast specific
	context and/or if deemed necessary, the refining or		context and/or if deemed necessary, the refining or
	defining of protocols to provide these capabilities.		defining of protocols to provide these capabilities.
	2. Definitions and Abbreviations		2. Definitions and Abbreviations
	2.1 Definitions		2.1 Definitions
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	For the purpose of this memo the following definitions		For the purpose of this memo the following definitions
	apply:		apply:
	Accounting: The set of capabilities that allow the		Accounting: The set of capabilities that allow the
	retrieval of a set of statistical data that can be defined		retrieval of a set of statistical data that can be defined
	on a per customer and/or a per service basis, within the		on a per customer and/or a per service basis, within the
	context of the deployment of multicast-based services. Such		context of the deployment of multicast-based services. Such
	data are retrieved for billing purposes, and can be		data are retrieved for billing purposes, and can be
	retrieved on a regular basis or upon unsolicited requests.		retrieved on a regular basis or upon unsolicited requests.
	skipping to change at page 7, line 6		skipping to change at page 7, line 6
	2.2 Abbreviations		2.2 Abbreviations
	For the purpose of this draft the following abbreviations		For the purpose of this draft the following abbreviations
	apply:		apply:
	AAA: Authentication.Authorization.and Accounting		AAA: Authentication.Authorization.and Accounting
	ACL: Access Control List		ACL: Access Control List
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	AN: Access Node		AN: Access Node
	CDN: Content Delivery Network		CDN: Content Delivery Network
	CDS: Content Delivery Services		CDS: Content Delivery Services
	CP: Content Provider		CP: Content Provider
	CP-AAA: Authentication, Authorization, and Accounting		CP-AAA: Authentication, Authorization, and Accounting
	skipping to change at page 8, line 6		skipping to change at page 8, line 6
	provision roles are divided between separate entities.		provision roles are divided between separate entities.
	Commonly, Content Providers (CP) do not build and maintain		Commonly, Content Providers (CP) do not build and maintain
	their own multicast network infrastructure as this is not		their own multicast network infrastructure as this is not
	their primary business area. CP often purchase transport		their primary business area. CP often purchase transport
	and management services from network service providers		and management services from network service providers
	instead. Similarly Network Service Providers (NSP) may not		instead. Similarly Network Service Providers (NSP) may not
	make their business in providing content. [I-D.mboned-		make their business in providing content. [I-D.mboned-
	maccnt-req] provides more detail of the multiple versus		maccnt-req] provides more detail of the multiple versus
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	single-entity Content Delivery Service (CDS) network		single-entity Content Delivery Service (CDS) network
	models.		models.
	In the usage model where a single NSP provides multicast		In the usage model where a single NSP provides multicast
	services to multiple CPs, the following general		services to multiple CPs, the following general
	requirements from [I-D.mboned-maccnt-req] apply:		requirements from [I-D.mboned-maccnt-req] apply:
	-Need for user tracking and billing capabilities		-Need for user tracking and billing capabilities
	-Need for QoS control such as resource management and		-Need for QoS control such as resource management and
	skipping to change at page 9, line 6		skipping to change at page 9, line 6
	CP to make the above two possible		CP to make the above two possible
	When the NSP and CP are the same single entity then the		When the NSP and CP are the same single entity then the
	general requirements are as follows.		general requirements are as follows.
	-Need for user tracking and user-billing capabilities		-Need for user tracking and user-billing capabilities
	-Need for access control and/or content protection at		-Need for access control and/or content protection at
	level the entity deems appropriate		level the entity deems appropriate
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	4. Framework and Roles of Entities		4. Framework and Roles of Entities
	4.1 AAA Framework in Multicast-Enabled Environments		4.1 AAA Framework in Multicast-Enabled Environments
	A general high-level framework is depicted in Figure 1.		A general high-level framework is depicted in Figure 1.
	+------------------------------+		+------------------------------+
	| user |		| user |
	| |		| |
	skipping to change at page 10, line 6		skipping to change at page 10, line 6
	4.1.1 Multiple CPs are connected to multiple NSPs		4.1.1 Multiple CPs are connected to multiple NSPs
	The user subscribes to multiple NSPs and multiple CPs in		The user subscribes to multiple NSPs and multiple CPs in
	this usage case. The user selects a CP and a NSP when the		this usage case. The user selects a CP and a NSP when the
	user requests content. The NSP may be automatically		user requests content. The NSP may be automatically
	selected by a user terminal: e.g. a fixed line NSP by a set		selected by a user terminal: e.g. a fixed line NSP by a set
	top box or a mobile NSP by a mobile phone. In some usage		top box or a mobile NSP by a mobile phone. In some usage
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	cases it is possible that the NSP used by a certain user		cases it is possible that the NSP used by a certain user
	will not always be the same. For example a user may have		will not always be the same. For example a user may have
	contracted with more than one NSP: one for fixed line		contracted with more than one NSP: one for fixed line
	access and another for mobile roaming access.		access and another for mobile roaming access.
	The content may be associated with (or managed by) a		The content may be associated with (or managed by) a
	specific CP. In this case, when the user selects content,		specific CP. In this case, when the user selects content,
	the CP is automatically selected.		the CP is automatically selected.
	skipping to change at page 11, line 6		skipping to change at page 11, line 6
	A CP receives an inquiry from the NSP. The CP authenticates		A CP receives an inquiry from the NSP. The CP authenticates
	the NSP's identity and makes an authorization decision		the NSP's identity and makes an authorization decision
	regarding the user's eligibility to access the requested		regarding the user's eligibility to access the requested
	contents. The CP is responsible for the authentication		contents. The CP is responsible for the authentication
	and authorization of users so that they can access the		and authorization of users so that they can access the
	content managed by the CP. The CP notifies the NSP		content managed by the CP. The CP notifies the NSP
	accordingly. When the CP cannot (e.g. error or resource		accordingly. When the CP cannot (e.g. error or resource
	issues) or decides not (e.g. policy issues) to deliver		issues) or decides not (e.g. policy issues) to deliver
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	content, the CP is responsible for notifying the NSP about		content, the CP is responsible for notifying the NSP about
	the reason. It is up to the NSP to relay or translate the		the reason. It is up to the NSP to relay or translate the
	reasons for rejection to the user.		reasons for rejection to the user.
	A CP may delegate AAA responsibility to a NSP. 'AAA proxy		A CP may delegate AAA responsibility to a NSP. 'AAA proxy
	in NSP' is described in 4.7 for this case.		in NSP' is described in 4.7 for this case.
	As defined in [I-D.mboned-maccnt-req], the CP may require		As defined in [I-D.mboned-maccnt-req], the CP may require
	the retrieval of accounting information related to the		the retrieval of accounting information related to the
	skipping to change at page 12, line 6		skipping to change at page 12, line 6
	The role of the CP is the same as that described in 4.1.1.		The role of the CP is the same as that described in 4.1.1.
	4.1.4 A single CP is connected to single NSP		4.1.4 A single CP is connected to single NSP
	In this case, a user subscribes to only one NSP and one CP.		In this case, a user subscribes to only one NSP and one CP.
	The user does not select a NSP and CP in this scenario.		The user does not select a NSP and CP in this scenario.
	Requests for multicast sent by the user to a selected NSP		Requests for multicast sent by the user to a selected NSP
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	should include enough information not only for		should include enough information not only for
	authentication by the CP but also for admission control by		authentication by the CP but also for admission control by
	the NSP.		the NSP.
	The role for the NSP is the same as 4.1.3		The role for the NSP is the same as 4.1.3
	The role of the CP is the same as the description in 4.1.1.		The role of the CP is the same as the description in 4.1.1.
	The NSP and CP could be the same entity. In this case, the		The NSP and CP could be the same entity. In this case, the
	roles of the NSP and CP may be combined.		roles of the NSP and CP may be combined.
	skipping to change at page 13, line 6		skipping to change at page 13, line 6
	NSPs assign user IDs to their users. A user may have more		NSPs assign user IDs to their users. A user may have more
	than one NSP-assigned user ID per a specific NSP. A user		than one NSP-assigned user ID per a specific NSP. A user
	requests for multicast to a NSP, the NSP-assigned user ID		requests for multicast to a NSP, the NSP-assigned user ID
	may be indicated in the request so that the NSP can		may be indicated in the request so that the NSP can
	identify the user. The NSP should not inform the NSP-		identify the user. The NSP should not inform the NSP-
	assigned user ID to the CP for security reasons. The NSP		assigned user ID to the CP for security reasons. The NSP
	may identify the multicast-access user by other methods		may identify the multicast-access user by other methods
	than the NSP-assigned userID, e.g. by the access port.		than the NSP-assigned userID, e.g. by the access port.
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	The actual mapping rules for NSP-assigned user IDs with CP-		The actual mapping rules for NSP-assigned user IDs with CP-
	user assigned IDs in account logs is a matter for the		user assigned IDs in account logs is a matter for the
	providers and out of the scope of this framework.		providers and out of the scope of this framework.
	4.3 Accounting		4.3 Accounting
	There are some accounting issues specific to multicasting.		There are some accounting issues specific to multicasting.
	An (S,G) should be recorded as a channel identifier. The		An (S,G) should be recorded as a channel identifier. The
	last hop device, such as an IGMP or MLD router or an IGMP		last hop device, such as an IGMP or MLD router or an IGMP
	skipping to change at page 14, line 6		skipping to change at page 14, line 6
	accounting messages of either level.		accounting messages of either level.
	The level of account report messaging between the NSP and		The level of account report messaging between the NSP and
	CP may be either configured statically or can be		CP may be either configured statically or can be
	dynamically requested by the CP in its response to the		dynamically requested by the CP in its response to the
	Access-Request relayed by the NSP to the CP. The		Access-Request relayed by the NSP to the CP. The
	determination of the actual level of report messaging is		determination of the actual level of report messaging is
	configured by the NSP at the NAS.		configured by the NSP at the NAS.
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	In case of very fast channel changes, the amount of items		In case of very fast channel changes, the amount of items
	logged by the NSP could become high. In order to reduce		logged by the NSP could become high. In order to reduce
	the number of report messages sent to the CP, the NSP can		the number of report messages sent to the CP, the NSP can
	consolidate multiple sets of accounting information inside		consolidate multiple sets of accounting information inside
	a single accounting report message. [I-D.ancp-framework]		a single accounting report message. [I-D.ancp-framework]
	4.4 Access Control and CP selection by NSP		4.4 Access Control and CP selection by NSP
	When a NSP receives an access request from a user, the NSP		When a NSP receives an access request from a user, the NSP
	skipping to change at page 15, line 6		skipping to change at page 15, line 6
	network resources for the requested multicast traffic,		network resources for the requested multicast traffic,
	streaming the requested multicast traffic as best-effort is		streaming the requested multicast traffic as best-effort is
	optional. The user may indicate in his/her Access		optional. The user may indicate in his/her Access
	Request whether he/she will accept best-effort grade		Request whether he/she will accept best-effort grade
	streaming if guaranteed class is not available. The CP's		streaming if guaranteed class is not available. The CP's
	preference for accepting downgrading to best-effort		preference for accepting downgrading to best-effort
	streaming may be either configured statically or can be		streaming may be either configured statically or can be
	dynamically requested by the CP in its response to the		dynamically requested by the CP in its response to the
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	Access-Request relayed by the NSP to the CP. In the case		Access-Request relayed by the NSP to the CP. In the case
	that it cannot be offered a guaranteed QoS stream, the NSP		that it cannot be offered a guaranteed QoS stream, the NSP
	may decide either to decline admission or to stream the		may decide either to decline admission or to stream the
	requested multicast traffic as best-effort. The NSP should		requested multicast traffic as best-effort. The NSP should
	not stream best-effort traffic if either the user or CP has		not stream best-effort traffic if either the user or CP has
	indicated against best-effort provision.		indicated against best-effort provision.
	A NSP's admission control may manage integrated network		A NSP's admission control may manage integrated network
	resources for unicast usage, such as VoIP or unicast		resources for unicast usage, such as VoIP or unicast
	skipping to change at page 16, line 6		skipping to change at page 16, line 6
	or channel(s).		or channel(s).
	When a user is receiving multicast traffic while the		When a user is receiving multicast traffic while the
	permission is about to expire, the NSP may send a		permission is about to expire, the NSP may send a
	notification to the user client that his session is about		notification to the user client that his session is about
	to expire, and that he will need to re-authenticate. In		to expire, and that he will need to re-authenticate. In
	such a case, the user will have to send the Access-Request.		such a case, the user will have to send the Access-Request.
	In the case that the user still has permission to the		In the case that the user still has permission to the
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	content, they should be able to continue to receive the		content, they should be able to continue to receive the
	multicast traffic without interruption.		multicast traffic without interruption.
	When re-authentication fails, the NSP should stop the		When re-authentication fails, the NSP should stop the
	multicast traffic and record accounting stop.		multicast traffic and record accounting stop.
	5. Network Connection Model and Functional Components		5. Network Connection Model and Functional Components
	Section 3.1 introduced the high-level AAA framework for		Section 3.1 introduced the high-level AAA framework for
	skipping to change at page 17, line 6		skipping to change at page 17, line 6
	NSP which may then forward a mAAA request towards the		NSP which may then forward a mAAA request towards the
	appropriate CP for authentication and authorization		appropriate CP for authentication and authorization
	purposes. The receiver gets information about a given		purposes. The receiver gets information about a given
	multicast group (*,G) or channel (S,G) corresponding to the		multicast group (*,G) or channel (S,G) corresponding to the
	content beforehand for generating the request. The CP		content beforehand for generating the request. The CP
	responds with either "success" or "failure". If "success",		responds with either "success" or "failure". If "success",
	the NSP grants access to the receiver and forwards		the NSP grants access to the receiver and forwards
	multicast traffic accordingly.		multicast traffic accordingly.
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	In this model the receiver selects the NSP to which the		In this model the receiver selects the NSP to which the
	Join request will be sent. Based on this request the NSP		Join request will be sent. Based on this request the NSP
	selects an appropriate CP to which it forwards the		selects an appropriate CP to which it forwards the
	corresponding mAAA request. The CP responds to the NSP's m		corresponding mAAA request. The CP responds to the NSP's m
	AAA request: it may not respond to another NSP in regards		AAA request: it may not respond to another NSP in regards
	to the request.		to the request.
	In this model, as described in section 4.1, the		In this model, as described in section 4.1, the
	relationship between NSP and CP can be one-to-one, one-to-		relationship between NSP and CP can be one-to-one, one-to-
	skipping to change at page 18, line 6		skipping to change at page 18, line 6
	models within the framework: "AAA enabled" multicasting and		models within the framework: "AAA enabled" multicasting and
	"Fully enabled AAA" multicasting which means "AAA enabled"		"Fully enabled AAA" multicasting which means "AAA enabled"
	with added admission control functions.		with added admission control functions.
	Section 3.1 introduces the high-level AAA framework for		Section 3.1 introduces the high-level AAA framework for
	multicasting. Below is a diagram of a AAA enabled		multicasting. Below is a diagram of a AAA enabled
	multicasting network with AAA, including the logical		multicasting network with AAA, including the logical
	components within the various entities.		components within the various entities.
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	|| CPE ||		|| CPE ||
	|| ||		|| ||
	|+- - - - - | - - - - - - - - -+|		|+- - - - - | - - - - - - - - -+|
	+-----------|-------------------+		+-----------|-------------------+
	|		|
	-------|------ IFa		-------|------ IFa
	skipping to change at page 19, line 6		skipping to change at page 19, line 6
	includes the transport system and a logical element for		includes the transport system and a logical element for
	multicast AAA functionality. The TS (transport system) is		multicast AAA functionality. The TS (transport system) is
	comprised of the access node and NAS (Network Access		comprised of the access node and NAS (Network Access
	Server) An AN (Access Node) may be connected directly to		Server) An AN (Access Node) may be connected directly to
	mAAA or a NAS relays AAA information between an AN and a		mAAA or a NAS relays AAA information between an AN and a
	mAAA. Descriptions of AN and its interfaces are out of the		mAAA. Descriptions of AN and its interfaces are out of the
	scope for this memo. The multicast AAA function may be		scope for this memo. The multicast AAA function may be
	provided by a mAAA which may include the function that		provided by a mAAA which may include the function that
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	downloads Join access control lists to the NAS (this		downloads Join access control lists to the NAS (this
	function is referred to conditional access policy control		function is referred to conditional access policy control
	function.)		function.)
	Interface between mAAA and NAS		Interface between mAAA and NAS
	The interface between mAAA and the NAS is labeled IFb in		The interface between mAAA and the NAS is labeled IFb in
	Figure 2. Over IFb the NAS sends an access request to the		Figure 2. Over IFb the NAS sends an access request to the
	NSP-mAAA and the mAAA replies. The mAAA may push		NSP-mAAA and the mAAA replies. The mAAA may push
	skipping to change at page 20, line 6		skipping to change at page 20, line 6
	multicast traffic depending on the NSP and CP's policy		multicast traffic depending on the NSP and CP's policy
	decisions.		decisions.
	Interface between NSP and CP		Interface between NSP and CP
	The interface between the NSP and CP is labeled IFc. Over		The interface between the NSP and CP is labeled IFc. Over
	IFc the NSP requests to the CP-AAA for access to contents		IFc the NSP requests to the CP-AAA for access to contents
	and the CP replies. CP may also send conditional access		and the CP replies. CP may also send conditional access
	policy over this interface for AAA-proxying.		policy over this interface for AAA-proxying.
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	|| CPE ||		|| CPE ||
	|| ||		|| ||
	|+- - - - - | - - - - - - - - -+|		|+- - - - - | - - - - - - - - -+|
	+-----------|-------------------+		+-----------|-------------------+
	|		|
	-------|------ IFa		-------|------ IFa
	skipping to change at page 21, line 6		skipping to change at page 21, line 6
	provided by MACF (Multicast Admission Control Function).		provided by MACF (Multicast Admission Control Function).
	This means that, before replying to the user's multicast		This means that, before replying to the user's multicast
	request, the mAAA queries the MACF for a network resource		request, the mAAA queries the MACF for a network resource
	access decision over the interface IFd. The MACF is		access decision over the interface IFd. The MACF is
	responsible for allocating network resources for forwarding		responsible for allocating network resources for forwarding
	multicast traffic. MACF also receives Leave information		multicast traffic. MACF also receives Leave information
	from NAS so that MACF releases corresponding reserved		from NAS so that MACF releases corresponding reserved
	resources.		resources.
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	5.3 Modularity of the framework		5.3 Modularity of the framework
	In the interest of flexibility, this framework is modular		In the interest of flexibility, this framework is modular
	so that it is possible that partially enabled versions of		so that it is possible that partially enabled versions of
	the models are supported. A AAA-enabled version provides		the models are supported. A AAA-enabled version provides
	AAA functionality without Network Resource management. A		AAA functionality without Network Resource management. A
	Network-Resource-Management-enabled (QoS-enabled) version		Network-Resource-Management-enabled (QoS-enabled) version
	provides Network Resource management without AAA		provides Network Resource management without AAA
	functionality. Similarly, the possibility of one or more		functionality. Similarly, the possibility of one or more
	skipping to change at page 21, line 48		skipping to change at page 21, line 48
	done to specify the interfaces between the user and NSP,		done to specify the interfaces between the user and NSP,
	NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA		NAS and mAAA, mAAA and MACF and NSP-mAAA and CP-AAA
	(presented in 5.2.)		(presented in 5.2.)
	Normative References		Normative References
	[I-D.mboned-maccnt-req]		[I-D.mboned-maccnt-req]
	Hayashi, et. al., "Requirements for Multicast AAA		Hayashi, et. al., "Requirements for Multicast AAA
	coordinated between Content Provider(s) and Network		coordinated between Content Provider(s) and Network
	Service Provider(s)", draft-ietf-mboned-maccnt-req-		Service Provider(s)", draft-ietf-mboned-maccnt-req-
	06.txt, June 2008, Work in Progress.		07.txt, January 2009, Work in Progress.
	[I-D.ancp-framework]		[I-D.ancp-framework]
	Ooghe, et. al, "Framework and Requirements for an		Ooghe, et. al, "Framework and Requirements for an
	Access Node Control Mechanism in Broadband Multi-		Access Node Control Mechanism in Broadband Multi-
	Internet Draft AAA and Admission Control Framework for		Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008		Multicasting January, 2009
	Service Networks", draft-ietf-ancp-framework-04.txt,		Service Networks", draft-ietf-ancp-framework-07.txt,
	November 2007, Work in Progress.		November 2008, Work in Progress.
	Authors' Addresses		Authors' Addresses
	Hiroaki Satou		Hiroaki Satou
	NTT Network Service Systems Laboratories		NTT Network Service Systems Laboratories
	3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585		3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585
	Japan		Japan
	Phone : +81 422 59 4683		Phone : +81 422 59 4683
	Email : satou.hiroaki@lab.ntt.co.jp		Email : satou.hiroaki@lab.ntt.co.jp
	skipping to change at page 22, line 47		skipping to change at line 997
	Japan		Japan
	Phone: +81 46 859 8790		Phone: +81 46 859 8790
	Email: tsunemasa@gmail.com		Email: tsunemasa@gmail.com
	Haixiang He		Haixiang He
	Nortel		Nortel
	600 Technology Park Drive		600 Technology Park Drive
	Billerica, MA 01801, USA		Billerica, MA 01801, USA
	Phone: +1 978 288 7482		Phone: +1 978 288 7482
	Email: haixiang@nortel.com		Email: haixiang@nortel.com
	Comments
	Comments are solicited and should be addressed to the
	mboned working group's mailing list at
	mboned@lists.uoregon.edu_and/or the authors.
	Internet Draft AAA and Admission Control Framework for
	Multicasting July, 2008
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	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.
	This document and the information contained herein are
	provided on an "AS IS" basis and THE CONTRIBUTOR, THE
	ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
	THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET
	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.
	Intellectual Property
	The IETF takes no position regarding the validity or scope
	of any 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 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.
	The IETF invites any interested party to bring to its
	attention any copyrights, patents or patent applications,
	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.
	Expiration
	This Internet-Draft will expire on January 3, 2009.
	Acknowledgement
	Funding for the RFC Editor function is currently provided
	by the Internet Society.
End of changes. 31 change blocks.
	73 lines changed or deleted		70 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/