draft-ietf-mboned-maccnt-req-07.txt		draft-ietf-mboned-maccnt-req-08.txt
	Tsunemasa Hayashi, NTT		mboned T. Hayashi
	Internet Draft Haixiang He, Nortel		Internet-Draft NTT Network Innovation
	Document:draft-ietf-mboned-maccnt-req-07.txt Hiroaki Satou, NTT		Intended status: Informational Laboratories
	Intended Status: Informational Hiroshi Ohta, NTT		Expires: January 14, 2010 H. He
	Expires: July 16, 2009 Susheela Vaidya, Cisco Systems		Nortel
			H. Satou
	January 12, 2009		H. Ohta
			NTT Network Service Systems
			Laboratories
			S. Vaidya
			Cisco Systems, Inc.
			July 13, 2009
	Requirements for Multicast AAA coordinated between Content		Requirements for Multicast AAA coordinated between Content Provider(s)
	Provider(s) and Network Service Provider(s) <draft-ietf-mboned-		and Network Service Provider(s)
	maccnt-req-07.txt>		draft-ietf-mboned-maccnt-req-08
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with
	the provisions of BCP 78 and BCP 79.		This Internet-Draft is submitted to IETF in full conformance with the
			provisions of BCP 78 and BCP 79. This document may contain material
			from IETF Documents or IETF Contributions published or made publicly
			available before November 10, 2008. The person(s) controlling the
			copyright in some of this material may not have granted the IETF
			Trust the right to allow modifications of such material outside the
			IETF Standards Process. Without obtaining an adequate license from
			the person(s) controlling the copyright in such materials, this
			document may not be modified outside the IETF Standards Process, and
			derivative works of it may not be created outside the IETF Standards
			Process, except to format it for publication as an RFC or to
			translate it into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months and may be updated, replaced, or obsoleted by other		and may be updated, replaced, or obsoleted by other documents at any
	documents at any time. It is inappropriate to use Internet-Drafts		time. It is inappropriate to use Internet-Drafts as reference
	as reference material or to cite them other than as "work in		material or to cite them other than as "work in progress."
	progress."
	The list of current Internet-Drafts can be accessed 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 July 16, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents in effect on the date of
	(http://trustee.ietf.org/license-info) in effect on the date of		publication of this document (http://trustee.ietf.org/license-info).
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with		and restrictions with respect to this document.
	respect to this document.
	Abstract		Abstract
	This memo presents requirements in the area of accounting and		This memo presents requirements in the area of accounting and access
	access control for IP multicasting. The scope of the		control for IP multicasting. The scope of the requirements is
	requirements is limited to cases that Authentication,		limited to cases where Authentication, Accounting and Authorization
	Accounting and Authorization (AAA) functions are coordinated		(AAA) functions are coordinated between Content Provider(s) and
	between Content Provider(s) and Network Service Provider(s).		Network Service Provider(s).
	General requirements for accounting and admission control
	capabilities including quality-of-service (QoS) related issues
	are listed. This memo assumes that these capabilities can be
	realized by functions implemented at edges of a network based
	on IGMP or MLD. Finally, cases for Content Delivery Services
	(CDS) are described as application examples which could benefit
	from multicasting accounting and access control capabilities as
	described in this memo.
	This memo defines requirements related to AAA issues for multi-		In order to describe the new requirements of a multi-entity Content
	entity provider models in which the network service provider and		Deliver System(CDS) using multicast, the memo presents three basic
	content provider cooperate to provide CDS and various related AAA		business models: 1) the Content Provider and the Network Provider are
	functions for purposes such as protecting and accounting for the		the same entity, 2) the Content Provider(s) and the Network
	access to content and network resources. The requirements are		Provider(s) are separate entities and users are not directly billed,
	generally not relevant to cases in which there is not a reason to		and 3) the Content Provider(s) and the Network Provider(s) are
	share AAA functions between separate entities.		separate entities and users are billed based on content consumption
			or subscriptions. The requirements of these three models are listed
			and evaluated as to which aspects are already supported by existing
			technologies and which aspects are not.
	Table of Contents		General requirements for accounting and admission control
			capabilities including quality-of-service (QoS) related issues are
			listed and the constituent logical functional components are
			presented.
	1. Introduction..................................................3		This memo assumes that the capabilities can be realized by
	2. Definitions and Abbreviations.................................5		integrating AAA functionalities with a multicast CDS system, with
	2.1 Definitions..................................................5		IGMP/MLD at the edge of the network.
	2.2 Abbreviations................................................6
	3. Problem Statement.............................................6
	3.1 Accounting Issues...........................................6
	3.2 Relationship with Secure Multicasting (MSEC)................8
	3.3 Regarding Access Media and User Separation..................8
	4. General AAA-related Functional Requirements for IP Multicasting
	.................................................................9
	5. Application Example and its Specific Requirements............14
	5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP
	are different entities (companies)..............................14
	5.1.1 Network Model for Multicast Content Delivery Service......15
	5.1.2 Content Delivery Service Requirements.....................17
	5.1.2.1 Accounting Requirements.................................17
	5.1.2.2 Authorization Requirements..............................18
	5.1.2.3 Authentication Requirements.............................19
	5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP
	are the same entities (companies)...............................19
	6. Acknowledgments..............................................21
	7. IANA Considerations..........................................21
	8. Security Considerations......................................21
	9. Privacy considerations.......................................21
	10. Conclusion..................................................21
	Normative References............................................22
	Authors' Addresses..............................................23
	1. Introduction		1. Introduction
	This memo presents general functional requirements related to		Broadband access networks such as ADSL (Asymmetric Digital Subscriber
	accounting, access control and admission control issues in IP		Line) or FTTH (Fiber to the Home) have been deployed widely in recent
	multicasting networks. A multicast network which fulfills all of		years. Content Delivery Service (CDS) is expected to be a major
	these requirements is called a "fully AAA and QoS enabled" IP		application provided through broadband access networks. Because many
	multicasting network here. Fulfillment of all or some of the		services such as television broadcasting require huge bandwidth
	requirements will make possible more robust management of IP		(e.g., 6Mbit/s) and processing power at the content server(s), IP
	multicasting networks.		multicast is used as an efficient delivery mechanism for CDS.
	IP multicasting is becoming widely used as a method to save
	network resources such as bandwidth or CPU processing power of the
	sender's server for cases where a large volume of information
	needs to be distributed to a very large number of receivers at a
	given data speed. This trend can be observed both in enterprise
	use and in broadband services provided by network operator/service
	providers.
	Distance learning within a university and in-house (in-company)
	sharing of multimedia information are examples of enterprise use.
	In these examples, sources generate high-bit rate (e.g., 6Mbit/s)
	streaming information. When the number of receivers becomes large,
	such systems do not scale well without multicasting.
	On the other hand, a content delivery service (CDS) is an example
	of a broadband service provided by network operators/service
	providers. Distribution of movies and other video programs to
	each user is a typical service. Each channel requires large
	bandwidth (e.g., 6Mbit/s) and operator/service providers need to
	provide many channels to make their service attractive. In
	addition, the number of receivers is large (e.g., more than a few
	thousands). A system to provide this service does not scale well
	without multicasting.
	As such, multicasting can be useful to make a network more		A single entity may design and be responsible for a system that
	scalable when a large volume of information needs to be		covers the various common high-level requirements of a multicasting
	distributed to a large number of receivers. However, multicasting		CDS such as 1) content serving, 2) the infrastructure to multicast
	according to current standards (e.g., IGMPv3[1] and MLDv2[2]) has		it, 3) network and content access control mechanisms. For cases in
	drawbacks compared to unicasting when one applies it to commercial		which the business model includes the direct billing of users, the
	services. Accounting of each user's actions is not possible with		single provider of both content and network services has sufficient
	multicasting as it is with unicasting. Accounting consists of		data in its control to bill users based on their content consumption.
	grasping each user's behavior, when she/he starts/stops to receive		Furthermore it is possible to tie access to the network and QoS based
	a channel, which channel she/he receives, etc.		on a user's contract status. Therefore current technologies support
			the single entity case.
	There are limitations to the application of multicasting in usage		Often, however, the content provision and network provision roles are
	models where user-based accounting is necessary, such as is the		split between separate entities. Commonly, Content Providers (CP) do
	case with many commercial applications. These limitations have		not build and maintain their own multicast network infrastructure as
	prevented the widespread deployment of multicasting. Development		this is not their primary business area. Instead, CPs often purchase
	and use of proprietary solutions to address such issues is an		transport and management services from network service providers.
	alternative to providing standardized solutions. However, non-		This memo lists the requirements of a business model in which the NSP
	standard solutions have drawbacks in terms of interoperability or		provides CDS using multicast as one such contractible service.
	cost of development and maintenance.
	Without accounting capability in multicasting, information		The direct revenue source for the multiple entity provider is a
	providers desiring accounting capability are forced to use		defining aspect of the business model which often has implications on
	unicasting even when multicasting would otherwise be desirable		requirements for the technologies that support the system. There are
	from a bandwidth/server resource perspective. If multicasting		cases such as the the advertising-based model where billing end-users
	could be used with user-based accounting capabilities, its		is not done and therefore accounting of content consumption can be
	applicability would be greatly widened.		anonymous and/or in aggegrate. In these cases the requirements of
			the business model for accounting for billing purposes are already
			supported by existing technologies. However, the NSP can not
			guarantee high quality transmission on a per-content basis with
			existing technologies.
	This memo first describes problems on accounting issues in		There is also the business model in which the individual user of
	multicasting. Then the general requirements for this capability		multicasted contents is the source of revenue for both consumed
	including QoS related issues are listed. Finally, application		content and network resources. In this model the NSP wants to
	examples which could benefit from multicasting with accounting		receive the appropriate fees for multicast services and the NSP
	capabilities are shown.		undertakes collecting bills as a proxy for the CPs. The NSP may
			provide high quality service by admission control. Current standards
			do not fully support this model and this memo will list the
			requirements which need to be supported.
	2. Definitions and Abbreviations		2. Definitions and Abbreviations
	2.1 Definitions		2.1. Definitions
	Authentication: action for identifying a user as a genuine one.		Authentication: action for identifying a user as a genuine one.
	Authorization: action for giving permission for a user to access		Authorization: action for giving permission for a user to access
	content or the network.		content or the network.
	Eligible user: Users may be eligible (permitted) to access		Eligible user: Users may be eligible (permitted) to access
	resources because of the attributes they have (e.g., delivery may		resources because of the attributes they have (e.g., delivery may
	require possession of the correct password or digital		require possession of the correct password or digital
	certificate), their equipment has (e.g., content may only be		certificate), their equipment has (e.g., content may only be
	skipping to change at page 6, line 12		skipping to change at page 4, line 32
	countries), and, of course, a mix of attributes may be required		countries), and, of course, a mix of attributes may be required
	for eligibility or ineligibility.		for eligibility or ineligibility.
	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, Accounting and Authorization		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
	NSP: Network Service Provider		NSP: Network Service Provider
	SSM: Source Specific Multicast		SSM: Source Specific Multicast
	QoS: Quality of Service		QoS: Quality of Service
	3. Problem Statement		3. Current Business Models
	3.1 Accounting Issues
	In unicast communications, the server (information source) can
	identify the client (information receiver) and only permits
	connection by an eligible client when this type of access control
	is necessary. In addition, when necessary, the server can grasp
	what the client is doing (e.g., connecting to the server, starting
	reception, what information the client is receiving, terminating
	reception, disconnecting from the server).
	On the other hand, in multicast communication with current
	standards (e.g., IGMPv3[1] or MLDv2[2]) the server just feeds its
	information to the multicast router [as in Fig.1]. Then, the
	multicast router replicates the data to any link which has at
	least one client requesting the information. In this process,
	no eligibility check is conducted. Any client can receive
	information just by requesting it.
	It is envisioned that there are many large-scale content
	distribution applications transferred over IP-based networks that
	can leverage multicasting technologies to meet their scalability
	requirements for clients and data volume, and that some of these
	applications require user-based accounting capabilities similar to
	available with unicast networks. For example, accounting is needed
	if one wants to charge for distributed information on a non-flat-
	fee basis. The current standards do not provide multicasting with
	authorization or access control capabilities sufficient to meet
	the requirements of accounting.
	|--- user ----|------------NSP------------------|-----CP---|
	+--------+		3.1. Single entity model where CP and NSP are the same entity
	| user |\
	+--------+ \
	\+------+ +------+ +------+ +------+
	+--------+ |Multi-| |Multi-| |Multi-| | |
	| user |---|cast |----|cast |----|cast |----|Server|
	+--------+ |router| |router| |router| | |
	/+------+ +------+ +------+ +------+
	+--------+ /
	| user |/
	+--------+
	Fig.1 Example network for multicast communication		One existing business model is that of a single entity responsible
			for both content and network service provision which bills its users
			based on content provision. (See figure below.)
	As such, the same level of user-based accounting capabilities as		+-----------------------------------------------------+
	provided in unicast networks should be provided in multicast		| +---------+ |
	networks.		| | Content | |
			| | Server | |
			| +----+----+ |
			| | |
			| CP+NSP +-------+-------+ |
			| | Provider Edge | |
			| +-------+-------+ |
			| | |
			| | |
			| +-------------+ |
			| | User Edge | |
			| +--+---+---+--+ |
			| / | \ |
			+----------- / --- | --- \ ---------------------------+
			/ | \
			/ | \ <- user/network interface
			/ | \
			+---------++ +-----+----+ ++---------+
			|Client #A | |Client #B | |Client #C |
			+----------+ +----------+ +----------+
			User A User B User C
	3.2 Relationship with Secure Multicasting (MSEC)		Example of CDS network configuration
	In many cases, content encryption (e.g. MSEC) is an effective		Figure 1
	method for preventing unauthorized access to original content (in
	other words, the ability to decode data to return it to its
	generally usable form.) This memo presents requirements for
	multicasting networks in the areas of 1) access control to prevent
	unauthorized usage of network resources (link bandwidth, router's
	processing power, etc.) , and 2) accounting to grasp user activity
	in a NSP. The functional requirements do not require content
	encryption although it might solve some of the content related
	problems. At this point, it is not yet clear whether encryption
	would be part of a solution and if so, what other components (if
	any) would also be required. Multicast streams generally consume
	large amounts of bandwidth for extended periods of time.
	Additionally, some multicast streams may have high-priority
	depending on a NSP's policy. NSP does not want to let ineligible
	users waste large amounts of bandwidth: for example encryption
	protects against content viewing but NSP desires protection
	against DoS attacks of ineligible users wasting network resources,
	even if it is encrypted. Content encryption and multicast access
	control should both be able to coexist for more robust security.
	3.3 Regarding Access Media and User Separation		In this model the network can query a content-policy-enabled AAA
			server within its own domain at the time a user requests content.
			The network can provide the AAA server with information such as user
			identity, device identity, the requested content (channel),
			geographic information, method of network connection, etc. that might
			be required for the content provision authorization decision. It is
			therefore possible to configure a network to deny network access
			based on the content policy decision.
	The requirements defined in this memo apply to solutions that		In this model there are no issues of mapping user identities between
	provide user separation either through physical separation		different entity domains. The provider has access to the information
	provided by dedicated access media between the user and multicast		on which user accessed from which point on what device. Furthermore
	router (see Fig. 1) or else through logical separation in cases		as network provider they can record not only when a user joined or
	of shared physical access media (e.g. using VLAN). However, IP		left a certain channel, but also if packets were actually delivered.
	multicast solutions with shared Layer 2 access media between the		Moreover, there are no inter-entity security and privacy concerns
	user and multicast router and no logical user separation (e.g.		between the CP and NSP.
	Ethernet with shared links and no VLAN) are out of scope of this
	memo. Nevertheless, some of the requirements in this memo defined
	for multicasting may also be relevant to multicasting over links
	without either physical or logical user separation. Therefore in
	the interest of modularity and flexibility, solutions addressing
	the requirements of this memo may also take into account
	application to multicasting without such user separation.
	4. General AAA-related Functional Requirements for IP Multicasting		The single entity network service and content provider also knows the
			content schedules for various channels. This is important not only
			for time and content-sensitive authorization decisions but also for
			providing meaningful billing details to end users.
	In consideration of the issues presented in section 3, the		3.2. Multiple entity model without direct content-based billing
	following requirements have been derived:
	(1) User identification		An additional model for delivering contents over a CDS is the
			advertising-based model where billing end-users is not done. In this
			model the four different roles may be filled by separate entities:
			Content Provider (CP), Network Service Provider (NSP), user clients,
			and advertising sponsors. In the general case of this business
			model, insofar as the advertiser does not require user-based metrics
			the accounting of content consumption can be anonymous and/or in
			aggregrate and can be off-line from the multicast-with-AAA CDS system
			itself. Therefore this model does not require any new standards to
			provide user-based accounting for a multi-entity CDS using multicast
			with AAA. (Providing this data in near real-time and inline would
			entail further requirements which can be dealt with in a separate
			memo if necessary.)
	The network should be able to identify each user when they attempt		A more complex version of this business model is conceivable in which
	to access the service so that necessary access controlling actions		a CP may require a user to enter into a subscription contract, even
	can be applied. Also, it is necessary to identify the user's		when the user does not get billed for content consumption. For
	receiver (e.g. IP address) of each request (e.g., join/leave) for		example, a CP may value individual data because it allows it to
	per host tracking purposes.		supply the advertisers with rich, user-segmented data and charge a
			higher premium. In that case the requirements of the next section
			"CDS with direct billing of the end user" are generally applicable
			because of the need to link the user data which the CP has to the
			actual viewing (or stream downloading) data that the NSP has.
	With current protocols (IGMP/MLD), the sender cannot distinguish		4. Proposed Model: Multity-entity CDS with direct billing of the end
	which receivers (end hosts) are actually receiving the information.		user
	The sender must rely on the information from the multicasting
	routers. This can be complicated if the sender and routers are
	maintained by different entities.
	(2) Issue of Network Resource Protection		In this model the networks for CDS contain three different types of
			entities: Content Provider (CP), Network Service Provider (NSP), and
			user clients. An NSP owns the network resources (infrastructure).
			It accommodates content providers on one side and accommodates user
			clients on the other side. NSP provides the network for CDS to two
			entities (i.e., CPs and user clients). A CP provides content to each
			user through the network of NSPs and charges users for content. NSPs
			are responsible for delivering the content to user clients, and for
			controlling the network resources. A NSP charges a user or a CP for
			network usage. A NSP may charge users for content as a proxy of the
			CP.
	In order to guarantee certain QoS it is important for network		+-------------+ +-------------+ +-------------+
	providers to be able to protect their network resources from being		| CP | | CP | | CP |
	wasted, (either maliciously or accidentally).		| #1 | | #2 | | #3 |
			| +---------+ | | +---------+ | | +---------+ |
			| | Content | | | | Content | | | | Content | |
			| | Server | | | | Server | | | | Server | |
			| +-------+-+ | | +----+----+ | | +-+-------+ |
			+----------\--+ +------|------+ +--/----------+
			\ | /
			\ | / <- network/network
			\ | / interface
			+------------- \ ------ | ------ / ----+
			| \ | / |
			| NSP +-+-----+-----+-+ |
			| | Provider Edge | |
			| +-------+-------+ |
			| | |
			| | |
			| +--+------+---+ |
			| | User Edge | |
			| +--+---+---+--+ |
			| / | \ |
			+------------- / --- | --- \ ----------+
			/ | \
			/ | \ <- user/network interface
			/ | \
			+---------++ +-----+----+ ++---------+
			|Client #A | |Client #B | |client #C |
			+----------+ +----------+ +----------+
			User A User B User C
	For comparisons sake, for unicast this issue can be resolved e.g.		Example of CDS network configuration
	by using RSVP in some cases.
	(2.1) Access control		Figure 2
	The network should be able to apply necessary access controlling		The CP provides detailed channel information (e.g., Time table of
	actions when an eligible user requests an action (such as a join		each channel) to the information server which is either managed by
	or a leave.) The network should be able to reject any action		the NSP or CP. An end-user client gets the information from the
	requested from an ineligible user.		information server. In this model, multicasting is used in the NSP's
			CDS network, and there are two different contracts. One is the
			contract between the NSP and the user which permits the user to
			access the basic network resources of the NSP. Another contract is
			between the CP and user to permit the user to subscribe to multicast
			content. Because the CP and NSP are different entities, and the NSP
			generally does not allow a CP to control (operate) the network
			resources of the NSP, user authorization needs to be done by the CP
			and NSP independently. Since there is no direct connection to the
			user/network interface, the CP cannot control the user/network
			interface. A user may want to move to another place, or may want to
			change her/his device (client) any time without interrupting her/his
			reception of services.
	(2.2) Control mechanism to support bandwidth of multicast stream		4.1. Information Required by Entities to Support the Proposed Business
	from a physical port of edge router or switch		Model
	The network may need to control the combined bandwidth for all
	channels at the physical port of the edge router or switch so that
	these given physical entities are not overflowed with traffic.
	(2.3) Control mechanism of number of channels delivered from a		User identification and Authentication:
	physical port of edge router and switch
	If an NSP desires to guarantee a certain level of QoS to CP and		The network should be able to identify and authenticate each user
	the receivers, it is necessary that the NSP be able to control the		when they attempt to access the service requesting content. This
	number of channels delivered from a physical port of an edge		user identification is required for:
	router and a switch in cases that there is a limit to the number
	of packet copies and/or number of channels that can be handled by
	multicast routers.
	For comparisons sake, for unicast this issue can be resolved e.g.		authorization for content consumption eligibility
	by using RSVP in some cases.
	(3) User Authentication		user tracking for billing based on actual content consumption
			and network resource usage
	The network should be able to authenticate a user.		With current protocols (IGMP/MLD), the sender cannot distinguish
			which receivers (end hosts) are actually receiving the
			information. The sender must rely on the information from the
			multicasting routers. This can be complicated if the sender and
			routers are maintained by different entities. Furthermore, the
			current user associated with receiver must be identified.
	(4) User Authorization		User Authorization:
	The network, at its option, should be able to authorize a user's		The network, at its option, should be able to authorize a user's
	access to content or a multicast group, so as to meet any demands		access to content or a multicast group, so as to meet any demands
	by a CP to prevent content access by ineligible users. In the		by a CP to prevent content access by ineligible users.
	case that the NSP may wish to provide a service based on
	guaranteed delivery, the NSP would not want to waste its network
	resources on ineligible users.
	(5) Accounting and Billing
	In many commercial multicast situations, NSPs would like to be		Sharing Programming data:
	able to precisely grasp network resource consumption and CPs would
	like to be able to precisely grasp the content consumption by
	users. Such information might be used for identifying highly
	viewed content for advertising revenue, ratings calculations,
	programming decisions, etc., as well as billing and auditing
	purposes. Also content and network providers may wish to provide
	users with access to their usage history.
	To assemble such an understanding of user behavior, it is		NSP needs a mechanism to receive channel programming data from the
	necessary to precisely log information such as who (host/user) is		CP in order to provide the information to the user at channel
	accessing what content at what time (join action) until what time		selection time and also for somehow logging or recording what
	(leave action). The result of the access-control decision (e.g.		programming content has been streamed to the user. In some cases
	results of authorization) would also be valuable information. The		the CP may contract the NSP to bill the user as a proxy for the
	desired degree of logging precisions would depend on the		CP. In this case there needs to be a mechanism for supplying the
	application used.		user-based viewing history with human-meaningful channel data to
			the end-user.
	(5.1) How to share user information		Content usage information by user:
	For commercial multicast applications it is important for NSP and		For billing and auditing purposes the CP needs the NSP to provide
	CP to be able to share information regarding user's behaviour (as		it with detailed per-user usage behavior indicating what content
	described in (5) in standardized ways.		was consumed from when to when. There needs to be a mechanism to
			supply the user-based viewing history from the NSP to the CP. If
			the CP is selling on an on-demand model, or tiered subscription
			basis or supplies some sort of online account statement this
			history needs to be fed back to the CP in near real-time. To
			assemble such data on user behavior, it is necessary to precisely
			log information such as who (host/user) is accessing what content
			at what time (join action) until what time (leave action). The
			result of the access-control decision (e.g. results of
			authorization) would also be valuable information. The desired
			degree of logging precisions would depend on the application used.
	(6) Notification to Users of the Result of the Join Request		Notification to Users of the Result of the Join Request:
	It should be possible to provide information to the user about the		It should be possible to provide information to the user about the
	status of his/her join request(granted/denied/other).		status of his/her join request(granted/denied/other). Such
			information can be used to give meaningful feedback to the user.
	(7) Service and Terminal Portability		5. Admission Control for Multicasting
	Depending on the service, networks should allow for a user to		In order to guarantee certain QoS it is important for network
	receive a service from different places and/or with a different		providers (at their option) to be able to protect their network
	terminal device.		resources from being wasted, (either maliciously or accidentally).
			The NSP should be able to apply appropriate access controlling
			actions based on user eligibility status:
	(8) Support of ASM and SSM		The network should be able to apply necessary access controlling
			actions when an eligible user requests an action (such as a join
			or a leave.)
	Both ASM (G), and SSM (S,G) should be supported as multicast		The network should be able to reject any action requested from an
	models.		ineligible user.
	(9) Admission Control for Join Action		In order to maintain a predefined QoS level, depending on the NSP's
	In order to maintain a predefined QoS level, depending on the		policy, a user edge should be able to control the number of streams
	NSP's policy, a user edge should be able to control the number of		it serves to a user, and total bandwidth consumed to that user. For
	streams it serves to a user, and total bandwidth consumed to that		example if the number of streams being served to a certain user has
	user. For example if the number of streams being served to a		reached the limit defined by the NSP's policy, then the user edge
	certain user has reached the limit defined by the NSP's policy,		should not accept a subsequent "join" until one of the existing
	then the user edge should not accept a subsequent "join" until one		streams is terminated. Similarly, if the NSP is controlling by per-
	of the existing streams is terminated. Similarly, if the NSP is		user bandwidth consumption, then a subsequent "join" should not be
	controlling by per-user bandwidth consumption, then a subsequent		accepted if delivery of the requested stream would push the consumed
	"join" should not be accepted if delivery of the requested stream		bandwidth over the NSP policy-defined limit.
	would push the consumed bandwidth over the NSP policy-defined
	limit.
	(10) Channel Join Latency and Leave Latency		The network may need to control the combined bandwidth for all
			channels at the physical port of the edge router or switch so that
			these given physical entities are not overflowed with traffic. This
			entails being able to control the number of channels delivered, the
			bandwidth for each channel and the combined bandwidth for all
			channels.
			6. Performance requirements
			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		strict requirements in terms of user experience. Join latency is the
	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
	the time between when a user sends a "leave" signal and when the		the time between when a user sends a "leave" signal and when the
	network stops streaming to the user.		network stops streaming to the user. Leave and Join latencies impact
			the acceptable user experience for fast channel surfing. In an IP-TV
	Leave and Join latencies impact the acceptable user experience for		application, users are not going to be receptive to a slow response
	fast channel surfing. In an IP-TV application, users are not going		time when changing channels. If there are policies for controlling
	to be receptive to a slow response time when changing channels.		the number of simultaneous streams a user may access then channel
	If there are policies for controlling the number of simultaneous		surfing will be determined by the join and leave latencies.
	streams a user may access then channel surfing will be determined		Furthermore, leave affects resource consumption: with a low "leave
	by the join and leave latencies.		latency" network providers could minimize streaming content when
			there are no audiences. It is important that any overhead for
	Furthermore, leave affects resource consumption: with a low		authentication, authorization, and access-control be minimized at the
	"leave latency" network providers could minimize streaming content		times of joining and leaving multicast channels so as to achieve join
	when there are no audiences.		and leave latencies acceptable in terms of user experience. For
			example this is important in an IP-TV application, because users are
			not going to be receptive to a slow response time when changing
			channels.
	It is important that any overhead for authentication,		7. Concomitant requirements
	authorization, and access-control be minimized at the times of
	joining and leaving multicast channels so as to achieve join and
	leave latencies acceptable in terms of user experience. For
	example this is important in an IP-TV application, because users
	are not going to be receptive to a slow response time when
	changing channels.
	(11) Scalability		Scalability
	Solutions that are used for AAA and QoS enabled IP multicasting		Solutions that are used for AAA and QoS enabled IP multicasting
	should scale enough to support the needs of content providers and		should scale enough to support the needs of content providers and
	network operators. NSP's multicast access and QoS policies should		network operators. NSP's multicast access and QoS policies should be
	be manageable for large scale users. (e.g. millions of users,		manageable for large scale users. (e.g. millions of users, thousands
	thousands of edge-routers)		of edge-routers)
	(12) Small Impact on the Existing Products
	Impact on the existing products (e.g., protocols, software, etc.)
	should be as minimal as possible.
	Ideally the NSP should be able to use the same infrastructure		Service and Terminal Portability:
	(such as access control) to support commercial multicast services
	for the so called "triple play" services: voice (VoIP), video, and
	broadband Internet access services.
	When a CP requires the NSP to provide a level of QoS surpassing		Depending on the service, networks should allow for a user to receive
	"best effort" delivery or to provide special services (e.g., to		a service from different places and/or with a different terminal
	limited users with specific attributes), certain parameters of the		device.
	CDS may be defined by a contractual relation between the NSP and
	the CP. However, just as for best-effort unicast, multicast
	allows for content sourced by CPs without a contractual relation
	with the NSP. Therefore, solutions addressing the requirements
	defined in this memo should not make obsolete multicasting that
	does not include AAA features. NSPs may offer tiered services,
	with higher QOS, accounting, authentication, etc., depending on
	contractual relation with the CPs. It is therefore important that
	Multicast AAA and QoS functions be as modular and flexible as
	possible.
	(13) Deployable as Alternative to Unicast		Deployable as Alternative to Unicast
	IP Multicasting would ideally be available as an alternative to IP		IP Multicasting would ideally be available as an alternative to IP
	unicasting when the "on-demand" nature of unicasting is not		unicasting when the "on-demand" nature of unicasting is not required.
	required. Therefore interfaces to multicasting should allow for		Therefore interfaces to multicasting should allow for easy
	easy integration into CDS systems that support unicasting.		integration into CDS systems that support unicasting. Especially
			equivalent interfaces for authorization, access control and
	Especially equivalent interfaces for authorization, access control		accounting capabilities should be provided.
	and accounting capabilities should be provided.
	(14) Multicast Replication
	The above requirements should also apply if multicast replication
	is being done on an access-node (e.g. DSLAMs or OLTs).
	Specific functional requirements for each application can be
	derived from the above general requirements. An example is shown
	in the section 5.
	5. Application Example and its Specific Requirements
	This section shows an application example which could benefit from
	multicasting. Then, specific functional requirements related to
	user-based accounting capabilities are derived.
	5.1 IP Multicast-based Content Delivery Service (CDS): CP and NSP are
	different entities (companies)
	Broadband access networks such as ADSL (Asymmetric Digital
	Subscriber Line) or FTTH (Fiber to the Home) have been deployed
	widely in recent years. Content Delivery Service (CDS) is expected
	to be a major application provided through broadband access
	networks. Because many services such as television broadcasting
	require huge bandwidth (e.g., 6Mbit/s) and processing power at
	content server, IP multicast is used as an efficient delivery
	mechanism for CDS.
	One way to provide high quality CDS is to use closed networks
	("walled-garden" model).
	This subsection shows an example where CP and NSP are different
	entities (companies).
	5.1.1 Network Model for Multicast Content Delivery Service
	As shown in Fig.2, networks for CDS contain three different types
	of entities: Content Provider (CP), Network Service Provider (NSP),
	and user clients. An NSP owns the network resources
	(infrastructure). It accommodates content providers on one side
	and accommodates user clients on the other side. NSP provides the
	network for CDS to two other entities (i.e., CPs and user clients).
	A CP provides content to each user through the network of NSPs.
	NSPs are responsible for delivering the content to user clients,
	and for controlling the network resources.
	+-------------+ +-------------+ +-------------+
	| CP | | CP | | CP |
	| #1 | | #2 | | #3 |
	| +---------+ | | +---------+ | | +---------+ |
	| | content | | | | content | | | | content | |
	| | server | | | | server | | | | server | |
	| +-------+-+ | | +----+----+ | | +-+-------+ |
	+----------\--+ +------|------+ +--/----------+
	\ | /
	\ | / <- network/network
	\ | / interface
	+------------- \ ------ | ------ / ----+
	| \ | / |
	| NSP +-+-----+-----+-+ |
	| | Provider Edge | |
	| +-------+-------+ | +-----------------+
	| | |---| Information |
	| | | | server |
	| +--+------+---+ | +-----------------+
	| | User Edge | |
	| +--+---+---+--+ |
	| / | \ |
	+------------- / --- | --- \ ----------+
	/ | \
	/ | \ <- user/network interface
	/ | \
	+---------++ +-----+----+ ++---------+
	|client #a | |client #b | |client #c |
	+----------+ +----------+ +----------+
	User A User B User C
	Fig.2 Example of CDS network configuration		Support of ASM and SSM
	The NSP provides the information server for all multicast channels,		Both ASM (G), and SSM (S,G) should be supported as multicast models.
	and a CP gives detailed channel information (e.g., Time table of
	each channel) to the information server. An end-user client gets
	the information from the information server. In this model,
	multicasting is used in the NSP's CDS network, and there are two
	different contracts. One is the contract between the NSP and the
	user which permits the user to access the basic network resources
	of the NSP. Another contract is between the CP and user to permit
	the user to subscribe to multicast content. Because the CP and NSP
	are different entities, and the NSP generally does not allow a CP
	to control (operate) the network resources of the NSP, user
	authorization needs to be done by the CP and NSP independently.
	Since there is no direct connection to the user/network interface,
	the CP cannot control the user/network interface. A user may want
	to move to another place, or may want to change her/his device
	(client) any time without interrupting her/his reception of
	services. As such, IP Multicast network should support
	portability capabilities.
	5.1.2 Content Delivery Service Requirements		Small Impact on the Existing Products
	Below are listed specific requirements to support common business		Impact on the existing products (e.g., protocols, software, etc.)
	cases/ contractual arrangements for the IP Multicast-based Content		should be as minimal as possible. Ideally the NSP should be able to
	Delivery Service.		use the same infrastructure (such as access control) to support
			commercial multicast services for the so called "triple play"
			services: voice (VoIP), video, and broadband Internet access
			services. When a CP requires the NSP to provide a level of QoS
			surpassing "best effort" delivery or to provide special services
			(e.g., to limited users with specific attributes), certain parameters
			of the CDS may be defined by a contractual relation between the NSP
			and the CP. However, just as for best-effort unicast, multicast
			allows for content sourced by CPs without a contractual relation with
			the NSP. Therefore, solutions addressing the requirements defined in
			this memo should not make obsolete multicasting that does not include
			AAA features. NSPs may offer tiered services, with higher QOS,
			accounting, authentication, etc., depending on contractual relation
			with the CPs. It is therefore important that Multicast AAA and QoS
			functions be as modular and flexible as possible.
	5.1.2.1 Accounting Requirements		Multicast Replication
	An NSP may have different contractual agreements with various CPs		The above requirements should also apply if multicast replication is
	or various legal obligations in different locations. One possible		being done on an access-node (e.g. DSLAMs or OLTs).
	business relationship between a CP and NSP is that of a revenue
	sharing which could be on a per content/usage-base. A solution
	should support varied billing and charging methods to satisfy both
	common legal and business/financial requirements to deploy
	multicasting services: this requires accurate and near real-time
	accounting information about the user clients' activity accessing
	the content services.
	The user accessing particular content is represented by the user's
	activities of joining or leaving the corresponding multicast
	group/channel (<(*,g)> or (s,g)). In multicast networks, only NSPs
	can collect joining or leaving activities in real-time through
	their user edges. The NSPs can transfer the accounting information
	to related CPs for them to generate user billing information.
	Existing standard AAA technology may be used to transfer the
	accounting information.
	To match the accounting information with a particular user, the		8. Constituent Logical Functional Components
	user has to be authenticated. Usually the account information of a
	user for content access is maintained by the CP. A user may have
	different user accounts for different CPs.(e.g. user_a@cp#1 and
	user_b@cp#2) The account is usually in the format of (username,
	password) so an user can access the content services from anywhere.
	For example, an user can access the CP from different NSPs.(e.g. a
	fixed line NSP and a mobile NSP). It should be noted that the user
	account used for content access can be different from the one used
	for network access maintained by NSPs.
	The NSP-CP model represents a multi-domain AAA environment. There		Below is a diagram of a AAA enabled multicasting network, including
	are plural cases of the model depending on the trust relationship		the logical components within the various entities.
	between the NSP and CP, and additional service requirements such
	as a certain QoS level guarantee or service/terminal portability.
	A mechanism is necessary to allow a CP and NSP to grasp each		+-------------------------------+
	user's behavior independently.		| user |
			|+- - - - - - - - - - - - - - -+|
			|| CPE ||
			|| ||
			|+- - - - - | - - - - - - - - -+|
			+-----------|-------------------+
			|
			-------|------ IFa
			|
			+-----------|-----------------------+
			| NSP | |
			| | |
			|+- - - - - |- - _+ + - - - - - + |
			|| | | | | | |
			| +------|-+ | +--------+ |
			|| | AN | | | | | MACF || |
			| | | | | | |
			|| +------|-+ | | | +---|----+| |
			| | | | | |
			| | | | IFd----- | |
			| | | IFb | | |
			|| +------|---+ | | | +---|----+| |
			| | |---|---| mAAA | |
			|| | NAS | | | | |(MACF *)|| | * optional
			| +----------+ | +--------+ |
			||+- - - - - - - -+ - - |- - - - -+ |
			+-----------------------|-----------+
			|
			-------|------ IFc
			|
			+-----------------------|-------+
			| CP +---------+ |
			| | CP-AAA | |
			| +---------+ |
			+-------------------------------+
	Another requirement related to accounting is the ability to notify		AAA enabled multicasting network with admission control
	a user when accounting really starts. When a "free preview"
	capability is supported, accounting may not start at the same time
	as the user's joining of the stream.
	Any solution addressing the requirements of this memo should		Figure 3
	consider the Interdomain accounting issues presented in RFC-2975
	[3]. It is especially important to consider that the CP and NSP
	as separate administrative entities can not be assumed to trust
	one another. The solution should be robust enough to handle
	packet loss between entity domains and assure for data integrity.
	In addition any solution should take into consideration common
	legal or financial requirements requiring confidential archiving
	of usage data.
	5.1.2.2 Authorization Requirements		The user entity includes the CPE (Customer Premise Equipment) which
			connects the receiver (s).
	The NSPs are responsible for delivering content and are generally		The NSP (Network Service Provider) includes the transport system and
	required to meet certain QoS levels or SLA (service level		a logical element for multicast AAA functionality. The TS (transport
	agreements). For example, video quality is very sensitive to packet		system) is comprised of the access node and NAS (Network Access
	loss. So if an NSP --due to limited network resources -- cannot		Server) An AN (Access Node) may be connected directly to mAAA or a
	meet quality requirements if it accepts an additional user request,		NAS relays AAA information between an AN and a mAAA. Descriptions of
	the NSP should reject that user's access request to avoid charging		AN and its interfaces are out of the scope for this memo. The
	the existing (i.e., already-joined) user for bad services. For		multicast AAA function may be provided by a mAAA which may include
	example, if an access line is shared by several users, an		the function that downloads Join access control lists to the NAS
	additional user's join may cause performance degradation for other		(this function is referred to as the conditional access policy
	users. If the incoming user is the first user on a user edge, this		control function.)
	will initiate the transmission of data between the provider edge
	and the user edge and this extra network traffic may cause
	performance degradation. There may also be policies that do not
	necessarily give highest priority to the "first-come" users, and
	these should also be considered.
	In order to protect network resources against misuse/malicious		Interface between mAAA and NAS
	access and maintain a QoS level, appropriate admission control
	function for traffic policing purposes is necessary so that the NSP
	can accept or reject the request without degrading the QoS beyond
	the specified level.
	5.1.2.3 Authentication Requirements		The interface between mAAA and the NAS is labeled IFb in Figure 3.
			Over IFb the NAS sends an access request to the NSP-mAAA and the mAAA
			replies. The mAAA may push conditional access policy to the NAS.
	There are two different aims of authentication. One is		CP-AAA
	authentication for network access, and another one is for content
	access. For the first case of authentication, NSP has a AAA server,
	and for the second case, each CP has a AAA server. In some cases,
	CPs delegate (outsource) the operation of user authentication to
	NSPs.
	As such, in addition to network access, multicast access by a user		The content provider may have its own AAA server which has the
	also needs to be authenticated. Content authentication should		authority over access policy for its contents.
	support the models where:
	- authentication for multicast content is outsourced to the
	NSP.
	- authentication for multicast content access is operated by
	the CP
	5.2 IP Multicast-based Content Delivery Service (CDS): CP and NSP are		Interface between user and NSP
	the same entities (companies)
	Another application example is the case where the content provider		The interface between the user and the NSP is labeled IFa in Figure
	(CP) and network service provider (NSP) are the same entity		3. Over IFa the user makes a multicasting request to the NSP. The
	(company) as shown in Fig. 3. In the case that the CP and NSP are		NSP may in return forward multicast traffic depending on the NSP and
	the same entity, some of the requirements indicated in 4.1 are not		CP's policy decisions.
	required.
	This model does not require the following items:		Interface between NSP and CP
	- Communication method between sender (content server) and		The interface between the NSP and CP is labeled IFc. Over IFc the
	user. Since they belong to the same company, they can use		NSP requests to the CP-AAA for access to contents and the CP replies.
	all the available information.		CP may also send conditional access policy over this interface for
			AAA-proxying.
	- Methods to share user-related information between NSPs and		The NSP may also include a component that provides network resource
	CPs.		management (e.g. QoS management), as described in section 5,
	+-----------------------------------------------------+		"Admission Control for Multicasting". Resource management and
	| +---------+ |		admission control is provided by MACF (Multicast Admission Control
	| | content | |		Function). This means that, before replying to the user's multicast
	| | server | |		request, the mAAA queries the MACF for a network resource access
	| +----+----+ |		decision over the interface IFd. The MACF is responsible for
	| | |		allocating network resources for forwarding multicast traffic. MACF
	| CP+NSP +-------+-------+ |		also receives Leave information from NAS so that MACF releases
	| | Provider Edge | |		corresponding reserved resources.
	| +-------+-------+ +--------------------+ |
	| | | Information server | |
	| | +--------------------+ |
	| +-------------+ |
	| | User Edge | |
	| +--+---+---+--+ |
	| / | \ |
	+----------- / --- | --- \ ---------------------------+
	/ | \
	/ | \ <- user/network interface
	/ | \
	+---------++ +-----+----+ ++---------+
	|Client #a | |client #b | |client #c |
	+----------+ +----------+ +----------+
	User A User B User C
	Fig.3 Example of CDS network configuration		9. Acknowledgments
	6. Acknowledgments
	The authors of this draft would like to express their appreciation		The authors of this draft would like to express their appreciation to
	to Pekka Savola of Netcore Ltd., Daniel Alvarez, and Toerless		Christian Jacquenet of France Telecom whose contributions to the "AAA
	Eckert of Cisco Systems, Sam Sambasivan of AT&T, Sanjay Wadhwa of		Framework for Multicasting" [draft-ietf-mboned-multiaaa-framework]
	Juniper, Tom Anschutz and Steven Wright of BellSouth, Nicolai		largely influenced this draft, Pekka Savola of Netcore Ltd., Daniel
	Leymann of T-Systems, Carlos Garcia Braschi of Telefonica Empresas,		Alvarez, and Toerless Eckert of Cisco Systems, Sam Sambasivan of
	Marshall Eubanks of Multicast Techno, Stephen Rife of NTT and		AT&T, Sanjay Wadhwa, Greg Shepherd, and Leonard Giuliano of Juniper,
	David Meyer in his role as mboned WG chair, as well as their		Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of
	thanks to the participants of the MBONED WG in general.		T-Systems, Bill Atwood of Concordia University, Carlos Garcia Braschi
			of Telefonica Empresas, Marshall Eubanks in his role as mboned WG
			chair, Ron Bonica in his role as Director as the Operations and
			Management Area, Stephen Rife of NTT and David Meyer in his former
			role as mboned WG chair, as well as their thanks to the participants
			of the MBONED WG in general.
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	7. IANA Considerations		10. IANA Considerations
	This memo does not raise any IANA consideration issues.		This memo does not raise any IANA consideration issues.
	8. Security Considerations		11. Security Considerations
	Accounting capabilities can be used to enhance the security of		Accounting capabilities can be used to enhance the security of
	multicast networks by excluding ineligible clients from the		multicast networks by excluding ineligible clients from the networks.
	networks.
	These requirements are not meant to address encryption issues.		These requirements are not meant to address encryption issues. Any
	Any solution meeting these requirements should allow for the		solution meeting these requirements should allow for the
	implementation of encryption such as MSEC on the multicast data.		implementation of encryption such as MSEC on the multicast data.
	9. Privacy considerations		12. Privacy considerations
	Any solution which meets these requirements should weigh the		Any solution which meets these requirements should weigh the benefits
	benefits of user-based accounting with the privacy considerations		of user-based accounting with the privacy considerations of the user.
	of the user. For example solutions are encouraged when applicable		For example solutions are encouraged when applicable to consider
	to consider encryption of the content data between the content		encryption of the content data between the content provider and the
	provider and the user in such a way that the Network Provider does		user in such a way that the Network Provider does not know the
	not know the contents of the channel.		contents of the channel.
			13. Conclusion
	10. Conclusion
	This memo describes general requirements for providing AAA and QoS		This memo describes general requirements for providing AAA and QoS
	enabled IP multicasting services. It lists issues related to		enabled IP multicasting services in multi-entity models. A few
	accounting, authentication, authorization and admission control		models are evaluated with regard to their support by current
	for multicast content delivery. Content Delivery Services with		technologies. The "multi-entity CDS with direct billing of the end
	different business models are cited as the type of application		user" model is presented and requirements for information sharing
	which could benefit from the capabilities of AAA and QoS enabled		between entities and requirements for admission control to enable
	IP multicasting described in this document.		guaranteeing of QoS are derived. Performance requirements and
			concomitant requirements are also presented.
	Normative References		14. Normative References
	[1] B. Cain, et. al., "Internet Group Management Protocol, Version		[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
	3", RFC3376, October 2002.		Accounting Management", RFC 2975, October 2000.
	[2] R. Vida, et. al., "Multicast Listener Discovery Version 2		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	(MLDv2) for IPv6", RFC3810, June 2004.		Thyagarajan, "Internet Group Management Protocol, Version
			3", RFC 3376, October 2002.
	[3] Aboba B , et. al., "Introduction to Accounting Management",		[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
	RFC 2975, October 2000.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
	Authors' Addresses		Authors' Addresses
	Tsunemasa Hayashi		Tsunemasa Hayashi
	NTT Network Innovation Laboratories		NTT Network Innovation Laboratories
	1-1 Hikarino'oka, Yokosuka-shi, Kanagawa, 239-0847 Japan		1-1 Hikarino'oka
			Yokosuka-shi, Kanagawa 239-0847
			Japan
	Phone: +81 46 859 8790		Phone: +81 46 859 8790
	Email: hayashi.tsunemasa@lab.ntt.co.jp		Email: hayashi.tsunemasa@lab.ntt.co.jp
	Haixiang He		Haixiang He
	Nortel		Nortel
	600 Technology Park Drive Billerica, MA 01801, USA		600 Technology Park Drive
			Billerica, MA 01801
			USA
	Phone: +1 978 288 7482		Phone: +1 978 288 7482
	Email: haixiang@nortel.com		Email: haixiang@nortel.com
	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
	Susheela Vaidya		Susheela Vaidya
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 W. Tasman Drive San Jose, CA 95134		170 W. Tasman Drive
			San Jose, CA 95134
			USA
	Phone: +1 408 525 1952		Phone: +1 408 525 1952
	Email: svaidya@cisco.com		Email: svaidya@cisco.com
End of changes. 106 change blocks.
	619 lines changed or deleted		508 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/