< draft-katz-yeung-ospf-traffic-09.txt		draft-katz-yeung-ospf-traffic-10.txt >
			A new Request for Comments is now available in online RFC libraries.
	Network Working Group D. Katz		RFC 3630
	Internet Draft Juniper Networks
	Category: Standards Track D. Yeung
	Expires: April 2003 Procket Networks
	draft-katz-yeung-ospf-traffic-09.txt K. Kompella
	Juniper Networks
	October 2002
	Traffic Engineering Extensions to OSPF Version 2
	*** Draft ***
	Status
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.
	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.
	Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract
	This document describes extensions to the OSPF protocol version 2 to
	support intra-area Traffic Engineering, using Opaque Link State
	Advertisements.
	Changes
	(This section to be removed before publication).
	Per comments from the OSPF WG mailing list, the following changes
	were made:
	- State that operation over multi-access networks with more than two
	TE devices is not expressly forbidden.
	- Fix figure in 2.3.1.
	- Specify that a Remote Interface IP Address sub-TLV is optional for
	a multi-access link.
	1. Introduction
	This document specifies a method of adding traffic engineering
	capabilities to OSPF Version 2 [1]. The architecture of traffic
	engineering is described in [2]. The semantic content of the
	extensions is essentially identical to the corresponding extensions
	to IS-IS [3]. It is expected that the traffic engineering extensions
	to OSPF will continue to mirror those in IS-IS.
	The extensions provide a way of describing the traffic engineering
	topology (including bandwidth and administrative constraints) and
	distributing this information within a given OSPF area. This
	topology does not necessarily match the regular routed topology,
	though this proposal depends on Network LSAs to describe multiaccess
	links.
	1.1. Applicability
	Many of the extensions specified in this document are in response to
	the requirements stated in [2], and thus are referred to as "traffic
	engineering extensions", and are also commonly associated with MPLS
	Traffic Engineering. A more accurate (albeit bland) designation is
	"extended link attributes", as what is proposed is simply to add more
	attributes to links in OSPF advertisements.
	The information made available by these extensions can be used to
	build an extended link state database just as router LSAs are used to
	build a "regular" link state database; the difference is that the
	extended link state database (referred to below as the traffic
	engineering database) has additional link attributes. Uses of the
	traffic engineering database include:
	o monitoring the extended link attributes;
	o local constraint-based source routing; and
	o global traffic engineering.
	For example, an OSPF-speaking device can participate in an OSPF area,
	build a traffic engineering database, and thereby report on the
	reservation state of links in that area.
	In "local constraint-based source routing", a router R can compute a
	path from a source node A to a destination node B; typically, A is R
	itself, and B is specified by a "router address" (see below). This
	path may be subject to various constraints on the attributes of the
	links and nodes that the path traverses, e.g., use green links that
	have unreserved bandwidth of at least 10Mbps. This path could then
	be used to carry some subset of the traffic from A to B, forming a
	simple but effective means of traffic engineering. How the subset of
	traffic is determined, and how the path is instantiated is beyond the
	scope of this document; suffice it to say that one means of defining
	the subset of traffic is "those packets whose IP destinations were
	learned from B", and one means of instantiating paths is using MPLS
	tunnels. As an aside, note that constraint-based routing can be NP-
	hard, or even unsolvable, depending on the nature of the attributes
	and constraints and thus many implementations will use heuristics.
	Consequently, we don't attempt to sketch an algorithm here.
	Finally, for "global traffic engineering", a device can build a
	traffic engineering database, input a traffic matrix and an
	optimization function, crunch on the information, and thus compute
	optimal or near-optimal routing for the entire network. The device
	can subsequently monitor the traffic engineering topology and react
	to changes by recomputing the optimal routes.
	1.2. Limitations
	As mentioned above, this document specifies extensions and procedures
	for intra-area distribution of Traffic Engineering information.
	Methods for inter-area and inter-AS (Autonomous System) are not
	discussed here.
	The extensions specified in this document capture the reservation
	state of point-to-point links. The reservation state of multiaccess
	links may not be accurately reflected, except in the special case
	that there are only two devices in the multiaccess subnetwork.
	Operation over multiaccess networks with more than two devices is not
	specifically prohibited. More accurate description of the
	reservation state of multi-access networks is for further study.
	This document also does not support unnumbered links. This
	deficiency is addressed in [4]; see also [5] and [6].
	1.3. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [7].
	2. LSA Format
	2.1. LSA type
	This extension makes use of the Opaque LSA [8].
	Three types of Opaque LSAs exist, each of which has different
	flooding scope. This proposal uses only Type 10 LSAs, which have
	area flooding scope.
	One new LSA is defined, the Traffic Engineering LSA. This LSA
	describes routers, point-to-point links, and connections to
	multiaccess networks (similar to a Router LSA). For traffic
	engineering purposes, the existing Network LSA suffices for
	describing multiaccess links, so no additional LSA is defined for
	this purpose.
	2.2. LSA ID
	The LSA ID of an Opaque LSA is defined as having eight bits of type
	and 24 bits of type-specific data. The Traffic Engineering LSA uses
	type 1. The remaining 24 bits are the Instance field, as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | Instance |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Instance field is an arbitrary value used to maintain multiple
	Traffic Engineering LSAs. A maximum of 16777216 Traffic Engineering
	LSAs may be sourced by a single system. The LSA ID has no
	topological significance.
	2.3. LSA Format Overview
	2.3.1. LSA Header
	The Traffic Engineering LSA starts with the standard LSA header:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS age | Options | 10 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 1 | Instance |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Advertising Router |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS sequence number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| LS checksum | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2.3.2. TLV Header
	The LSA payload consists of one or more nested Type/Length/Value
	(TLV) triplets for extensibility. The format of each TLV is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The Length field defines the length of the value portion in octets
	(thus a TLV with no value portion would have a length of zero). The
	TLV is padded to four-octet alignment; padding is not included in
	the length field (so a three octet value would have a length of
	three, but the total size of the TLV would be eight octets). Nested
	TLVs are also 32-bit aligned. Unrecognized types are ignored.
	This memo defines Types 1 and 2. See the IANA Considerations section
	for allocation of new Types.
	2.4. LSA payload details
	An LSA contains one top-level TLV.
	There are two top-level TLVs defined:
	1 - Router Address
	2 - Link
	2.4.1. Router Address TLV
	The Router Address TLV specifies a stable IP address of the
	advertising router that is always reachable if there is any
	connectivity to it. This is typically implemented as a "loopback
	address"; the key attribute is that the address does not become
	unusable if an interface is down. In other protocols this is known
	as the "router ID," but for obvious reasons this nomenclature is
	avoided here. If a router advertises BGP routes with the BGP next
	hop attribute set to the BGP router ID, then the Router Address
	SHOULD be the same as the BGP router ID.
	If IS-IS is also active in the domain, this address can also be used
	to compute the mapping between the OSPF and IS-IS topologies. For
	example, suppose a router R is advertising both IS-IS and OSPF
	Traffic Engineering LSAs, and suppose further that some router S is
	building a single Traffic Engineering Database (TED) based on both
	IS-IS and OSPF TE information. R may then appear as two separate
	nodes in S's TED; however, if both the IS-IS and OSPF LSAs generated
	by R contain the same Router Address, then S can determine that the
	IS-IS TE LSA and the OSPF TE LSA from R are indeed from a single
	router.
	The router address TLV is type 1, and has a length of 4, and the
	value is the four octet IP address. It must appear in exactly one
	Traffic Engineering LSA originated by a router.
	2.4.2. Link TLV
	The Link TLV describes a single link. It is constructed of a set of
	sub-TLVs. There are no ordering requirements for the sub-TLVs.
	Only one Link TLV shall be carried in each LSA, allowing for fine
	granularity changes in topology.
	The Link TLV is type 2, and the length is variable.
	The following sub-TLVs are defined:
	1 - Link type (1 octet)
	2 - Link ID (4 octets)
	3 - Local interface IP address (4 octets)
	4 - Remote interface IP address (4 octets)
	5 - Traffic engineering metric (4 octets)
	6 - Maximum bandwidth (4 octets)
	7 - Maximum reservable bandwidth (4 octets)
	8 - Unreserved bandwidth (32 octets)
	9 - Administrative group (4 octets)
	This memo defines sub-Types 1 through 9. See the IANA Considerations
	section for allocation of new sub-Types.
	The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
	exactly once. All other sub-TLVs defined here may occur at most
	once. These restrictions need not apply to future sub-TLVs.
	Unrecognized sub-TLVs are ignored.
	Various values below use the (32 bit) IEEE Floating Point format.
	For quick reference, this format is as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|S| Exponent | Fraction |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	where S is the sign; Exponent is the exponent base 2 in "excess 127"
	notation; and Fraction is the mantissa - 1, with an implied binary
	point in front of it. Thus the above represents the value
	(-1)**(S) * 2**(Exponent-127) * (1 + Fraction)
	For more details, refer to [9].
	2.5. Sub-TLV Details
	2.5.1. Link Type
	The Link Type sub-TLV defines the type of the link:
	1 - Point-to-point
	2 - Multiaccess
	The Link Type sub-TLV is TLV type 1, and is one octet in length.
	2.5.2. Link ID
	The Link ID sub-TLV identifies the other end of the link. For point-
	to-point links, this is the Router ID of the neighbor. For
	multiaccess links, this is the interface address of the designated
	router. The Link ID is identical to the contents of the Link ID
	field in the Router LSA for these link types.
	The Link ID sub-TLV is TLV type 2, and is four octets in length.
	2.5.3. Local Interface IP Address
	The Local Interface IP Address sub-TLV specifies the IP address(es)
	of the interface corresponding to this link. If there are multiple
	local addresses on the link, they are all listed in this sub-TLV.
	The Local Interface IP Address sub-TLV is TLV type 3, and is 4N
	octets in length, where N is the number of local addresses.
	2.5.4. Remote Interface IP Address
	The Remote Interface IP Address sub-TLV specifies the IP address(es)
	of the neighbor's interface corresponding to this link. This and the
	local address are used to discern multiple parallel links between
	systems. If the Link Type of the link is Multiaccess, the Remote
	Interface IP Addess is set to 0.0.0.0; alternatively, an
	implementation MAY choose not to send this sub-TLV.
	The Remote Interface IP Address sub-TLV is TLV type 4, and is 4N
	octets in length, where N is the number of neighbor addresses.
	2.5.5. Traffic Engineering Metric
	The Traffic Engineering Metric sub-TLV specifies the link metric for
	traffic engineering purposes. This metric may be different than the
	standard OSPF link metric. Typically, this metric is assigned by a
	network admistrator.
	The Traffic Engineering Metric sub-TLV is TLV type 5, and is four
	octets in length.
	2.5.6. Maximum Bandwidth
	The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that
	can be used on this link in this direction (from the system
	originating the LSA to its neighbor), in IEEE floating point format.
	This is the true link capacity. The units are bytes per second.
	The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in
	length.
	2.5.7. Maximum Reservable Bandwidth
	The Maximum Reservable Bandwidth sub-TLV specifies the maximum
	bandwidth that may be reserved on this link in this direction, in
	IEEE floating point format. Note that this may be greater than the
	maximum bandwidth (in which case the link may be oversubscribed).
	This SHOULD be user-configurable; the default value should be the
	Maximum Bandwidth. The units are bytes per second.
	The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four
	octets in length.
	2.5.8. Unreserved Bandwidth
	The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
	not yet reserved at each of the eight priority levels, in IEEE
	floating point format. The values correspond to the bandwidth that
	can be reserved with a setup priority of 0 through 7, arranged in
	increasing order with priority 0 occurring at the start of the sub-
	TLV, and priority 7 at the end of the sub-TLV. The initial values
	(before any bandwidth is reserved) are all set to the Maximum
	Reservable Bandwidth. Each value will be less than or equal to the
	Maximum Reservable Bandwidth. The units are bytes per second.
	The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in
	length.
	2.5.9. Administrative Group
	The Administrative Group sub-TLV contains a 4-octet bit mask assigned
	by the network administrator. Each set bit corresponds to one
	administrative group assigned to the interface. A link may belong to
	multiple groups.
	By convention the least significant bit is referred to as 'group 0',
	and the most significant bit is referred to as 'group 31'.
	The Administrative Group is also called Resource Class/Color [2].
	The Administrative Group sub-TLV is TLV type 9, and is four octets in
	length.
	3. Elements of Procedure
	Routers shall originate Traffic Engineering LSAs whenever the LSA
	contents change, and whenever otherwise required by OSPF (an LSA
	refresh, for example). Note that this does not mean that every
	change must be flooded immediately; an implementation MAY set
	thresholds (for example, a bandwidth change threshold) that trigger
	immediate flooding, and initiate flooding of other changes after a
	short time interval. In any case, the origination of Traffic
	Engineering LSAs SHOULD be rate-limited to at most one every
	MinLSInterval [1].
	Upon receipt of a changed Traffic Engineering LSA or Network LSA
	(since these are used in traffic engineering calculations), the
	router should update its traffic engineering database. No SPF or
	other route calculations are necessary.
	4. Compatibility Issues
	There should be no interoperability issues with routers that do not
	implement these extensions, as the Opaque LSAs will be silently
	ignored.
	The result of having routers that do not implement these extensions
	is that the traffic engineering topology will be missing pieces;
	however, if the topology is connected, TE paths can still be
	calculated and ought to work.
	5. Normative References
	[1] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
	[4] Kompella, K., Rekhter, Y., et al, "OSPF Extensions in Support of
	Generalized MPLS," work in progress.
	[6] Kompella, K., and Y. Rekhter, "Signalling Unnumbered Links in
	RSVP-TE," work in progress.
	[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.
	[8] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, July 1998.
	[9] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic",
	Standard 754-1985, 1985 (ISBN 1-5593-7653-8).
	6. Informative References
	[2] Awduche, D., et al, "Requirements for Traffic Engineering Over
	MPLS," RFC 2702, September 1999.
	[3] Smit, H. and T. Li, "ISIS Extensions for Traffic Engineering,"
	work in progress.
	[5] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling
	Unnumbered Links in CR-LDP," work in progress.
	[10] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
	Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
	[11] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital
	Signatures", RFC 2154, June 1997.
	7. Security Considerations
	This document specifies the contents of Opaque LSAs in OSPFv2. As
	Opaque LSAs are not used for SPF computation or normal routing, the
	extensions specified here have no affect on IP routing. Tampering
	with TE LSAs may have an effect on traffic engineering computations,
	however, and it is suggested that whatever mechanisms are used for
	securing the transmission of normal OSPF LSAs be applied equally to
	all Opaque LSAs, including the TE LSAs specified here.
	Note that the mechanisms in [1] and [11] apply to Opaque LSAs. It is
	suggested that any future mechanisms proposed to secure/authenticate
	OSPFv2 LSA exchanges be made general enough to be used with Opaque
	LSAs.
	8. IANA Considerations
	The top level Types in a TE LSA as well as Types for sub-TLVs in a TE
	Link TLV are to be registered with IANA.
	Following the guidelines set in [10], top level Types in TE LSAs from
	3 through 32767 are to be assigned by Expert Review (the said Expert
	to be decided by the IESG). Types from 32768 through 65535 are
	reserved for Private Use. In all cases, assigned values Types MUST
	be registered with IANA.
	Also, sub-Types of a TE Link TLV from 10 to 32767 are to be assigned
	by Expert Review; values from 32768 through 32772 are reserved for
	Private Use; and values from 32773 through 65535 are to be assigned
	First Come First Served. In all cases, assigned values are to be
	registered with IANA.
	9. Authors' Addresses
	Dave Katz
	Juniper Networks
	1194 N. Mathilda Ave.
	Sunnyvale, CA 94089 USA
	Phone: +1 408 745 2000
	Email: dkatz@juniper.net
	Derek M. Yeung		Title: Traffic Engineering (TE) Extensions to
	Procket Networks, Inc.		OSPF Version 2
	1100 Cadillac Court		Author(s): D. Katz, K. Kompella, D. Yeung
	Milpitas, CA 95035 USA		Status: Standards Track
			Date: September 2003
			Mailbox: dkatz@juniper.net, myeung@procket.com,
			kireeti@juniper.net
			Pages: 14
			Characters: 27717
			Updates: 2370
	Phone: +1 408 635-7900		I-D Tag: draft-katz-yeung-ospf-traffic-10.txt
	Email: myeung@procket.com
	Kireeti Kompella		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3630.txt
	Juniper Networks
	1194 N. Mathilda Ave.
	Sunnyvale, CA 94089 USA
	Phone: +1 408 745 2000		This document describes extensions to the OSPF protocol version 2 to
	Email: kireeti@juniper.net		support intra-area Traffic Engineering (TE), using Opaque Link State
			Advertisements.
	10. IPR Notices		This document is a product of the Open Shortest Path First IGP Working
			Group of the IETF.
	The IETF takes no position regarding the validity or scope of any		This is now a Proposed Standard Protocol.
	intellectual property 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; neither does it represent that it
	has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication 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 implementors or users of this specification can
	be obtained from the IETF Secretariat.
	The IETF invites any interested party to bring to its attention any		This document specifies an Internet standards track protocol for
	copyrights, patents or patent applications, or other proprietary		the Internet community, and requests discussion and suggestions
	rights which may cover technology that may be required to practice		for improvements. Please refer to the current edition of the
	this standard. Please address the information to the IETF Executive		"Internet Official Protocol Standards" (STD 1) for the
	Director.		standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	11. Full Copyright Notice		This announcement is sent to the IETF list and the RFC-DIST list.
			Requests to be added to or deleted from the IETF distribution list
			should be sent to IETF-REQUEST@IETF.ORG. Requests to be
			added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	This document and translations of it may be copied and furnished to		To: rfc-info@RFC-EDITOR.ORG
	others, and derivative works that comment on or otherwise explain it		Subject: getting rfcs
	or assist in its implmentation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		help: ways_to_get_rfcs
	revoked by the Internet Society or its successors or assigns.
	This document and the information contained herein is provided on an		Requests for special distribution should be addressed to either the
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		specifically noted otherwise on the RFC itself, all RFCs are for
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		unlimited distribution.echo
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		Submissions for Requests for Comments should be sent to
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	558 lines changed or deleted		37 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/