draft-ietf-mboned-maccnt-req-08.txt		draft-ietf-mboned-maccnt-req-09.txt
	mboned T. Hayashi		mboned T. Hayashi,
	Internet-Draft NTT Network Innovation		Internet-Draft H. Satou,
	Intended status: Informational Laboratories		Intended status: Informational H. Ohta
	Expires: January 14, 2010 H. He		Expires: September 6, 2010 NTT
			H.He
	Nortel		Nortel
	H. Satou
	H. Ohta
	NTT Network Service Systems
	Laboratories
	S. Vaidya		S. Vaidya
	Cisco Systems, Inc.		Cisco Systems, Inc.
	July 13, 2009		March 5, 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-08		draft-ietf-mboned-maccnt-req-09
	Status of this Memo
	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
	Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-
	Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 14, 2010.
	Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.
	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, Accounting and Authorization		limited to cases where Authentication, Authorization and Accounting
	(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
	Deliver System(CDS) using multicast, the memo presents three basic		Delivery Service(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
	capabilities including quality-of-service (QoS) related issues are		capabilities including quality-of-service (QoS) related issues are
	listed and the constituent logical functional components are		listed and the constituent logical functional components are
	presented.		presented.
	This memo assumes that the capabilities can be realized by		This memo assumes that the capabilities can be realized by
	integrating AAA functionalities with a multicast CDS system, with		integrating AAA functionalities with a multicast CDS system, with
	IGMP/MLD at the edge of the network.		IGMP/MLD at the edge of the network.
			Status of this Memo
			This Internet-Draft is submitted to IETF in full conformance with the
			provisions of BCP 78 and BCP 79.
			Internet-Drafts are working documents of the Internet Engineering
			Task Force (IETF), its areas, and its working groups. Note that
			other groups may also distribute working documents as Internet-
			Drafts.
			Internet-Drafts are draft documents valid for a maximum of six months
			and may be updated, replaced, or obsoleted by other documents at any
			time. It is inappropriate to use Internet-Drafts as reference
			material or to cite them other than as "work in progress."
			The list of current Internet-Drafts can be accessed at
			http://www.ietf.org/ietf/1id-abstracts.txt.
			The list of Internet-Draft Shadow Directories can be accessed at
			http://www.ietf.org/shadow.html.
			This Internet-Draft will expire on September 6, 2010.
	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 33		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, Accounting and Authorization		AAA: Authentication, Authorization and Accounting
	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 6, line 41		skipping to change at page 6, line 33
	A more complex version of this business model is conceivable in which		A more complex version of this business model is conceivable in which
	a CP may require a user to enter into a subscription contract, even		a CP may require a user to enter into a subscription contract, even
	when the user does not get billed for content consumption. For		when the user does not get billed for content consumption. For
	example, a CP may value individual data because it allows it to		example, a CP may value individual data because it allows it to
	supply the advertisers with rich, user-segmented data and charge a		supply the advertisers with rich, user-segmented data and charge a
	higher premium. In that case the requirements of the next section		higher premium. In that case the requirements of the next section
	"CDS with direct billing of the end user" are generally applicable		"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		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.		actual viewing (or stream downloading) data that the NSP has.
	4. Proposed Model: Multity-entity CDS with direct billing of the end		4. Proposed Model: Multity-entity CDS
	user
	In this model the networks for CDS contain three different types of		In this model the networks for CDS contain three different types of
	entities: Content Provider (CP), Network Service Provider (NSP), and		entities: Content Provider (CP), Network Service Provider (NSP), and
	user clients. An NSP owns the network resources (infrastructure).		user clients. An NSP owns the network resources (infrastructure).
	It accommodates content providers on one side and accommodates user		It accommodates content providers on one side and accommodates user
	clients on the other side. NSP provides the network for CDS to two		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		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		user through the network of NSPs and charges users for content. NSPs
	are responsible for delivering the content to user clients, and for		are responsible for delivering the content to user clients, and for
	controlling the network resources. A NSP charges a user or a CP for		controlling the network resources. A NSP charges a user or a CP for
	skipping to change at page 10, line 12		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. Performance requirements		6. Reauthorization and deauthorization requirements
			A mechanism for periodic reauthorization of users who have already
			joined a channel stream should be supported. The reauthorization
			could be an authorization check based on the NSP's eligibility
			requirements and/or could involve the NSP querying the CP for
			reauthorization of a user.
			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
			a reauthorization check. If a NSP revokes authorization for 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
			revokes authorization to content for a user the CP signals to the NSP
			to cease streaming to that user. An example usage case for
			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
			some models, it is conceivable that a CP could communicate 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
			requests unnecessary.
			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
	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. Leave and Join latencies impact		network stops streaming to the user. Leave and Join latencies impact
	the acceptable user experience for fast channel surfing. In an IP-TV		the acceptable user experience for fast channel surfing. In an IP-TV
	skipping to change at page 10, line 37		skipping to change at page 11, line 8
	Furthermore, leave affects resource consumption: with a low "leave		Furthermore, leave affects resource consumption: with a low "leave
	latency" network providers could minimize streaming content when		latency" network providers could minimize streaming content when
	there are no audiences. It is important that any overhead for		there are no audiences. It is important that any overhead for
	authentication, authorization, and access-control be minimized at the		authentication, authorization, and access-control be minimized at the
	times of joining and leaving multicast channels so as to achieve join		times of joining and leaving multicast channels so as to achieve join
	and leave latencies acceptable in terms of user experience. For		and leave latencies acceptable in terms of user experience. For
	example this is important in an IP-TV application, because users are		example this is important in an IP-TV application, because users are
	not going to be receptive to a slow response time when changing		not going to be receptive to a slow response time when changing
	channels.		channels.
	7. Concomitant requirements		8. Concomitant requirements
	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 be		network operators. NSP's multicast access and QoS policies should be
	manageable for large scale users. (e.g. millions of users, thousands		manageable for large scale users. (e.g. millions of users, thousands
	of edge-routers)		of edge-routers)
	Service and Terminal Portability:		Service and Terminal Portability:
	skipping to change at page 11, line 19		skipping to change at page 11, line 37
	unicasting when the "on-demand" nature of unicasting is not required.		unicasting when the "on-demand" nature of unicasting is not required.
	Therefore interfaces to multicasting should allow for easy		Therefore interfaces to multicasting should allow for easy
	integration into CDS systems that support unicasting. Especially		integration into CDS systems that support unicasting. Especially
	equivalent interfaces for authorization, access control and		equivalent interfaces for authorization, access control and
	accounting capabilities should be provided.		accounting capabilities should be provided.
	Support of ASM and SSM		Support of ASM and SSM
	Both ASM (G), and SSM (S,G) should be supported as multicast models.		Both ASM (G), and SSM (S,G) should be supported as multicast models.
			Support for Tunneled Multicast
			The AAA requirements specified in this document should apply to both
			end-to-end native multicast and to tunnel-enabled multicast, such as
			AMT multicast: [I-D.ietf-mboned-auto-multicast]
	Small Impact on the Existing Products		Small Impact on the Existing Products
	Impact on the existing products (e.g., protocols, software, etc.)		Impact on the existing products (e.g., protocols, software, etc.)
	should be as minimal as possible. Ideally the NSP should be able to		should be as minimal as possible. Ideally the NSP should be able to
	use the same infrastructure (such as access control) to support		use the same infrastructure (such as access control) to support
	commercial multicast services for the so called "triple play"		commercial multicast services for the so called "triple play"
	services: voice (VoIP), video, and broadband Internet access		services: voice (VoIP), video, and broadband Internet access
	services. When a CP requires the NSP to provide a level of QoS		services. When a CP requires the NSP to provide a level of QoS
	surpassing "best effort" delivery or to provide special services		surpassing "best effort" delivery or to provide special services
	(e.g., to limited users with specific attributes), certain parameters		(e.g., to limited users with specific attributes), certain parameters
	skipping to change at page 11, line 44		skipping to change at page 12, line 21
	AAA features. NSPs may offer tiered services, with higher QOS,		AAA features. NSPs may offer tiered services, with higher QOS,
	accounting, authentication, etc., depending on contractual relation		accounting, authentication, etc., depending on contractual relation
	with the CPs. It is therefore important that Multicast AAA and QoS		with the CPs. It is therefore important that Multicast AAA and QoS
	functions be as modular and flexible as possible.		functions be as modular and flexible as possible.
	Multicast Replication		Multicast Replication
	The above requirements should also apply if multicast replication is		The above requirements should also apply if multicast replication is
	being done on an access-node (e.g. DSLAMs or OLTs).		being done on an access-node (e.g. DSLAMs or OLTs).
	8. Constituent Logical Functional Components		9. Constituent Logical Functional Components
	Below is a diagram of a AAA enabled multicasting network, including		Below is a diagram of a AAA enabled multicasting network, including
	the logical components within the various entities.		the logical components within the various entities.
	+-------------------------------+		+-------------------------------+
	| user |		| user |
	|+- - - - - - - - - - - - - - -+|		|+- - - - - - - - - - - - - - -+|
	|| CPE ||		|| CPE ||
	|| ||		|| ||
	|+- - - - - | - - - - - - - - -+|		|+- - - - - | - - - - - - - - -+|
	skipping to change at page 13, line 47		skipping to change at page 14, line 47
	management (e.g. QoS management), as described in section 5,		management (e.g. QoS management), as described in section 5,
	"Admission Control for Multicasting". Resource management and		"Admission Control for Multicasting". Resource management and
	admission control is provided by MACF (Multicast Admission Control		admission control is provided by MACF (Multicast Admission Control
	Function). This means that, before replying to the user's multicast		Function). This means that, before replying to the user's multicast
	request, the mAAA queries the MACF for a network resource access		request, the mAAA queries the MACF for a network resource access
	decision over the interface IFd. The MACF is responsible for		decision over the interface IFd. The MACF is responsible for
	allocating network resources for forwarding multicast traffic. MACF		allocating network resources for forwarding multicast traffic. MACF
	also receives Leave information from NAS so that MACF releases		also receives Leave information from NAS so that MACF releases
	corresponding reserved resources.		corresponding reserved resources.
	9. Acknowledgments		10. Acknowledgments
	The authors of this draft would like to express their appreciation to		The authors of this draft would like to express their appreciation to
	Christian Jacquenet of France Telecom whose contributions to the "AAA		Christian Jacquenet of France Telecom whose contributions to the "AAA
	Framework for Multicasting" [draft-ietf-mboned-multiaaa-framework]		Framework for Multicasting" [draft-ietf-mboned-multiaaa-framework]
	largely influenced this draft, Pekka Savola of Netcore Ltd., Daniel		largely influenced this draft; Pekka Savola of Netcore Ltd.; Daniel
	Alvarez, and Toerless Eckert of Cisco Systems, Sam Sambasivan of		Alvarez, and Toerless Eckert of Cisco Systems; Sam Sambasivan of
	AT&T, Sanjay Wadhwa, Greg Shepherd, and Leonard Giuliano of Juniper,		AT&T; Sanjay Wadhwa, Greg Shepherd, and Leonard Giuliano of Juniper;
	Tom Anschutz and Steven Wright of BellSouth, Nicolai Leymann of		Tom Anschutz and Steven Wright of BellSouth; Nicolai Leymann of
	T-Systems, Bill Atwood of Concordia University, Carlos Garcia Braschi		T-Systems; Bill Atwood of Concordia University; Carlos Garcia Braschi
	of Telefonica Empresas, Marshall Eubanks in his role as mboned WG		of Telefonica Empresas; Mark Altom, Andy Huang, Tom Imburgia, Han
	chair, Ron Bonica in his role as Director as the Operations and		Nguyen, Doug Nortz of ATT Labs; Marshall Eubanks in his role as
	Management Area, Stephen Rife of NTT and David Meyer in his former		mboned WG chair; Ron Bonica in his role as Director as the Operations
	role as mboned WG chair, as well as their thanks to the participants		and Management Area; Stephen Rife of Digital Garage and David Meyer
	of the MBONED WG in general.		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.
	10. IANA Considerations		11. IANA Considerations
	This memo does not raise any IANA consideration issues.		This memo does not raise any IANA consideration issues.
	11. Security Considerations		12. 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 networks.		multicast networks by excluding ineligible clients from the networks.
	These requirements are not meant to address encryption issues. Any		These requirements are not meant to address encryption issues. 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.
	12. Privacy considerations		13. Privacy considerations
	Any solution which meets these requirements should weigh the benefits		Any solution which meets these requirements should weigh the benefits
	of user-based accounting with the privacy considerations of the user.		of user-based accounting with the privacy considerations of the user.
	For example solutions are encouraged when applicable to consider		For example solutions are encouraged when applicable to consider
	encryption of the content data between the content provider and the		encryption of the content data between the content provider and the
	user in such a way that the Network Provider does not know the		user in such a way that the Network Provider does not know the
	contents of the channel.		contents of the channel.
	13. Conclusion		14. 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 in multi-entity models. A few		enabled IP multicasting services in multi-entity models. A few
	models are evaluated with regard to their support by current		models are evaluated with regard to their support by current
	technologies. The "multi-entity CDS with direct billing of the end		technologies. The "multi-entity CDS with direct billing of the end
	user" model is presented and requirements for information sharing		user" model is presented and requirements for information sharing
	between entities and requirements for admission control to enable		between entities and requirements for admission control to enable
	guaranteeing of QoS are derived. Performance requirements and		guaranteeing of QoS are derived. Performance requirements and
	concomitant requirements are also presented.		concomitant requirements are also presented.
	14. Normative References		15. References
			15.1. Normative References
	[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to		[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
	Accounting Management", RFC 2975, October 2000.		Accounting Management", RFC 2975, October 2000.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol, Version
	3", RFC 3376, October 2002.		3", RFC 3376, October 2002.
	[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery		[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
	Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.		Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
			15.2. Informative References
			[I-D.ietf-mboned-auto-multicast]
			Thaler, D., Talwar, M., Aggarwal, A., Vicisano, L., and T.
			Pusateri, "Automatic IP Multicast Without Explicit Tunnels
			(AMT)", draft-ietf-mboned-auto-multicast-09 (work in
			progress), June 2008.
	Authors' Addresses		Authors' Addresses
	Tsunemasa Hayashi		Tsunemasa Hayashi
	NTT Network Innovation Laboratories		Nippon Telegraph and Telephone Corporation
	1-1 Hikarino'oka		1-1 Hikarino'oka
	Yokosuka-shi, Kanagawa 239-0847		Yokosuka-shi, Kanagawa 239-0847
	Japan		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
	Nortel
	600 Technology Park Drive
	Billerica, MA 01801
	USA
	Phone: +1 978 288 7482
	Email: haixiang@nortel.com
	Hiroaki Satou		Hiroaki Satou
	NTT Network Service Systems Laboratories		Nippon Telegraph and Telephone Corporation
	3-9-11 Midoricho		3-9-11 Midoricho
	Musashino-shi, Tokyo 180-8585		Musashino-shi, Tokyo 180-8585
	Japan		Japan
	Phone: +81 422 59 4683		Phone: +81 422 59 4683
	Email: satou.hiroaki@lab.ntt.co.jp		Email: satou.hiroaki@lab.ntt.co.jp
	Hiroshi Ohta		Hiroshi Ohta
	NTT Network Service Systems Laboratories		Nippon Telegraph and Telephone Corporation
	3-9-11 Midoricho		3-9-11 Midoricho
	Musashino-shi, Tokyo 180-8585		Musashino-shi, Tokyo 180-8585
	Japan		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
			Haixiang He
			Nortel
			600 Technology Park Drive
			Billerica, MA 01801
			USA
			Phone: +1 978 288 7482
			Email: haixiang@nortel.com
	Susheela Vaidya		Susheela Vaidya
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Phone: +1 408 525 1952		Phone: +1 408 525 1952
	Email: svaidya@cisco.com		Email: svaidya@cisco.com
			Copyright and License Notice
			Copyright (c) 2010 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info) in effect on the date of
			publication of this document. Please review these documents
			carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
			include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
			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.
End of changes. 27 change blocks.
	90 lines changed or deleted		103 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/