draft-ietf-grow-mrt-08.txt		draft-ietf-grow-mrt-09.txt
	Network Working Group L. Blunk		Network Working Group L. Blunk
	Internet-Draft M. Karir		Internet-Draft M. Karir
	Intended status: Standards Track Merit Network		Intended status: Standards Track Merit Network
	Expires: January 15, 2009 C. Labovitz		Expires: August 29, 2009 C. Labovitz
	Arbor Networks		Arbor Networks
	July 14, 2008		February 25, 2009
	MRT routing information export format		MRT routing information export format
	draft-ietf-grow-mrt-08.txt		draft-ietf-grow-mrt-09.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	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.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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 January 15, 2009.		This Internet-Draft will expire on August 29, 2009.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		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 document describes the MRT format for routing information		This document describes the MRT format for routing information
	export. This format was developed in concert with the Multi-threaded		export. This format was developed in concert with the Multi-threaded
	Routing Toolkit (MRT) from whence the format takes it name. The		Routing Toolkit (MRT) from whence the format takes it name. The
	format can be used to export routing protocol messages, state		format can be used to export routing protocol messages, state
	changes, and routing information base contents.		changes, and routing information base contents.
	Table of Contents		Table of Contents
	skipping to change at page 3, line 47		skipping to change at page 4, line 4
	A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22		A.1.2. DIE Type . . . . . . . . . . . . . . . . . . . . . . . 22
	A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22		A.1.3. PEER_DOWN Type . . . . . . . . . . . . . . . . . . . . 22
	A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22		A.2. Deprecated MRT Routing Information Types . . . . . . . . . 22
	A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22		A.2.1. BGP Type . . . . . . . . . . . . . . . . . . . . . . . 22
	A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25		A.2.2. RIP Type . . . . . . . . . . . . . . . . . . . . . . . 25
	A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25		A.2.3. IDRP Type . . . . . . . . . . . . . . . . . . . . . . 25
	A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25		A.2.4. RIPNG Type . . . . . . . . . . . . . . . . . . . . . . 25
	A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26		A.2.5. BGP4PLUS and BGP4PLUS_01 Types . . . . . . . . . . . . 26
	A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26		A.2.6. Deprecated BGP4MP Subtypes . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
	Intellectual Property and Copyright Statements . . . . . . . . . . 29
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	Researchers and engineers often wish to analyze network behavior by		Researchers and engineers often wish to analyze network behavior by
	skipping to change at page 5, line 24		skipping to change at page 5, line 24
	format was initially defined in the MRT Programmer's Guide [MRT PROG		format was initially defined in the MRT Programmer's Guide [MRT PROG
	GUIDE].		GUIDE].
	This memo serves to document the MRT format as currently implemented		This memo serves to document the MRT format as currently implemented
	in publicly available software. The format has been extended since		in publicly available software. The format has been extended since
	it's original introduction in the MRT toolset and these extensions		it's original introduction in the MRT toolset and these extensions
	are also included in this memo. Further extensions may be introduced		are also included in this memo. Further extensions may be introduced
	at a later date through additional definitions of the MRT Type field		at a later date through additional definitions of the MRT Type field
	and Subtype fields.		and Subtype fields.
	Fields which contain multi-byte numeric values are encoded in network		A number of MRT message types have been documented in some references
	byte order from most significant byte to least significant byte.		but are not known to have been implemented. Further, several types
	Fields which contain routing message fields are encoded in the same		were employed in early MRT implementations, but are no longer
	order as they appear in the packet contents.		actively being used. These types are considered to be deprecated and
			are documented in a separate appendix at the end of this document.
			Some of the deprecated types may of interest to researchers examining
			historical MRT archives.
			Fields which contain multi-octet numeric values are encoded in
			network octet order from most significant octet to least significant
			octet. Fields which contain routing message fields are encoded in
			the same order as they appear in the packet contents.
	3. Basic MRT Format		3. Basic MRT Format
	All MRT format messages have a common header which includes a		All MRT format messages have a common header which includes a
	timestamp, Type, Subtype, and length field. The header is followed		timestamp, Type, Subtype, and length field. The header is followed
	by a message field. The MRT common header is illustrated below.		by a message field. The MRT common header is illustrated below.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 45		skipping to change at page 6, line 45
	information.		information.
	Subtype:		Subtype:
	A 2-octet field that is used to further distinguish message		A 2-octet field that is used to further distinguish message
	information within a particular message Type.		information within a particular message Type.
	Length:		Length:
	A 4-octet message length field. The length field contains the		A 4-octet message length field. The length field contains the
	number of bytes within the message. The length field does not		number of octets within the message. The length field does not
	include the length of the MRT common header.		include the length of the MRT common header.
	Message:		Message:
	A variable length message. The contents of this field are		A variable length message. The contents of this field are
	context dependent upon the Type and Subtype fields.		context dependent upon the Type and Subtype fields.
	4. MRT Informational Types		4. MRT Informational Types
	The MRT format defines five Informational Type messages. These		The MRT format defines five Informational Type messages. These
	skipping to change at page 8, line 19		skipping to change at page 8, line 19
	and do not contain routing information. These messages are OPTIONAL		and do not contain routing information. These messages are OPTIONAL
	and were largely intended for use when MRT messages are sent over a		and were largely intended for use when MRT messages are sent over a
	network to a remote repository store. However, MRT message		network to a remote repository store. However, MRT message
	repository stores have traditionally resided on the same device as		repository stores have traditionally resided on the same device as
	the collector and these Informational Types have seen limited		the collector and these Informational Types have seen limited
	implementation. Further, transport mechanisms for MRT messages are		implementation. Further, transport mechanisms for MRT messages are
	considered to be outside the scope of this document.		considered to be outside the scope of this document.
	The START and I_AM_DEAD messages MAY be used to provide a time		The START and I_AM_DEAD messages MAY be used to provide a time
	reference when a data collector begins and ends the collection		reference when a data collector begins and ends the collection
	process.		process. The time reference is obtained from the Timestamp field in
			the MRT message header.
	The message field MAY contain an OPTIONAL message string for		The message field MAY contain an OPTIONAL message string for
	diagnostic purposes. The message string encoding MUST follow the		diagnostic purposes. The message string encoding MUST follow the
	UTF-8 transformation format. The Subtype field is unused for these		UTF-8 transformation format. The Subtype field is unused for these
	Types and SHOULD be set to 0.		Types and SHOULD be set to 0.
	The MRT Informational Types are defined below:		The MRT Informational Types are defined below:
	1 START		1 START
	3 I_AM_DEAD		3 I_AM_DEAD
	skipping to change at page 12, line 26		skipping to change at page 12, line 26
	The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated		The Peer Type, Peer BGP ID, Peer IP, and Peer AS fields are repeated
	as indicated by the Peer Count field. The position of the Peer in		as indicated by the Peer Count field. The position of the Peer in
	the PEER_INDEX_TABLE is used as an index in the subsequent		the PEER_INDEX_TABLE is used as an index in the subsequent
	TABLE_DUMP_V2 MRT records. The index number begins with 0.		TABLE_DUMP_V2 MRT records. The index number begins with 0.
	The Peer Type field is a bit field which encodes the type of the AS		The Peer Type field is a bit field which encodes the type of the AS
	and IP address as follows:		and IP address as follows:
	Bit 0 - unset for IPv4 Peer IP address, set for IPv6		Bit 0 - unset for IPv4 Peer IP address, set for IPv6
	Bit 1 - unset when Peer AS field is 16 bits, set when it's 32 bits		Bit 1 - unset when Peer AS is 16 bits, set when it's 32 bits
	The records which follow the PEER_INDEX_TABLE record constitute the		The records which follow the PEER_INDEX_TABLE record constitute the
	RIB entries and include a header which specifies a sequence number,		RIB entries and include a header which specifies a sequence number,
	NLRI, and a count of the number of RIB entries which follow.		NLRI, and a count of the number of RIB entries which follow.
	The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST,		The format for the RIB_IPV4_UNICAST, RIB_IPV4_MULTICAST,
	RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below.		RIB_IPV6_UNICAST, and RIB_IPV6_MULTICAST headers are shown below.
	The Prefix Length and Prefix fields are encoded in the same manner as		The Prefix Length and Prefix fields are encoded in the same manner as
	the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix		the BGP NLRI encoding for IPV4 and IPV6 prefixes. Namely, the Prefix
	field contains address prefixes followed by enough trailing bits to		field contains address prefixes followed by enough trailing bits to
	skipping to change at page 15, line 13		skipping to change at page 15, line 13
	following AFI Types are supported:		following AFI Types are supported:
	1 AFI_IPv4		1 AFI_IPv4
	2 AFI_IPv6		2 AFI_IPv6
	5.4.2. BGP4MP_MESSAGE Subtype		5.4.2. BGP4MP_MESSAGE Subtype
	This Subtype is used to encode BGP Messages. It can be used to		This Subtype is used to encode BGP Messages. It can be used to
	encode any Type of BGP message. In order to determine the BGP		encode any Type of BGP message. In order to determine the BGP
	message Type, the entire BGP message is included in the BGP Message		message Type, the entire BGP message is included in the BGP Message
	field. This includes 16-octet marker, 2-ocet length, and 1-octet		field. This includes the 16-octet marker, the 2-octet length, and
	type fields. Note that the BGP4MP_MESSAGE Subtype does not support		the 1-octet type fields. Note that the BGP4MP_MESSAGE Subtype does
	32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates the		not support 32BIT AS numbers. The BGP4MP_MESSAGE_AS4 Subtype updates
	BGP4MP_MESSAGE Subtype in order to support these. The BGP4MP_MESSAGE		the BGP4MP_MESSAGE Subtype in order to support 32BIT AS numbers. The
	fields are shown below:		BGP4MP_MESSAGE fields are shown below:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer AS number | Local AS number |		| Peer AS number | Local AS number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Interface Index | Address Family |		| Interface Index | Address Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Peer IP address (variable) |		| Peer IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 17, line 49		skipping to change at page 17, line 49
	5.7. ISIS_ET Type		5.7. ISIS_ET Type
	The ISIS_ET Type extends the ISIS Type to support microsecond		The ISIS_ET Type extends the ISIS Type to support microsecond
	timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond		timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
	timestamp field is appended to the MRT common header after the length		timestamp field is appended to the MRT common header after the length
	field. The ISIS_ET Type is otherwise identical to the ISIS Type.		field. The ISIS_ET Type is otherwise identical to the ISIS Type.
	5.8. OSPFv3 Type		5.8. OSPFv3 Type
	The OSPFv3 Type extends the original OSPF Type to support IPv6		The OSPFv3 Type extends the original OSPF Type to support IPv6
	addresses for the OSPFv3 protocol as defined in RFC 2740 [RFC2740].		addresses for the OSPFv3 protocol as defined in RFC 5340 [RFC5340].
	The format of the MRT Message field for the OSPFv3 Type is as		The format of the MRT Message field for the OSPFv3 Type is as
	follows:		follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Address Family |		| Address Family |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Remote IP address (variable) |		| Remote IP address (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 19, line 9		skipping to change at page 19, line 9
	timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond		timestamps. As with the BGP4MP_ET Type, a 32BIT microsecond
	timestamp field is appended to the MRT common header after the length		timestamp field is appended to the MRT common header after the length
	field and its length is included in the calculation of the length		field and its length is included in the calculation of the length
	field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3		field value. The OSPFv3_ET Type is otherwise identical to the OSPFv3
	Type.		Type.
	6. IANA Considerations		6. IANA Considerations
	This section provides guidance to the Internet Assigned Numbers		This section provides guidance to the Internet Assigned Numbers
	Authority (IANA) regarding registration of values related to the MRT		Authority (IANA) regarding registration of values related to the MRT
	specification, in accordance with BCP 26, RFC 2434 [RFC2434].		specification, in accordance with BCP 26, RFC 5226 [RFC5226].
	There are two name spaces in MRT that require registration: Type		There are two name spaces in MRT that require registration: Type
	Codes and Subtype Codes.		Codes and Subtype Codes.
	MRT is not intended as a general-purpose specification for protocol		MRT is not intended as a general-purpose specification for protocol
	information export, and allocations should not be made for purposes		information export, and allocations should not be made for purposes
	unrelated to routing protocol information export.		unrelated to routing protocol information export.
	The following policies are used here with the meanings defined in BCP		The following policies are used here with the meanings defined in BCP
	26: "Specification Required", "IETF Consensus".		26: "Specification Required", "IETF Consensus".
	skipping to change at page 21, line 23		skipping to change at page 21, line 23
	dual environments", RFC 1195, December 1990.		dual environments", RFC 1195, December 1990.
	[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,		[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
	January 1997.		January 1997.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.
	[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
	RFC 2740, December 1999.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760,
	January 2007.		January 2007.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
			[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
			for IPv6", RFC 5340, July 2008.
	8.2. Informative References		8.2. Informative References
	[MRT PROG GUIDE]		[MRT PROG GUIDE]
	Labovitz, C., "MRT Programmer's Guide", November 1999,		Labovitz, C., "MRT Programmer's Guide", November 1999,
	<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.		<http://www.merit.edu/networkresearch/mrtprogrammer.pdf>.
	Appendix A. Deprecated MRT types		Appendix A. Deprecated MRT types
	This Appendix lists deprecated MRT types. These types are documented		This Appendix lists deprecated MRT types. These types are documented
	for informational purposes only. While documented in some		for informational purposes only. While documented in some
	skipping to change at page 29, line 4		skipping to change at line 1045
	Manish Karir		Manish Karir
	Merit Network		Merit Network
	Email: mkarir@merit.edu		Email: mkarir@merit.edu
	Craig Labovitz		Craig Labovitz
	Arbor Networks		Arbor Networks
	Email: labovit@arbor.net		Email: labovit@arbor.net
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	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, THE IETF TRUST 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
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	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
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 17 change blocks.
	31 lines changed or deleted		44 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/