draft-ietf-mboned-maccnt-req-09.txt		draft-ietf-mboned-maccnt-req-10.txt
	mboned T. Hayashi,		mboned T. Hayashi,
	Internet-Draft H. Satou,		Internet-Draft H. Satou,
	Intended status: Informational H. Ohta		Intended status: Informational H. Ohta
	Expires: September 6, 2010 NTT		Expires: February 25, 2011 NTT
	H.He		H.He
	Nortel		Nortel
	S. Vaidya		S. Vaidya
	Cisco Systems, Inc.		Cisco Systems, Inc.
	March 5, 2010		August 24, 2010
	Requirements for Multicast AAA coordinated between Content Provider(s)		Requirements for Multicast AAA coordinated between Content Provider(s)
	and Network Service Provider(s)		and Network Service Provider(s)
	draft-ietf-mboned-maccnt-req-09		draft-ietf-mboned-maccnt-req-10
	Abstract		Abstract
	This memo presents requirements in the area of accounting and access		This memo presents requirements in the area of accounting and access
	control for IP multicasting. The scope of the requirements is		control for IP multicasting. The scope of the requirements is
	limited to cases where Authentication, Authorization and Accounting		limited to cases where Authentication, Accounting and Authorization
	(AAA) functions are coordinated between Content Provider(s) and		(AAA) functions are coordinated between Content Provider(s) and
	Network Service Provider(s).		Network Service Provider(s).
	In order to describe the new requirements of a multi-entity Content		In order to describe the new requirements of a multi-entity Content
	Delivery Service(CDS) using multicast, the memo presents three basic		Deliver System(CDS) using multicast, the memo presents three basic
	business models: 1) the Content Provider and the Network Provider are		business models: 1) the Content Provider and the Network Provider are
	the same entity, 2) the Content Provider(s) and the Network		the same entity, 2) the Content Provider(s) and the Network
	Provider(s) are separate entities and users are not directly billed,		Provider(s) are separate entities and users are not directly billed,
	and 3) the Content Provider(s) and the Network Provider(s) are		and 3) the Content Provider(s) and the Network Provider(s) are
	separate entities and users are billed based on content consumption		separate entities and users are billed based on content consumption
	or subscriptions. The requirements of these three models are listed		or subscriptions. The requirements of these three models are listed
	and evaluated as to which aspects are already supported by existing		and evaluated as to which aspects are already supported by existing
	technologies and which aspects are not.		technologies and which aspects are not.
	General requirements for accounting and admission control		General requirements for accounting and admission control
	skipping to change at page 2, line 23		skipping to change at page 2, line 23
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		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 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 accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 6, 2010.		This Internet-Draft will expire on February 25, 2011.
	1. Introduction		1. Introduction
	Broadband access networks such as ADSL (Asymmetric Digital Subscriber		Broadband access networks such as ADSL (Asymmetric Digital Subscriber
	Line) or FTTH (Fiber to the Home) have been deployed widely in recent		Line) or FTTH (Fiber to the Home) have been deployed widely in recent
	years. Content Delivery Service (CDS) is expected to be a major		years. Content Delivery Service (CDS) is expected to be a major
	application provided through broadband access networks. Because many		application provided through broadband access networks. Because many
	services such as television broadcasting require huge bandwidth		services such as television broadcasting require huge bandwidth
	(e.g., 6Mbit/s) and processing power at the content server(s), IP		(e.g., 6Mbit/s) and processing power at the content server(s), IP
	multicast is used as an efficient delivery mechanism for CDS.		multicast is used as an efficient delivery mechanism for CDS.
	skipping to change at page 4, line 15		skipping to change at page 4, line 15
	User: In this document user refers to a requester and a recipient		User: In this document user refers to a requester and a recipient
	of multicast data, termed a viewer in CDS.		of multicast data, termed a viewer in CDS.
	User-based accounting: actions for grasping each user's behavior,		User-based accounting: actions for grasping each user's behavior,
	when she/he starts/stops to receive a channel, which channel		when she/he starts/stops to receive a channel, which channel
	she/he receives, etc.		she/he receives, etc.
	2.2. Abbreviations		2.2. Abbreviations
	AAA: Authentication, Authorization and Accounting		AAA: Authentication, Accounting and Authorization
	ASM: Any-Source Multicast		ASM: Any-Source Multicast
	CDS: Content Delivery Service		CDS: Content Delivery Service
	CP: Content Provider		CP: Content Provider
	IGMP: Internet Group Management Protocol		IGMP: Internet Group Management Protocol
	MLD: Multicast Listener Discovery		MLD: Multicast Listener Discovery
	skipping to change at page 10, line 7		skipping to change at page 10, line 7
	accepted if delivery of the requested stream would push the consumed		accepted if delivery of the requested stream would push the consumed
	bandwidth over the NSP policy-defined limit.		bandwidth over the NSP policy-defined limit.
	The network may need to control the combined bandwidth for all		The network may need to control the combined bandwidth for all
	channels at the physical port of the edge router or switch so that		channels at the physical port of the edge router or switch so that
	these given physical entities are not overflowed with traffic. This		these given physical entities are not overflowed with traffic. This
	entails being able to control the number of channels delivered, the		entails being able to control the number of channels delivered, the
	bandwidth for each channel and the combined bandwidth for all		bandwidth for each channel and the combined bandwidth for all
	channels.		channels.
	6. Reauthorization and deauthorization requirements		6. Reauthorization/ deauthorization requirements
	A mechanism for periodic reauthorization of users who have already		A mechanism for periodic reauthorization of users who have already
	joined a channel stream should be supported. The reauthorization		joined a channel stream should be supported. The reauthorization
	could be an authorization check based on the NSP's eligibility		could be an authorization check based on the NSP's eligibility
	requirements and/or could involve the NSP querying the CP for		requirements and/or could involve the NSP querying the CP for
	reauthorization of a user.		reauthorization of a user.
	A mechanism for deauthorization should be supported for cases in		A mechanism for deauthorization should be supported for cases in
	which a user is deemed ineligible by the NSP and/or CP at the time of		which a user is deemed ineligible by the NSP and/or CP at the time of
	a reauthorization check. If a NSP revokes authorization for the		a reauthorization check. If a NSP revokes authorization for the
	network for a user it should force a leave, and record details of the		network for a user it should force a leave, and record details of the
	leave (including the time and reason for the forced leave.) If a CP		leave (including the time and reason for the forced leave.) If a CP
	revokes authorization to content for a user the CP signals to the NSP		revokes authorization to content for a user the CP signals to the NSP
	to cease streaming to that user. An example usage case for		to cease streaming to that user. An example usage case for
	deauthorizing a user is one where a user has a subscription or has		deauthorizing a user is one where a user has a subscription or has
	paid for a certain amount of content and has reached that limit. In		paid for a certain amount of content and has reached that limit. In
	some models, it is conceivable that a CP could communicate the		some models, it is conceivable that a CP could communicate the
	parameters for de-authorization to the NSP at the time of the		parameters for de-authorization to the NSP at the time of the
	original join's authorization so as to make NSP to CP reauthorization		original join's authorization so as to make NSP->CP reauthorization
	requests unnecessary.		requests unnecessary.
	7. Performance requirements		7. Performance requirements
	Channel Join Latency and Leave Latency		Channel Join Latency and Leave Latency
	Commercial implementations of IP multicasting are likely to have		Commercial implementations of IP multicasting are likely to have
	strict requirements in terms of user experience. Join latency is the		strict requirements in terms of user experience. Join latency is the
	time between when a user sends a "join" request and when the		time between when a user sends a "join" request and when the
	requested data streaming first reaches the user. Leave latency is		requested data streaming first reaches the user. Leave latency is
End of changes. 9 change blocks.
	9 lines changed or deleted		9 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/