< draft-deng-multimob-ps-mobilemulticast-01.txt		draft-deng-multimob-ps-mobilemulticast-02.txt >
	Network Working Group H. Deng		Network Working Group H. Deng
	Internet-Draft China Mobile		Internet-Draft China Mobile
	Intended status: Standards Track P. Yang		Intended status: Standards Track P. Yang
	Expires: August 23, 2008 Hitachi (China) R&D Corporation		Expires: January 14, 2009 Hitachi
	Q. Wu		Q. Wu
	Tsinghua Univ.		Tsinghua Univ.
	February 20, 2008		July 13, 2008
	Problem Statement and Requirement: Mobile Multicast		Problem Statement and Requirement: Mobile Multicast
	draft-deng-multimob-ps-mobilemulticast-01		draft-deng-multimob-ps-mobilemulticast-02
	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
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on August 23, 2008.		This Internet-Draft will expire on January 14, 2009.
	Copyright Notice
	Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document discusses the problem and requirement of multicast		This document discusses the problem and requirement of multicast
	solution in the mobile networks. One current issue in mobile		solution in the mobile networks. One current issue in mobile
	multicast solution has been raised and requirements of mobile IPTV on		multicast solution has been raised and requirements of mobile IPTV on
	multicast mobility will also be summarized especially for some		multicast mobility will also be summarized especially for some
	mechanisms such as the tunneling, service capability and security		mechanisms such as the tunneling, service capability and security
	discussion which is basis of supporting the mobile IPTV applications.		discussion which is basis of supporting the mobile IPTV applications.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements on multicast mobility management for mobile		2. IP mobility management multicast support in mobile network . . 4
	IPTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Mobile IPTV multicast framework . . . . . . . . . . . . . 4
	2.1. (Mobile) IPTV multicast framework . . . . . . . . . . . . 5		2.2. Mobile IPv4 support Multicast . . . . . . . . . . . . . . 4
	2.2. Service Requirements Mobile IPTV multicast delivery . . . 5		2.3. Mobile IPv6 support Multicast . . . . . . . . . . . . . . 5
	2.3. Correspondence Mobile IPv6 to support Multicast for		3. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	mobile IPTV? . . . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	3. One Problem about Mobile Multicast . . . . . . . . . . . . . . 9		5. Normative References . . . . . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . . . 11
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	7.2. Informative References . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	While more and more operators begin to provide the wireless broadband		While more and more operators begin to provide the wireless broadband
	network systems, the needs for multicast and and broadcast service in		network systems, the needs for multicast and and broadcast service in
	mobile network become promising. Recently IPTV might become one of		mobile network become promising. Recently IPTV might become one of
	the killer applications for mobile network. Mobile IPTV service is a		the desirable applications for mobile network. Mobile IPTV service
	kind of A/V services which are combined with interactive data for the		is a kind of A/V services which are combined with interactive data
	related or supplementary information of A/V program using bi-		for the related or supplementary information of A/V program using bi-
	directional wireless broadband links. User can enjoy the downlink		directional wireless broadband links. User can enjoy the downlink
	A/V stream and access more detailed or value-added information via		A/V stream and access more detailed or value-added information via
	uplink simultaneously. Mobile IPTV service, which is also described		uplink simultaneously.
	as place-shifting IPTV service in [IPTV.SR.SC], basically is to
	ensure continuous and original IPTV experiences for the users who
	move to the other place from where he or she originally subscribed
	for.
	As specified in [IPTV.SR.SC], mobile IPTV (place-shifting) could be
	divided into two categories, depending on who is taking care of
	redistributing the IPTV traffic:
	The subscriber-based solution requires the device of subsrcriber to
	redistributes traffic to the place where the user is currently
	located.
	The network-based one need the service provider send the IPTV traffic
	to the moved place. while mobile IPTV users handover from one network
	domain to another network domain, the network side should guarantee
	the service continuity and smoothness.
	Mobile IPTV service is a mass multimedia group communication service.
	It has more requirements on network bandwidth and QoS/QoE compared
	with best effort data services. As desribed in [Schmidt07],
	multicast is optimal to support this kind of group communication
	service in mobile network. The problems and survey could be found in
	[Schmidt07]. This document only discusses the problems and
	requirement of mobile multicast.
	In the IPv6 network, Mobile IPv6 (MIPv6)[RFC3775] is the basic way to		In the mobile network, Mobile IPv4 (MIPv4)[RFC3344], Mobile
	support mobility. It allows the mobile nodes(MN) to maintain the		IPv6[RFC3775], DSMIP6 [DSMIPv6] and PMIP6[Gundavelli08]is the basic
	reachability while moving in the IPv6 network. After registration to		way to support IP mobility management. It allows the mobile
	home agent(HA), the packets destined to MN could be routed correctly		nodes(MN) to maintain the reachability while moving in the IP
	by using the end-to-end tunnel, while MN is away from the home		network. After registration to home agent(HA), the packets destined
	network. MIPv6 has some other extensions (HMIP6 [RFC4140], FMIP6		to MN could be routed correctly by using the tunneling mechanism,
	[RFC4068], PMIP6 [Gundavelli08])for different application schemes.		while MN is away from the home network.
	MIPv6 has two methods for multicast. [Schmidt07] has already
	analysis on the Prons and Cons of these two ways.
	Besides the MIP camp, there are some specific multicast solutions in		But the current IP mobility management mechanism lack of full support
	3GPP(MBMS)[MBMS] and 3GPP2 network(BCMCS)[BCMCS]. There is the		of multicast service.This document will illustrate the main issue of
	possiblity that access gateway may experience the overload to support		them. Since DSMIP6 is principally similar to MIP6, so it will not be
	this kind of services. Anyhow, In the real deployment, BCMCS/MBMS		illustrated independently in this document.
	may not always available anywhere in operators' cellular network,they
	could also support the mobile IPTV services in cellular networks.
	2. Requirements on multicast mobility management for mobile IPTV		2. IP mobility management multicast support in mobile network
	2.1. (Mobile) IPTV multicast framework		2.1. Mobile IPTV multicast framework
	[IPTV.MC.FR] and [IPTV.FR] make detailed description on IPTV		ITU make detailed description on IPTV architecture and multicast
	architecture and multicast framewroks. Mobile IPTV content delivery		framewroks. Mobile IPTV content delivery infrastructure may consists
	infrastructure may consists of four different layers, i.e. Content		of four different layers, i.e. Content Source, Core, Metro(Edge),
	Source, Core, Metro(Edge), and Access. Content source is where IPTV		and Access. Content source is where IPTV service contents are
	service contents are originated and they can be placed in either		originated and they can be placed in either inside or outside of
	inside or outside of delivery infrastructure. Core is service/		delivery infrastructure. Core is service/network provider_is
	network provider_is backbone infrastructure. Metro, in other words		backbone infrastructure. Metro, in other words Aggregation or Edge,
	Aggregation or Edge, is where it connects and aggregates between core		is where it connects and aggregates between core and access. Access
	and access. Access is user domain that includes last mile.		is user domain that includes last mile.
	The transport profile of Mobile IPTV are shown in the picture below:		The transport profile of Mobile IPTV are shown in the picture below:
	Wired or Wireless		Wired or Wireless
	|		|
	| +.........................................+		| +.........................................+
	+----------+ | . Mobile IPTV Transport Profile .		+----------+ | . Mobile IPTV Transport Profile .
	| Mobile | V . +--------+ +------+ +------+ .		| Mobile | V . +--------+ +------+ +------+ .
	| IPTV |---------| Access |------| Edge |------| Core | .		| IPTV |---------| Access |------| Edge |------| Core | .
	| Terminal | . +--------+ +------+ +------+ .		| Terminal | . +--------+ +------+ +------+ .
	skipping to change at page 5, line 40 ¶		skipping to change at page 4, line 40 ¶
	. +-------------+ || || .		. +-------------+ || || .
	. | Content |==============|| || .		. | Content |==============|| || .
	. | Source | || .		. | Source | || .
	. +-------------+ || .		. +-------------+ || .
	+................\\...................||..+		+................\\...................||..+
	\\ ||		\\ ||
	+----------------+ ||		+----------------+ ||
	| content source |==		| content source |==
	+----------------+		+----------------+
	Besides the functions showen in the picture above, multicast delivery		In the case of IPTV support in mobile network, such architecture will
	control functions are needed for the Mobile IPTV Transport profile.		be considered and mapped to the network entity of IP mobility
	They may be responsible for the multicast tree managerment,		management.
	membership management, authentication and authorization of members,
	QoS management, load and traffic mamangement
	2.2. Service Requirements Mobile IPTV multicast delivery
	[IPTV.SR.REQ] specified the service requirements of (Mobile) IPTV.
	[IPTV.QoE.REQ] gives the requirements related to QoS and QoE. Mobile
	IPTV service includes multiple type of services, such as video,
	audio, data(captures, EPG, etc.). Video service need much bandwidth
	and also should be a service with high service quality. Network
	should implement traffic control for high priority multicast traffic
	to ensure the QOS of multicast. Specifically, following functions
	should be supported in the mobile network:
	(1)Total Multicast Bandwidth: access node should be able to control
	on total bandwidth of a user port that can be used for multicast
	service;
	(2)Current Available Bandwidth: the access node should be able to
	aware of current available bandwidth that can be used for multicast
	service, specifically, can be total multicast bandwidth consumed
	multicast bandwidth;
	(3)Connection Admission Control (CAC): It is required that Connection
	Admission Control supported in Access network based on available
	resources. When end user subscribes to a multicast stream, access
	network will perform CAC: check if current available resources are
	enough for the new service subscription. The resources can be
	bandwidth, connection number and user service privilege profile.
	(4) Network Attachment Control: The attachment control should be		2.2. Mobile IPv4 support Multicast
	supported by the multicast control function and multicast replication
	function. The multicast control function should build the privilege
	table for multicast users, and the multicast replication function
	should forward multicast media content to users which have the
	privilege of IPTV multicast services.
	(5) Packet loss: depending on the bit rate and video/audio profiles,		Section 4.3 and 4.4 of [RFC3344] discuss the support of multicast and
	the video and audio streams have different levels of sensitiveness on		broadcast. In order to receive multicast packet through it's home
	packet loss. [IPTV.QoE.REQ] gives the detail of packet loss		network, a mobile node MUST join the multicast group in one of two
	requirements for all kinds of real-time mobile IPTV media streams.		ways. One is based on co-located care-of address, the other is based
	The multicast mobile network should gurantee not only the duration of		on the home address (foreign agent care-of address). In both cases,
	single error, but also the total packet loss rate. Besides the		a mobile node tunnels IGMP messages to its home agent, the home agent
	packet loss at radio interface, the multicast handoff will also incur		forwards multicast datagrams down the tunnel to the mobile node.
	some packet loss.
	(6) Packet priority: considering the video/audio compression		Access network
	characteristics, different packets may have different importance. It		(Wired or Wireless) IP multicast
	is recommended to provide better guarantee for important packets.		| packets
			+----+ | |
			| MN1| V +------+ +------+ |
			+----+---------------|======|=============| | |
			+----+ | FA | | HA | V
			| MN2|---------------|======|=============| |-----
			+----+ +------+ +------+
	(7) Synchronization: Mobile IPTV services is also an integrated		Figure 1: Nested tunneling in MIP4 for Multicast
	service with synchronized multiple streams. Although the service
	provider and the terminal may have some solution to maintain
	synchronized streams, the mobile network may also incur delay and
	jitter. So, the mobile multicast should provide some machenism to
	ensure the synchronization of mobile IPTV streams.
	(8) Notification: there are some mobile IPTV service events, which		In the case of co-located care-of address, the home agent SHOULD
	will trigger notification messages. The multicast mobile network		tunnel the datagram to this care-of address directly; In the case of
	should understand such kind of notifications and make the actions		foreign agent care-of address, the home agent MUST first encapsulate
	accordingly. In this sense, a notifiction solution among the nodes		the datagram in a unicast datagram addressed to the mobile node's
	of multicast mobile network mya be useful.		home address and then MUST tunnel the resulting datagram (nested
			tunneling) to the mobile node's care-of address.If there are more
			than 500 MNs under the same FA, there will be 500 tunnels between HA
			and FA to transmit multicast packets.
	2.3. Correspondence Mobile IPv6 to support Multicast for mobile IPTV?		2.3. Mobile IPv6 support Multicast
	Many works have made the analysis on the multicast solution in mobile		In this document, the analysis on multicast of mobile IPv6 will be
	IPv6. [Schmidt07] has the summary of all the related works. In this		made only based on mobile IPTV. The Home Agent(HA) may be part of
	document, the analysis on multicast of mobile IPv6 will be made only		the core function in the mobile IPTV framework. The edge function
	based on mobile IPTV. The Home Agent(HA) may be part of the core		normally coould be considered as the access gateway(AGW) in the
	function in the mobile IPTV framework. The edge function normally		deployment of mobile IPv6 in mobile network.
	coould be considered as the access gateway(AGW) in the deployment of
	mobile IPv6 in mobile network.
	Access network		Access network
	(Wired or Wireless) IP multicast		(Wired or Wireless) IP multicast
	+------+ | packets		+------+ | packets
	| | | |		| | | |
	| MN | V +------+ +------+ |		| MN | V +------+ +------+ |
	| |===============|======|=============| | |		| |===============|======|=============| | |
	+------+ | | | | V		+------+ | | | | V
	bi-dictional tunnel | AR | | HA |-----		bi-dictional tunnel | AR | | HA |-----
	+------+ | | | |		+------+ | | | |
	| |===============|======|=============| |		| |===============|======|=============| |
	| MN | +------+ +------+		| MN | +------+ +------+
	| |		| |
	+------+		+------+
	Bandwidth efficiency: The advantage of the bi-directional tunneling		Figure 2: Nested tunneling in MIP6 for Multicast
	solution (as the above figure) is its simplicity and the transparency
	of handover to the multicast operation. This approach is inefficient
	because of the tunnel overhead and delay. The multiple unicasting
	tunneling problem for multicast between HA and MN should be solved to
	improve the bandwidth efficientcy (as the below figure). In the
	deployment of mobile IPv6 in wireless network (cellular, WLAN or
	WIMAX), HA (core) is relatively close to the AGW(Edge). So, the
	delay issue because of triangle tunneling may not be so severe.
	Access network
	(Wired or Wireless) IP multicast
	+------+ | packets
	| | | |
	| MN | V +------+ +------+ |
	| |===============|======| | | |
	+------+ | | | | V
	bi-dictional tunnel | AR |=============| HA |-----
	+------+ | | | |
	| |===============|======| | |
	| MN | +------+ +------+
	| |
	+------+
	Packet loss: the mobile IPTV services consist of real-time video/
	audio streams. So, the short delay/seamless multicast handoff of
	mobile IPv6 is surely useful.
	Synchronization: the requirements include the synchronization among
	all the nodes of mobile IPv6 and the synchronization between the
	mobile IPTV streams. Firstly, a precise time reference is needed in
	the multicast mobile network. Secondly, the synchronization
	information is necessary in the mobile IPTV streams. Lastly, some
	notification messages may be useful to share some time-based mobile
	IPTV events among mobile IPv6 nodes. It's also useful for precise
	mobile IPTV and multicast network charging.Proxy Mobile IPv6 has some
	basic requirement about synchronization between LMA and MAG for
	several considerations.
	Notification: it's recommended to have some notification machenism in		Notification: it's recommended to have some notification machenism in
	mobile IPv6. It's useful to do synchronous actions for incoming		mobile IPv6. It's useful to do synchronous actions for incoming
	mobile IPTV service events.		mobile IPTV service events.
	3. One Problem about Mobile Multicast		By the way, it is recommended that DSMIP6 has similar situation, and
			Proxy mobile IPv6 will be described in a seperate document.
	The current MBMS which is defined in 3GPP [MBMS] may experience
	overload for each network entity such as access gateway and
	broadcast/multicast server, in the case of mobile node frequently
	join and quit from the multicast group, multicast service
	announcement may also need to be reconsidered.
	4. Security Considerations		3. Security Considerations
	Multicast security is one of the most crucial issues in mobile IPTV		Multicast security is one of the most crucial issues in mobile IPTV
	service such that it is required to provide security capabilities to		service such that it is required to provide security capabilities to
	protect mobile IPTV multicast network from any malicious attempts		protect mobile IPTV multicast network from any malicious attempts
	caused by multicast security holes. Security itself is too diverse		caused by multicast security holes such as denial of service attacks.
	to break down to the specific multicast purpose; however functional
	requirements of multicast security for each network elements should
	be clearly defined and should provide capabilities along with the
	definitions.
	As specified in [IPTV.SEC], the mobile IPTV security requirements may
	have following aspects:
	- IPTV architecture is required to be robust against denial of
	service attacks targeting any multicast mechanisms.
	- Multicast system architecture is required to provide a mechanism of
	multicast protocol adjacency authentication in order to establish a
	reliable peer.
	- Multicast system architecture is required to provide an admission
	control mechanism to regulate any multicast events.
	- Multicast system architecture is required to be independent of
	adjacent domain such that it shall not affect the adjacent multicast
	domain without permission.
	- Multicast system architecture is required to provide a mechanism to		After the integration IP mobility management like MIP4, MIP6 with the
	check integrity of multicast contents before service delivery such		multicast service, it should not depreciate the security protection
	that it prevents unauthorized contents from becoming the content		of the basic IP mobility management mechanism.
	source.
	5. IANA Considerations		4. IANA Considerations
	This document makes no requests to IANA.		This document makes no requests to IANA.
	6. Conclusion		5. Normative References
	This draft discusses multicast mobility for mobile network and mobile
	IPTV services. Firstly the mobile IPTV multicast framework is
	described followed by its the requirements on multicast mobile
	networks. The impacts on current mobile IPv6 multicast solutions are
	also discussed based on the requirements of mobile IPTV. Security
	issues are discussed lastly in this document.
	7. References
	7.1. Normative References		[DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts and
			Routers (DSMIPv6)",
			draft-ietf-mip6-nemo-v4traversal-06.txt (work in
			progress), November 2007.
	[Gundavelli08]		[Gundavelli08]
	Gundavelli, S., "Proxy Mobile IPv6",		Gundavelli, S., "Proxy Mobile IPv6",
	draft-ietf-netlmm-proxymip6-10.txt (work in progress),		draft-ietf-netlmm-proxymip6-18.txt (work in progress),
	February 2008.		May 2008.
			[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
			August 2002.
	[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	in IPv6", RFC 3775, June 2004.		in IPv6", RFC 3775, June 2004.
	7.2. Informative References
	[BCMCS] 3GPP2, "Broadcast/Multicast Services - Stage 1, Revision
	A", 3GPP2 S.R0030-A V1.0, Feb. 2004.
	[IPTV.FR] Xie, W. and Will. , "IPTV Architecture", ITU-T IPTV Focus
	Group on IPTV FG-IPTV-DOC-0084, May 2007.
	[IPTV.MC.FR]
	Seo, Y., "IPTV Multicast Frameworks", ITU-T IPTV Focus
	Group on IPTV FG-IPTV-DOC-0092, May 2007.
	[IPTV.QoE.REQ]
	Takahashi, A., "Quality of Experience Requirements for
	IPTV", ITU-T IPTV Focus Group on IPTV FG-IPTV-DOC-0086,
	May 2007.
	[IPTV.SEC]
	Xie, W., "IPTV Security Aspects", ITU-T IPTV Focus Group
	on IPTV FG-IPTV-DOC-0090, May 2007.
	[IPTV.SR.REQ]
	Becha, B., "IPTV service requirements", ITU-T IPTV Focus
	Group on IPTV FG-IPTV-DOC-0083, May 2007.
	[IPTV.SR.SC]
	Li, M., "IPTV service scenarios", ITU-T IPTV Focus Group
	on IPTV FG-IPTV-DOC-0085, May 2007.
	[MBMS] 3GPP, "Multimedia Broadcast/Multicast Service (MBMS)
	Architecture and functional description", 3GPP TS
	23.246 V8.0.0, September 2007.
	[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
	July 2005.
	[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
	Bellier, "Hierarchical Mobile IPv6 Mobility Management
	(HMIPv6)", RFC 4140, August 2005.
	[Schmidt07]
	Schmidt, T., "Multicast Mobility in MIPv6: Problem
	Statement and Brief Survey",
	draft-irtf-mobopts-mmcastv6-ps-02.txt (work in progress),
	November 2007.
	Authors' Addresses		Authors' Addresses
	Hui Deng		Hui Deng
	China Mobile		China Mobile
	53A,Xibianmennei Ave.,		53A,Xibianmennei Ave.,
	Xuanwu District,		Xuanwu District,
	Beijing 100053		Beijing 100053
	China		China
	Email: denghui02@gmail.com		Email: denghui02@gmail.com
	Peng Yang		Peng Yang
	Hitachi (China) R&D Corporation		Hitachi
	301, North Wing, Tower C Raycom Infotech Park		301, North Wing, Tower C Raycom Infotech Park
	2 kexueyuan Nanlu		2 kexueyuan Nanlu
	Haidian District		Haidian District
	Beijing, 100080		Beijing, 100080
	P.R. China		P.R. China
	Phone: +861082862918(ext.)328		Phone: +861082862918(ext.)328
	Email: pyang@hitachi.cn		Email: pyang@hitachi.cn
	Qian Wu		Qian Wu
	skipping to change at page 16, line 44 ¶		skipping to change at line 283 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		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		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 32 change blocks.
	279 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/