draft-ietf-avt-rtp-and-rtcp-mux-00.txt		draft-ietf-avt-rtp-and-rtcp-mux-01.txt
	Network Working Group C. Perkins		Network Working Group C. Perkins
	Internet-Draft University of Glasgow		Internet-Draft University of Glasgow
	Updates: 3550 (if approved) M. Westerlund		Updates: 3550 (if approved) M. Westerlund
	Expires: April 2, 2007 Ericsson		Intended status: Standards Track Ericsson
	September 29, 2006		Expires: April 23, 2007 October 20, 2006
	Multiplexing RTP Data and Control Packets on a Single Port		Multiplexing RTP Data and Control Packets on a Single Port
	draft-ietf-avt-rtp-and-rtcp-mux-00.txt		draft-ietf-avt-rtp-and-rtcp-mux-01.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
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 April 2, 2007.		This Internet-Draft will expire on April 23, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This memo discusses issues that arise when multiplexing RTP data		This memo discusses issues that arise when multiplexing RTP data
	packets and RTP control protocol (RTCP) packets on a single UDP port.		packets and RTP control protocol (RTCP) packets on a single UDP port.
	It updates RFC 3550 to describe when such multiplexing is, and is		It updates RFC 3550 to describe when such multiplexing is, and is
	skipping to change at page 2, line 13		skipping to change at page 2, line 13
	(SDP) can be used to signal multiplexed sessions.		(SDP) can be used to signal multiplexed sessions.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4		4. Distinguishable RTP and RTCP Packets . . . . . . . . . . . . . 4
	5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5		5. Multiplexing RTP and RTCP on a Single Port . . . . . . . . . . 5
	5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6		5.1. Unicast Sessions . . . . . . . . . . . . . . . . . . . . . 6
	5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 7		5.1.1. SDP Signalling . . . . . . . . . . . . . . . . . . . . 6
	5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 7		5.1.2. Interactions with SIP forking . . . . . . . . . . . . 7
	6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 8		5.1.3. Interactions with ICE . . . . . . . . . . . . . . . . 7
			5.1.4. Interactions with Header Compression . . . . . . . . . 7
			5.2. Any Source Multicast Sessions . . . . . . . . . . . . . . 8
			5.3. Source Specific Multicast Sessions . . . . . . . . . . . . 8
			6. Multiplexing, Bandwidth, and Quality of Service . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . . 10		10.2. Informative References . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Real-time Transport Protocol (RTP) [1] comprises two components:		The Real-time Transport Protocol (RTP) [1] comprises two components:
	a data transfer protocol, and an associated control protocol (RTCP).		a data transfer protocol, and an associated control protocol (RTCP).
	Historically, RTP and RTCP have been run on separate UDP ports. With		Historically, RTP and RTCP have been run on separate UDP ports. With
	increased use of Network Address Translation (NAT) this has become		increased use of Network Address Translation (NAT) this has become
	problematic, since opening multiple NAT pinholes can be costly. This		problematic, since opening multiple NAT pinholes can be costly. This
	memo discusses how the RTP and RTCP flows for a single media type can		memo discusses how the RTP and RTCP flows for a single media type can
	be run on a single port, to ease NAT traversal, and considers when		be run on a single port, to ease NAT traversal, and considers when
	skipping to change at page 6, line 10		skipping to change at page 6, line 10
	The procedures for multiplexing RTP and RTCP on a single port depend		The procedures for multiplexing RTP and RTCP on a single port depend
	on whether the session is a unicast session or a multicast session.		on whether the session is a unicast session or a multicast session.
	For a multicast sessions, also depends whether ASM or SSM multicast		For a multicast sessions, also depends whether ASM or SSM multicast
	is to be used.		is to be used.
	5.1. Unicast Sessions		5.1. Unicast Sessions
	It is acceptable to multiplex RTP and RTCP packets on a single UDP		It is acceptable to multiplex RTP and RTCP packets on a single UDP
	port to ease NAT traversal for unicast sessions, provided the RTP		port to ease NAT traversal for unicast sessions, provided the RTP
	payload types used in the session are chosen according to the rules		payload types used in the session are chosen according to the rules
	in Section 4.		in Section 4. The following sections describe how such multiplexed
			sessions can be signalled using the Session Initiation Protocol (SIP)
			with the offer/answer model.
			5.1.1. SDP Signalling
	When the Session Description Protocol (SDP) [8] is used to negotiate		When the Session Description Protocol (SDP) [8] is used to negotiate
	RTP sessions according to the offer/answer model [9], the "a=rtcp:"		RTP sessions according to the offer/answer model [9], the "a=rtcp:"
	attribute [10] is used to indicate the port chosen for RTCP traffic,		attribute [10] is used to indicate the port chosen for RTCP traffic
	if the default of using an odd/even port pair is not desirable. If		if the default of using an odd/even port pair is not desirable. If
	RTP and RTCP are to be multiplexed on a single port, this attribute		RTP and RTCP are to be multiplexed on a single port, this attribute
	MUST be included in the initial SDP offer, and MUST indicate the the		MUST be included in the initial SDP offer, and MUST indicate the same
	same port as included in the "m=" line. For example:		port as included in the "m=" line. For example:
	v=0		v=0
	o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e		o=csp 1153134164 1153134164 IN IP6 2001:DB8::211:24ff:fea3:7a2e
	s=-		s=-
	c=IN IP6 2001:DB8::211:24ff:fea3:7a2e		c=IN IP6 2001:DB8::211:24ff:fea3:7a2e
	t=1153134164 1153137764		t=1153134164 1153137764
	m=audio 49170 RTP/AVP 97		m=audio 49170 RTP/AVP 97
	a=rtpmap:97 iLBC/8000		a=rtpmap:97 iLBC/8000
	a=rtcp:49170		a=rtcp:49170
	This offer denotes a unicast voice-over-IP session using the RTP/AVP		This offer denotes a unicast voice-over-IP session using the RTP/AVP
	profile with iLBC coding. The answerer is requested to send both RTP		profile with iLBC coding. The answerer is requested to send both RTP
	and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.		and RTCP to port 49170 on IPv6 address 2001:DB8::211:24ff:fea3:7a2e.
	If the answerer supports multiplexing of RTP and RTCP onto a single		If the answerer supports multiplexing of RTP and RTCP onto a single
	port it MUST include an "a=rtcp:" attribute in the answer. The port		port it MUST include an "a=rtcp:" attribute in the answer, and the
	specified in that attribute MUST be the same as that used for RTP in		port specified in that attribute MUST be the same as that used for
	the "m=" line of the answer. The RTP payload types used MUST conform		RTP in the "m=" line of the answer. The RTP payload types used in
	to the rules in Section 4, and the answer MUST be rejected if there		the answer MUST conform to the rules in Section 4.
	is a conflict between the chosen RTP payload types and the expected
	RTCP packet types.
	If the answer does not contain an "a=rtcp:" attribute, the offerer		If the answer does not contain an "a=rtcp:" attribute, the offerer
	MUST NOT multiplex RTP and RTCP packets on a single port. Instead,		MUST NOT multiplex RTP and RTCP packets on a single port. Instead,
	it must send and receive RTCP on a port allocated according to the		it must send and receive RTCP on a port allocated according to the
	usual port pair rules. This will occur when talking to a peer that		usual port pair rules. This will occur when talking to a peer that
	does not understand the "a=rtcp:" attribute or this specification.		does not understand the "a=rtcp:" attribute or this specification.
	If the answer contains an "a=rtcp:" attribute, but that attribute
	specifies a different port for RTCP than for RTP, then the answer
	MUST be rejected, and the session re-negotiated using separate RTP
	and RTCP ports.
	Answerers which support the "a=rtcp:" attribute but do not understand		Answerers which support the "a=rtcp:" attribute but do not understand
	this memo should reject sessions where the RTP and RTCP ports are the		this memo should return an answer which does not contain an "a=rtcp:"
	same (Section 11 of [1] prohibits such sessions unless the mechanisms		attribute (since Section 11 of [1] prohibits such sessions unless the
	described in this memo are used). It is likely that this is a poorly		mechanisms described in this memo are used). It is likely that this
	tested feature of older implementations, however, and implementations		is a poorly tested feature of older implementations, however, and
	should be robust to unexpected behaviour. If the offerer suspects a		implementations should be robust to unexpected behaviour.
	session was rejected due to the presence of multiplexed RTP and RTCP,
	it MAY retry the offer using separate ports for RTP and RTCP.
	When using SIP with a forking proxy, it is possible that multiple 200		5.1.2. Interactions with SIP forking
	(OK) answers will be received, some supporting multiplexed RTP and
	RTCP, some not. This is not an issue if a separate RTP session is
	established with each answerer, since multiplexing occurs on a per
	session basis, but does prevent a single RTP session being opened
	between the offerer and all answerers.
	TODO: expand this discussion. Does SIP define if this should be a		When using SIP with a forking proxy, it is possible that an INVITE
	single RTP session or multiple sessions?		request may result in multiple 200 (OK) responses. If RTP and RTCP
			multiplexing is offered in that INVITE, it is important to be aware
			that some answerers may support multiplexed RTP and RTCP, some not.
			This will require the offerer listen for RTCP on both the RTP port
			and the usual RTCP port, and to send RTCP on both ports, unless
			branches of the call that support multiplexing are re-negotiated to
			use separate RTP and RTCP ports.
	TODO: discuss interactions between multiplexed RTP and RTCP, and		5.1.3. Interactions with ICE
	Interactive Connectivity Establishment (ICE) [15].
			It is common to use the Interactive Connectivity Establishment (ICE)
			[15] methodology to establish RTP sessions in the presence of Network
			Address Translation (NAT) devices or other middleboxes. An RTP media
			stream usually comprises two components in ICE (one for RTP and one
			for RTCP), and connectivity checks are performed for each component.
			The RTCP port must always be explicitly signalled using the "a=rtcp:"
			attribute when using ICE.
			When RTP and RTCP are to be multiplexed on a single UDP port, there
			is no need to perform ICE checks for the RTCP traffic. Accordingly,
			each RTP stream MUST be treated as comprising only a single component
			when multiplexing is in use (this can be detected by the port on the
			"a=rtcp:" line matching that on the "m=" line). Multiplexing RTP and
			RTCP therefore cuts the number of ICE checks that must be performed
			in half.
			5.1.4. Interactions with Header Compression
			Multiplexing RTP and RTCP packets onto a single port may negatively
			impact header compression schemes, for example Compressed RTP (CRTP)
			[16] and RObust Header Compression (ROHC) [17]. Header compression
			exploits patterns of change in the RTP headers of consecutive packets
			to send an indication that the packet changed in the expected way,
			rather than sending the complete header each time. This can lead to
			significant bandwidth savings if flows have uniform behaviour. The
			presence of RTCP packets multiplexed with RTP data packets disrupts
			these patterns, however, and can significantly reduce the gains
			available due to header compression.
			This effect may be especially significant in those environments, such
			as some wireless telephony systems, which rely on the efficiency of
			header compression to match the media to a limited capacity channel.
			The implications of multiplexing RTP and RTCP should be carefully
			considered before use in such environments.
	5.2. Any Source Multicast Sessions		5.2. Any Source Multicast Sessions
	The problem of NAT traversal is less severe for any source multicast		The problem of NAT traversal is less severe for any source multicast
	(ASM) RTP sessions than for unicast RTP sessions, and the benefit of		(ASM) RTP sessions than for unicast RTP sessions, and the benefit of
	using separate ports for RTP and RTCP is greater, due to the ability		using separate ports for RTP and RTCP is greater, due to the ability
	to support third party RTCP only monitors. Accordingly, RTP and RTCP		to support third party RTCP only monitors. Accordingly, RTP and RTCP
	packets SHOULD NOT be multiplexed onto a single port when using ASM		packets SHOULD NOT be multiplexed onto a single port when using ASM
	multicast RTP sessions, and SHOULD instead use separate ports and		multicast RTP sessions, and SHOULD instead use separate ports and
	multicast groups.		multicast groups.
	skipping to change at page 8, line 38		skipping to change at page 9, line 21
	packets on the SSM channel, even if sent on a separate port).		packets on the SSM channel, even if sent on a separate port).
	6. Multiplexing, Bandwidth, and Quality of Service		6. Multiplexing, Bandwidth, and Quality of Service
	Multiplexing RTP and RTCP has implications on the use of Quality of		Multiplexing RTP and RTCP has implications on the use of Quality of
	Service (QoS) mechanism that handles flow that are determined by a		Service (QoS) mechanism that handles flow that are determined by a
	three or five tuple (protocol, port and address for source and/or		three or five tuple (protocol, port and address for source and/or
	destination). In these cases the RTCP flow will be merged with the		destination). In these cases the RTCP flow will be merged with the
	RTP flow when multiplexing them together. Thus the RTCP bandwidth		RTP flow when multiplexing them together. Thus the RTCP bandwidth
	requirement needs to be considered when doing QoS reservations for		requirement needs to be considered when doing QoS reservations for
	the combinded RTP and RTCP flow. However from an RTCP perspective it		the combined RTP and RTCP flow. However from an RTCP perspective it
	is beneficial to receive the same treatment of RTCP packets as for		is beneficial to receive the same treatment of RTCP packets as for
	RTP as it provides more accurate statistics for the measurements		RTP as it provides more accurate statistics for the measurements
	performed by RTCP.		performed by RTCP.
	The bandwidth required for a multiplexed stream comprises the session		The bandwidth required for a multiplexed stream comprises the session
	bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the		bandwidth of the RTP stream, plus the bandwidth used by RTCP. In the
	usual case, the RTP session bandwidth is signalled in the SDP "b=AS:"		usual case, the RTP session bandwidth is signalled in the SDP "b=AS:"
	line, and the RTCP traffic is limited to 5% of this value. Any QoS		line, and the RTCP traffic is limited to 5% of this value. Any QoS
	reservation SHOULD therefore be made for 105% of the "b=AS:" value.		reservation SHOULD therefore be made for 105% of the "b=AS:" value.
	If a non-standard RTCP bandwidth fraction is used, signalled by the		If a non-standard RTCP bandwidth fraction is used, signalled by the
	skipping to change at page 9, line 31		skipping to change at page 10, line 14
	have been demultiplexed, cryptographic processing happens in the		have been demultiplexed, cryptographic processing happens in the
	usual manner.		usual manner.
	8. IANA Considerations		8. IANA Considerations
	No IANA actions are required.		No IANA actions are required.
	9. Acknowledgements		9. Acknowledgements
	We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar		We wish to thank Steve Casner, Joerg Ott, Christer Holmberg, Gunnar
	Hellstrom, Randell Jesup, Hadriel Kaplan and Harikishan Desineni for		Hellstrom, Randell Jesup, Hadriel Kaplan, Harikishan Desineni, and
	their comments on this memo. This work is supported in part by the		Stephan Wenger for their comments on this memo. This work is
	UK Engineering and Physical Sciences Research Council.		supported in part by the UK Engineering and Physical Sciences
			Research Council.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,		[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
	"RTP: A Transport Protocol for Real-Time Applications", STD 64,		"RTP: A Transport Protocol for Real-Time Applications", STD 64,
	RFC 3550, July 2003.		RFC 3550, July 2003.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	skipping to change at page 11, line 5		skipping to change at page 11, line 34
	[14] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM		[14] Casner, S. and S. Deering, "First IETF Internet Audiocast", ACM
	SIGCOMM Computer Communication Review, Volume 22, Number 3,		SIGCOMM Computer Communication Review, Volume 22, Number 3,
	July 1992.		July 1992.
	[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A		[15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
	Methodology for Network Address Translator (NAT) Traversal for		Methodology for Network Address Translator (NAT) Traversal for
	Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in		Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in
	progress), August 2006.		progress), August 2006.
			[16] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
			Low-Speed Serial Links", RFC 2508, February 1999.
			[17] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
			Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K.,
			Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
			Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
			Framework and four profiles: RTP, UDP, ESP, and uncompressed",
			RFC 3095, July 2001.
	Authors' Addresses		Authors' Addresses
	Colin Perkins		Colin Perkins
	University of Glasgow		University of Glasgow
	Department of Computing Science		Department of Computing Science
	17 Lilybank Gardens		17 Lilybank Gardens
	Glasgow G12 8QQ		Glasgow G12 8QQ
	UK		UK
	Email: csp@csperkins.org		Email: csp@csperkins.org
	Magnus Westerlund		Magnus Westerlund
	Ericsson		Ericsson
	Torshamgatan 23		Torshamgatan 23
	Stockholm SE-164 80		Stockholm SE-164 80
	Sweden		Sweden
	Email: magnus.westerlund@ericsson.com		Email: magnus.westerlund@ericsson.com
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			This document is subject to the rights, licenses and restrictions
			contained in BCP 78, and except as set forth therein, the authors
			retain all their rights.
			This document and the information contained herein are provided on an
			"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
			OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
			ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
			INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
			INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
			WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 12, line 29		skipping to change at page 13, line 45
	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.
	Disclaimer of Validity
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement
	Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 21 change blocks.
	66 lines changed or deleted		112 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/