draft-ietf-mboned-maccnt-req-02.txt		draft-ietf-mboned-maccnt-req-03.txt
	Tsunemasa Hayashi, NTT		Tsunemasa Hayashi, NTT
	Internet Draft Haixiang He, Nortel		Internet Draft Haixiang He, Nortel
	Document:draft-ietf-mboned-maccnt-req-02.txt Hiroaki Satou, NTT		Document:draft-ietf-mboned-maccnt-req-03.txt Hiroaki Satou, NTT
	Expires: June 18, 2006 Hiroshi Ohta, NTT		Expires: July 14, 2006 Hiroshi Ohta, NTT
	Susheela Vaidya, Cisco Systems		Susheela Vaidya, Cisco Systems
	December 15, 2005		January 10, 2006
	Requirements for Accounting, Authentication and Authorization in		Requirements for Accounting, Authentication and Authorization in
	Well Managed IP Multicasting Services		Well Managed IP Multicasting Services
	<draft-ietf-mboned-maccnt-req-02.txt>		<draft-ietf-mboned-maccnt-req-03.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet 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-
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	documents at any time. It is inappropriate to use Internet-Drafts		documents at any time. It is inappropriate to use Internet-Drafts
	as reference material or to cite them other than as "work in		as reference 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 June 18, 2006.		This Internet-Draft will expire on July 14, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005)		Copyright (C) The Internet Society (2006)
	Abstract		Abstract
	This memo presents requirements in the area of accounting and		This memo presents requirements in the area of accounting and
	access control for multicasting. General requirements for		access control for multicasting. General requirements for
	accounting capabilities including quality-of-service (QoS) related		accounting capabilities including quality-of-service (QoS) related
	issues are listed. This I-D assumes that these capabilities can be		issues are listed. Finally, cases for Content Delivery Services
	realized by functions implemented at edges of a network based on		(CDS) are described as application examples which could benefit
	IGMP or MLD. Finally, cases for Content Delivery Services (CDS)		from multicasting accounting and access control capabilities as
	are described as application examples which could benefit from
	multicasting accounting and access control capabilities as
	described in the I-D. It is proposed that this I-D be used as a		described in the I-D. It is proposed that this I-D be used as a
	starting point for further discussion on these issues.		starting point for further discussion on these issues.
	Table of contents		Table of contents
	Copyright Notice.................................................1		Copyright Notice.................................................1
	1. Introduction..................................................2		1. Introduction..................................................2
	2. Definitions and Abbreviations.................................4		2. Definitions and Abbreviations.................................4
	2.1 Definitions..................................................4		2.1 Definitions..................................................4
	2.2 Abbreviations................................................4		2.2 Abbreviations................................................4
	3. Problem statement.............................................5		3. Problem statement.............................................4
	3.1 Accounting issues...........................................5		3.1 Accounting issues...........................................5
	3.2 Relationship with secure multicasting (MSEC)................6		3.2 Relationship with secure multicasting (MSEC)................6
	4. General functional requirements for well managed IP		4. General AAA-related functional requirements for IP
	multicasting..................................................6		multicasting..................................................6
	5. Application example and its specific requirements............10		5. Application example and its specific requirements............10
	5.1 IP Multicast-based Content Delivery Service (CDS): CP and		5.1 IP Multicast-based Content Delivery Service (CDS): CP and
	NSP are different entities (companies)......................10		NSP are different entities (companies)......................10
	5.1.1 Network model for Multicast Content Delivery Service......10		5.1.1 Network model for Multicast Content Delivery Service......10
	5.1.2 Content Delivery Service Requirements.....................12		5.1.2 Content Delivery Service Requirements.....................12
	5.1.2.1 Accounting Requirements.................................12		5.1.2.1 Accounting Requirements.................................12
	5.1.2.2 Authorization Requirements..............................13		5.1.2.2 Authorization Requirements..............................13
	5.1.2.3 Authentication Requirements.............................13		5.1.2.3 Authentication Requirements.............................13
	5.2 IP Multicast-based Content Delivery Service (CDS): CP and		5.2 IP Multicast-based Content Delivery Service (CDS): CP and
	NSP are the same entities (companies).......................14		NSP are the same entities (companies).......................14
	6. Acknowledgements.............................................15		6. Acknowledgements.............................................15
	7. IANA considerations..........................................15		7. IANA considerations..........................................15
	8. Security considerations......................................15		8. Security considerations......................................15
	9. Conclusion...................................................15		9. Conclusion...................................................15
	Normative References............................................15		Normative References............................................15
			Authors' Addresses..............................................15
	Full Copyright Statement........................................17		Full Copyright Statement........................................17
	Intellectual Property...........................................17		Intellectual Property...........................................17
	Acknowledgement.................................................17
	1. Introduction		1. Introduction
	The intention of this memo is to define requirements related to		This I-D will present general functional requirements related to
	accounting, authentication and authorization issues for "well-		accounting, authentication and authorization issues in IP
	managed IP multicasting" services ("well-managed" defined at the		multicasting networks. A multicast network which fulfills all of
	end of this introduction).		these requirements will be called a "fully AAA enabled" IP
			multicasting network. Fulfillment of all or some of the
			requirements will make possible more robust management of IP
			multicasting networks, and as such these capabilities contribute to
			the provision of well-managed IP multicasting services.
	IP multicasting is becoming widely used as a method to save network		IP multicasting is becoming widely used as a method to save network
	resources such as bandwidth or CPU processing power of the sender's		resources such as bandwidth or CPU processing power of the sender's
	server for cases where a large volume of information needs to be		server for cases where a large volume of information needs to be
	distributed to a large number of receivers. This trend can be		distributed to a large number of receivers. This trend can be
	observed both in enterprise use and in broadband services provided		observed both in enterprise use and in broadband services provided
	by network operator/service providers.		by network operator/service providers.
	Distance learning within a university and in-house (in-company)		Distance learning within a university and in-house (in-company)
	sharing of multimedia information are examples of enterprise use.		sharing of multimedia information are examples of enterprise use.
	skipping to change at page 4, line 14		skipping to change at page 4, line 16
	used with user-based accounting capabilities, its applicability		used with user-based accounting capabilities, its applicability
	would be greatly widened.		would be greatly widened.
	This I-D first describes problems on accounting issues in		This I-D first describes problems on accounting issues in
	multicasting. Then the general requirements for this capability		multicasting. Then the general requirements for this capability
	including QoS related issues are listed. Finally, application		including QoS related issues are listed. Finally, application
	examples which could benefit from multicasting with accounting		examples which could benefit from multicasting with accounting
	capabilities are shown. It is proposed that this I-D be used as a		capabilities are shown. It is proposed that this I-D be used as a
	starting point for a discussion on these issues.		starting point for a discussion on these issues.
	This I-D will present general functional requirements related to
	accounting, authentication and authorization issues in IP
	multicasting networks, and a multicast network which fulfills these
	requirements will be called a "well managed" IP multicasting
	network.
	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.
	User-based accounting: actions for grasping each user's behavior,		User-based accounting: actions for grasping each user's behavior,
	skipping to change at page 5, line 4		skipping to change at page 4, line 46
	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: Single-Source Multicast		SSM: Single-Source Multicast
	QoS: Quality of Service		QoS: Quality of Service
	3. Problem statement
			3. Problem statement
	3.1 Accounting issues		3.1 Accounting issues
	In unicast communications, the server (information source) can		In unicast communications, the server (information source) can
	identify the client (information receiver) and only permits		identify the client (information receiver) and only permits
	connection by an eligible client when this type of access control		connection by an eligible client when this type of access control
	is necessary. In addition, when necessary, the server can grasp		is necessary. In addition, when necessary, the server can grasp
	what the client is doing (e.g., connecting to the server, starting		what the client is doing (e.g., connecting to the server, starting
	reception, what information the client is receiving, terminating		reception, what information the client is receiving, terminating
	reception, disconnecting from the server).		reception, disconnecting from the server).
	On the other hand, in multicast communication with current		On the other hand, in multicast communication with current
	standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its		standards (e.g., IGMPv3[1] or MLDv2[1]) the server just feeds its
	skipping to change at page 6, line 19		skipping to change at page 6, line 19
	other words, the ability to decode data to return it to its		other words, the ability to decode data to return it to its
	generally useable form.) This I-D presents requirements for		generally useable form.) This I-D presents requirements for
	multicasting networks in the areas of 1) access control to prevent		multicasting networks in the areas of 1) access control to prevent
	unauthorized access to the network, and 2) accounting to grasp user		unauthorized access to the network, and 2) accounting to grasp user
	activity. The functional requirements do not require content		activity. The functional requirements do not require content
	encryption although it might solve some of the related problems.		encryption although it might solve some of the related problems.
	At this point, it is not yet clear whether encryption would be part		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		of a solution and if so, what other components (if any) would also
	be required.		be required.
	4. General functional requirements for well managed IP multicasting		4. General AAA-related functional requirements for IP multicasting
	In consideration of the issues presented in section 3, the		In consideration of the issues presented in section 3, the
	following requirements have been derived:		following requirements have been derived:
	(1) User identification		(1) User identification
	The network should be able to identify each user when they attempt		The network should be able to identify each user when they attempt
	to access the service so that necessary access controlling actions		to access the service so that necessary access controlling actions
	can be applied. Also, it is necessary to identify the source		can be applied. Also, it is necessary to identify the source
	(user) of each request (e.g., join/leave) for user accounting		(user) of each request (e.g., join/leave) for user accounting
	skipping to change at page 7, line 12		skipping to change at page 7, line 12
	(2.1) Access control		(2.1) Access control
	The network should be able to apply necessary access controlling		The network should be able to apply necessary access controlling
	actions when an eligible user requests. The network should be able		actions when an eligible user requests. The network should be able
	to reject any action requested from an ineligible user.		to reject any action requested from an ineligible user.
	(2.2) Control mechanism to support bandwidth of multicast stream		(2.2) Control mechanism to support bandwidth of multicast stream
	from a physical port of edge router or switch		from a physical port of edge router or switch
	The network may need to control the combined bandwidth for all		The network may need to control the combined bandwidth for all
	groups both at the physical port of the edge router or switch so		groups at the physical port of the edge router or switch so that
	that these given physical entities are not overflowed with traffic.		these given physical entities are not overflowed with traffic.
	(2.3) Control mechanism of number of groups delivered from a		(2.3) Control mechanism of number of groups delivered from a
	physical port of edge router and switch		physical port of edge router and switch
	If an NSP desires to guarantee a certain level of QoS to CP and the		If an NSP desires to guarantee a certain level of QoS to CP and the
	receivers, it is necessary that the NSP be able to control the		receivers, it is necessary that the NSP be able to control the
	number of groups delivered from a physical port of an edge router		number of groups delivered from a physical port of an edge router
	and a switch so that the combined bandwidth between content servers		and a switch so that the combined bandwidth between content servers
	and multicast routers can be within the limit.		and multicast routers can be within the limit.
	skipping to change at page 11, line 50		skipping to change at page 11, line 50
	Fig.2 Example of CDS network configuration		Fig.2 Example of CDS network configuration
	The NSP provides the information server for all multicast channels,		The NSP provides the information server for all multicast channels,
	and a CP gives detailed channel information (e.g., Time table of		and a CP gives detailed channel information (e.g., Time table of
	each channel) to the information server. An end-user client gets		each channel) to the information server. An end-user client gets
	the information from the information server. In this model,		the information from the information server. In this model,
	multicast is used in the NSP's CDS network, and there are two		multicast is used in the NSP's CDS network, and there are two
	different contracts. One is the contract between the NSP and the		different contracts. One is the contract between the NSP and the
	end user which permits the user to access the basic network		end user which permits the user to access the basic network
	resources of the NSP. Another contract is between the CP and end		resources of the NSP. Another contract is between the CP and end
	user to permit the user to subscribe multicast content. Because the		user to permit the user to subscribe to multicast content. Because
	CP and NSP are different entities, and the NSP generally does not		the CP and NSP are different entities, and the NSP generally does
	allow a CP to control (operate) the network resources of the NSP,		not allow a CP to control (operate) the network resources of the
	user authorization needs to be done by the CP and NSP independently.		NSP, user authorization needs to be done by the CP and NSP
	Since there is no direct connection to the user/network interface,		independently. Since there is no direct connection to the
	the CP cannot control the user/network interface. An end user may		user/network interface, the CP cannot control the user/network
	want to move to another place, or may want to change her/his device		interface. An end user may want to move to another place, or may
	(client) anytime without interrupting her/his reception of services.		want to change her/his device (client) anytime without interrupting
	As such, IP Multicast network should support portability		her/his reception of services. As such, IP Multicast network
	capabilities.		should support portability capabilities.
	5.1.2 Content Delivery Service Requirements		5.1.2 Content Delivery Service Requirements
	To have a successful business providing multicast, there are some		To have a successful business providing multicast, there are some
	specific requirements for the IP Multicast-based Content Delivery		specific requirements for the IP Multicast-based Content Delivery
	Service.		Service.
	5.1.2.1 Accounting Requirements		5.1.2.1 Accounting Requirements
	Since the CP and NSP are different business entities, they need to		Since the CP and NSP are different business entities, they need to
	skipping to change at page 15, line 12		skipping to change at page 15, line 12
	Fig.3 Example of CDS network configuration		Fig.3 Example of CDS network configuration
	6. Acknowledgements		6. Acknowledgements
	The authors of this draft would like to express their appreciation		The authors of this draft would like to express their appreciation
	to Pekka Savola of Netcore Ltd., Daniel Alvarez and Toerless Eckert		to Pekka Savola of Netcore Ltd., Daniel Alvarez and Toerless Eckert
	of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper,		of Cisco Systems, Sam Sambasivan of SBC, Sanjay Wadhwa of Juniper,
	Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T-		Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of T-
	Systems, as well as the participants of the MBONED WG in general.		Systems, as well as the participants of the MBONED WG in general.
			Funding for the RFC Editor function is currently provided by the
			Internet Society.
	7. IANA considerations		7. IANA considerations
	This I-D does not raise any IANA consideration issues.		This I-D does not raise any IANA consideration issues.
	8. Security considerations		8. 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.
	9. Conclusion		9. Conclusion
	This I-D describes general requirements for providing "well		This I-D describes general requirements for providing "well
	managed" IP multicasting services. It lists issues related to		managed" IP multicasting services. It lists issues related to
	accounting, authentication, authorization and admission control for		accounting, authentication, authorization and admission control for
	multicast content delivery, with the goal of finding a solution		multicast content delivery. Content Delivery Services with
	implemented at edges of the network based on IGMP or MLD. Content		different business models is cited as an application which could
	Delivery Services with different business models is cited as an		benefit from the capabilities of "well managed" IP multicasting
	application which could benefit from the capabilities of "well		described in this document.
	managed" IP multicasting described in this document.
	It is proposed that this document be used as a starting point for		It is proposed that this document be used as a starting point for
	discussing requirements for "well managed" IP multicasting services.		discussing requirements for "well managed" IP multicasting services.
	Normative References		Normative References
	[1] B. Cain, et. al., "Internet Group Management Protocol, Version		[1] B. Cain, et. al., "Internet Group Management Protocol, Version
	3", RFC3376, October 2002.		3", RFC3376, October 2002.
	[2] R. Vida, et. al., "Multicast Listener Discovery Version 2		[2] R. Vida, et. al., "Multicast Listener Discovery Version 2
	(MLDv2) for IPv6", RFC3810, June 2004.		(MLDv2) for IPv6", RFC3810, June 2004.
	skipping to change at page 17, line 6		skipping to change at page 17, line 6
	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
	Phone: +1 408 525 1952		Phone: +1 408 525 1952
	Email: svaidya@cisco.com		Email: svaidya@cisco.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on		This document and the information contained herein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND		REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
	EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT		EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
	skipping to change at page 17, line 44		skipping to change at line 759
	attempt made to obtain a general license or permission for the use		attempt made to obtain a general license or permission for the use
	of such proprietary rights by implementers or users of this		of such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository		specification can be obtained from the IETF on-line IPR repository
	at http://www.ietf.org/ipr.		at http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf		this standard. Please address the information to the IETF at ietf
	ipr@ietf.org.		ipr@ietf.org.
	Acknowledgement
	Funding for the RFC Editor function is currently provided by the
	Internet Society.
End of changes. 22 change blocks.
	44 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/