< draft-ong-gmpls-ason-routing-exper-00.txt		draft-ong-gmpls-ason-routing-exper-01.txt >
	Network Working Group L. Ong		Network Working Group L. Ong, Ciena
	Internet-Draft Ciena		Internet-Draft A. Malis, Verizon
	Intended status: Informational R. Theillaud		Intended status: Standards Track R. Theillaud, Marben Products
	Expires: April 21, 2010 Marben Products		Expires: October 26, 2010
	October 18, 2009		February 26, 2010
	Implementation Experience with OSPFv2 Extensions for ASON Routing		OSPFv2 Extensions for ASON Routing based on Implementation Experience
	draft-ong-gmpls-ason-routing-exper-00		draft-ong-gmpls-ason-routing-exper-01
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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.
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 21, 2010.		This Internet-Draft will expire on October 26, 2010.
	Abstract		Abstract
	IETF CCAMP WG has defined a set of extensions to OSPFv2 to support		IETF CCAMP WG has defined a set of extensions to OSPFv2 to support
	ASON routing requirements. These extensions have been given EXP		ASON routing requirements. These extensions have been given EXP
	status rather than Standards Track and according to guidelines for		status rather than Standards Track and according to guidelines for
	OSPFv2 have not been allocated standard codepoints by IANA.		OSPFv2 have not been allocated standard codepoints by IANA. This
			work has continued in [OSPFASON].
	This draft describes implementation and interoperability testing		This draft defines a set of proposed updates for a subset of the
	experiences with ASON routing extensions to OSPFv2 which provide		the ASON routing extensions for OSPFv2 defined in [OSPFASON].
	equivalent routing functionality to the extensions defined in IETF		These proposed updates have already benefited from running code
	CCAMP with some differences in formatting of the extensions.		tested in multiple interoperability testing events, with at least
			eight independent implementations. The differences from [OSPFASON]
			are the result of field and interoperability testing experience.
	This summary of implementation and testing is provided to help move		These formats are proposed to either be folded in to [OSPFASON],
	ASON Routing extensions for OSPF to Standards Track.		or be a separate Standards Track RFC covering
			a subset of the ASON extensions to OSPFv2, as preferred by the
			working group. We believe that adopting these formats will help
			move those parts of [OSPFASON] towards Standards Track, while
			preserving the functionality defined in [OSPFASON].
	Requirements Language		Requirements Language
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Comparison with [OSPFASON]. . . . . . . . . . . . . . . . . . 3
	2.1. Review of ASON Routing draft . . . . . . . . . . . . . . . 3		3. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Tested IPv4 Reachability Advertisement . . . . . . . . . . 4		3.1. ASON Routing Requirements . . . . . . . . . . . . . . . . 4
	3. Link Attributes . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Local TE Router_ID sub-TLV . . . . . . . . . . . . . . . . 5
	3.1. Review of ASON Routing draft . . . . . . . . . . . . . . . 4		3.3. IPv4 Reachable Address Prefix sub-TLV . . . . . . . . . . 5
	3.2. Bandwidth Accounting for ITU-T SONET/SDH Layers . . . . . 4		3.4. IPv6 Reachable Address Prefix sub-TLV . . . . . . . . . . 5
	3.2.1. SONET/SDH-specific connection availability . . . . . . 5		4. Routing Information Scope . . . . . . . . . . . . . . . . . . 6
	4. Routing Information Scope . . . . . . . . . . . . . . . . . . 7		4.1. ASON Routing Requirements . . . . . . . . . . . . . . . . 6
	4.1. Review of ASON Routing Draft . . . . . . . . . . . . . . . 7		4.2. Local and Remote TE Router_ID sub-TLVs . . . . . . . . . . 6
	4.2. Link Advertisement (Local and Remote TE Router ID		5. Link Attributes . . . . . . . . . . . . . . . . . . . . . . . 7
	sub-TLVs) . . . . . . . . . . . . . . . . . . . . . . . . 7		5.1. ASON Requirements . . . . . . . . . . . . . . . . . . . . 7
	4.3. Reachability Advertisement (Local TE Router ID sub-TLV) . 8		5.2. Link Component Availability Sub-TLV. . . . . . . . . . . . 7
	4.4. New Reachable Address top-level TLV . . . . . . . . . . . 9		6. Implementation and Testing Results . . . . . . . . . . . . . . 9
	5. Routing Information Dissemination . . . . . . . . . . . . . . 10		6.1. Standardization . . . . . . . . . . . . . . . . . . . . . 9
	6. Implementation and Testing Results . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Standardization . . . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	This draft presents results of interoperability testing on the part		The ITU-T defines the architecture of the Automatically Switched
	of the authors and others that have been involved in understanding		Optical Network (ASON) in [G.8080].
	and prototyping routing for ASON as part of the OIF (Optical
	Internetworking Forum). Some of the authors have contributed to the		[RFC4258] details the routing requirements for the GMPLS suite of
	work in IETF on ASON routing requirements and protocol evaluation.		routing protocols to support the capabilities and functionality of
	Many of the requirements and protocol functions discussed in		ASON control planes identified in [G.7715] and in [G.7715.1].
	[RFC4258] and [RFC4652] have been incorporated into prototyping work
	at OIF. Experimental protocol extensions to OSPF were implemented to		[RFC4652] evaluates the IETF Link State Routing Protocols against the
	support the functions identified in [RFC4258] and [RFC4652].		requirements identified in [RFC4258]. Section 7.1 of [RFC4652]
			summarizes the capabilities to be provided by OSPFv2 [RFC2328] in
			support of ASON routing. This document details a set of OSPFv2
			extensions supporting a subset of the capabilities identified in
			[RFC4652] which have already been implemented and tested for
			interoperability across at least 8 independent implementations.
	Note that these extensions have been tested in a transport-only		Note that these extensions have been tested in a transport-only
	instance of OSPF, i.e. routing implementations supported only optical		instance of OSPF, i.e. routing implementations supported only optical
	routing and did not participate in any IP routing use of OSPF.		routing and did not participate in any IP routing use of OSPF.
	Since then, the IETF has published a draft ( [OSPF-ASON]) addressing		This draft also compares the implemented extensions to those
	some of the features implemented by those prototypes. However, the		defined in [OSPFASON], which defines experimental OSPFv2
	latest revision of [OSPF-ASON] (-09) no longer provides IETF-		extensions in support of [RFC4652] capabilities. The changes from
	standardized code points for such sub-TLVs, due to its Experimental		[OSPFASON] are the result of field and interoperability testing
	Status and the existing guidelines for allocation of codepoints for		experience, and are either minor format changes or supplementary
	OSPF.		information found useful in field testing. We believe that adop-
			ting the extensions in this draft will further progress [OSPFASON].
	This draft summarizes testing of ASON routing extensions done by the		2. Comparison with [OSPFASON]
	authors and others participating in OIF interop testing to assist in
	the process of moving ASON routing extensions to Standards Track.
	2. Reachability		This draft defines formats similar to some defined in [OSPFASON].
			This section gives a high level comparison of the two formats.
	2.1. Review of ASON Routing draft		2.1. Reachable Address Prefix Advertisement
	In order to advertise blocks of reachable address prefixes a		Uses a single TLV to carry multiple values of TE Router_ID and
	summarization mechanism was proposed in [OSPF-ASON].		associated IPv4 or IPv6 address prefixes, rather than separate
			TLVs as in [OSPFASON].
	This extension consists of a network mask (a 32-bit number indicating		In the IPv4 prefix format, uses Prefix Length to indicate the
	the range of IP addresses residing on a single IP network/subnet).		prefix length rather than a Network Mask as in [OSPFASON] (Note
	The set of local addresses is carried in an OSPFv2 TE LSA node		[OSPFASON] uses Prefix Length for the IPv6 prefix format).
	attribute TLV (a specific sub-TLV is defined per address family,
	i.e., IPv4 and IPv6, used as network-unique identifiers).
	Similar functionality was implemented and tested by the authors and		2.2. Router Information Scoping
	others. At the time of initial prototyping, the OSPFv2 TE LSA node
	attribute TLV had not been defined, so somewhat different formatting
	was used to carry IP prefixes.
	The tested solution used a new sub-TLV to carry the same information,		Uses separate Sub-TLVs to carry Local and Remote TE Router_ID
	called the Reachable IPv4 Prefix sub-TLV. This sub-TLV was carried		instead of a single Sub-TLV for both, as in [OSPFASON].
	in a new OSPFv2 Reachable Address TLV. Details of the TLV are given
	in section 5.
	2.2. Tested IPv4 Reachability Advertisement		2.3. Link Attributes
	The Reachable IPv4 Prefix sub-TLV used the following format:		Advertises Link Component Availability at multiple TDM layers
			as opposed to or in addition to advertisement of ISCD for an
			individual TDM layer.
			3. Reachability
			3.1. ASON Routing Requirements
			[RFC4652] identifies the need for additional capabilities to
			advertise blocks of reachable address prefixes using a summarization
			mechanism either taking the form of a prefix length (which indicates
			the number of significant bits in the prefix) or a network mask.
			An OSPF Reachable Address Prefix TLV was implemented and tested
			to support this capability. This TLV is advertised as the payload
			of a Type 1 Traffic Engineering LSA [RFC3630]. It has the following
			format:"
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Sub-type (EXP) | Length (variable) |		| Type | Length (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Addr length | Reserved |		| Local TE_Router_Id sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Reachable Address |		| IPv4 or IPv6 Reachable Address sub-TLV |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// . . . //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 or IPv6 Reachable Address sub-TLV |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			// . . . //
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Local TE_Router_Id sub-TLV |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 or IPv6 Reachable Address sub-TLV |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			// . . . //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 or IPv6 Reachable Address sub-TLV |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			This format allows the Reachable Address Prefix TLV to advertise
			multiple TE Router_IDs associated with the advertising entity, as
			well as multiple Reachable Address Prefixes associated with these
			TE Router_IDs.
	Addr length: specifies the length of the prefix as a number of Bits.		Each IPv4 or IPv6 Reachable Address Prefix sub-TLV is associated
			specifically with the TE Router_ID preceding it in the TLV.
	IPv4 Reachable Address: For example, the address prefix 192.10.3.0/24		3.2. Local TE_Router_ID Sub-TLV
	can be advertised with an address of 193.10.3 and an addr_length =
	24.
	3. Link Attributes		The Local TE_Router_ID sub-TLV used the following format:
	3.1. Review of ASON Routing draft		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 (tbd) | Length |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Local TE Router_ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	[OSPF-ASON] defined additional terminology and scoping of link		The Local TE Router_ID field advertises a Local TE Router_IDentifier
	attributes advertised in a GMPLS LSA. One attribute which was left		being advertised associated with the advertising entity.
	open for possible technology-specific enhancements was the the
	Interface Switching Capability Descriptor (ISCD).
	For prototyping purposes for control of SONET/SDH networks, the		3.3 IPv4 Reachable Address Prefix Sub-TLV
	following technology-specific enhancement was implemented.
	3.2. Bandwidth Accounting for ITU-T SONET/SDH Layers		The IPv4 Reachable Address Prefix sub-TLV takes the following form:
	GMPLS Routing defines an Interface Switching Capability Descriptor		0 1 2 3
	(ISCD) that delivers, among other things, information about the		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
	(maximum/minimum) bandwidth per priority that an LSP can make use of.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Per [RFC4202] and [RFC4203], one or more ISCD sub-TLVs can be		| Type (tbd) | Length (variable) |
	associated with an interface. This information, combined with the		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Unreserved Bandwidth (sub-TLV defined in [RFC3630], Section 2.5.8),		| Pref_length | Reserved |
	provides the basis for bandwidth accounting.		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| IPv4 Reachable Address Prefix |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	[OSPF-ASON] states that in the ASON context, additional information		The following fields are defined:
	may be included when representation and information in the other
	advertised fields are not sufficient for a specific technology (e.g.,
	SDH). The definition of technology-specific information elements was
	left beyond the scope of [OSPF-ASON], in the draft.
	3.2.1. SONET/SDH-specific connection availability		Pref_length: length in bits of the Prefix
	For SONET/SDH networks with switches capable of handling multiple		IPv4 Reachable Address Prefix: Each prefix is encoded as a
	layer networks, a single link may be used for a number of TDM layers.		32-bit word with trailing zero bit padding as necessary.
	For example, an OC192 link may be used for STS-1, STS-3c, STS-12c,
	STS-48c, STS-192c connections, switched by the same fabric.
	GMPLS appears to offer a number of possible options for advertising		3.4 IPv6 Reachable Address Prefix Sub-TLV
	link characteristics where multiple layers are supported by the same
	physical link.
	One option is to advertise separate Link TLVs for each layer. A		IPv6 prefixes were not implemented or tested.
	second option is to advertise multiple ISCD sub-TLVs within a single
	Link TLV for the link. A third option is to advertise a single Link
	TLV and ISCD sub-TLV and attempt to derive bandwidth availability for
	multiple TDM layers from this information.
	All three options were found to have some disadvantages and instead a		4. Routing Information Scope
	technology-specific ISCD sub-TLV was defined containing information
	that applies to multiple TDM layers.
	This solution was implemented for the following reasons:		4.1. ASON Routing Requirements
	o If separate TLVs are advertised for each layer, then common		[RFC4652] identifies the need for an extension to routing protocols
	information such as LSA header information, link type, link ID,		to support non-1:1 relationships between the Router_ID and TE
	link local and remote identifiers, protection type, administrative		Router_ID, and as a result the need for the capability to advertise
	group and shared risk are repeated for each layer.		the remote Lj value where Lj is a logical control plane entity that
			is associated to a single data plane (abstract) node.
	o If separate ISCD sub-TLVs are advertised for each layer, then		4.2. Local and Remote TE Router_ID Sub-TLVs
	common information such as the Switching Capability (TDM) and
	Encoding Type (SONET/SDH) are repeated for each layer.
	o Deriving bandwidth availability from a single ISCD sub-TLV which		In order to support this capability, two sub-TLVs of the TE LSA Link
	contains the total available bandwidth and the minimum reservable		TLV [RFC3630] are defined for advertising the Local TE Router_ID
	bandwidth yields potentially inaccurate results, since support of		and Remote TE Router_ID. These use the following formats:
	standard concatenation requires sequential timeslots in a
	particular position, and this can be blocked by a smaller signal
	in that space. Some available bandwidth may not be usable as a
	result.
	A technology-specific ISCD sub-TLV that carried a compact description		0 1 2 3
	of the number of unallocated timeslots at each supported SONET/SDH		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
	signal type was used instead of separate Link TLVs or ISCD sub-TLVs		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	and carried exact availability information for each signal type. The		| Type | Length |
	indication subfield was also removed as no longer necessary since		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Arbitrary SONET/SDH is not supported.		| Local TE Router_ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The following technology-specific ISCD format was tested:		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 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Remote TE Router_ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			These sub-TLVs allow the routing protocol to scope the advertised
			link attributes advertised in an OSPFv2 TE Link LSA for ASON
			routing.
			5. Link Attributes
			5.1 ASON Requirements
			[RFC4652] notes that in the ASON context, bandwidth accounting
			representations are possible, taking the form of a set of tuples
			<signal_type; number of unallocated timeslots>, and that this
			representation may also require definition of additional signal
			types (from those defined in [RFC4606]) to represent support of
			contiguously concatenated signals,
			i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
			It notes that the ISCD defined in [RFC4202] is the most
			straightforward without requiring any bandwidth accounting
			change from an LSR perspective. However, the ISCD defined
			in [RFC4202} must be advertised once per signal type
			(identified by the Minimum Reservable Bandwidth value) in
			order to provide an accurate advertisement of bandwidth
			for each signal. For SONET/SDH links, it is common to support
			4-5 signal types (e.g., STS-1, 3c, 12c, 48c and 192c) at once,
			and advertisement of 4-5 ISCD sub-TLVs would consume about
			200 bytes as compared to 20-30 bytes for a tuple format.
			Most of the ISCD bytes are required to advertise 8 levels of
			priority. We believe this overhead can be reduced as (a) ASON
			specifications do not identify priority as an ASON service; and
			(b) TDM networks generally to not support preemption priority
			at all, not to mention 8 levels.
			5.2. Link Component Availability Sub-TLV
			The Link Component Availability Sub-TLV carries an indication
			of SONET/SDH bandwidth at multiple link component signal types as
			supplementary information to the ISCD sub-TLV.
			When multiple priorities are used, the Link Component Availability
			Sub-TLV can be interpreted as the availability for Priority 7.
			The following format is defined:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type (EXP) | Length = 4 + n*4 |		| Type (tbd) | Length = 4 + n*4 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Switching Cap | Encoding | Reserved |		| Switching Cap | Encoding | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signal Type | Number of Unallocated Timeslots |		| Signal Type | Number of Unallocated Timeslots |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Signal Type | Number of Unallocated Timeslots |		| Signal Type | Number of Unallocated Timeslots |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	// . . . //		// . . . //
	| |		| |
	skipping to change at page 6, line 38 ¶		skipping to change at page 8, line 34 ¶
	and thus has a value greater than or equal to 1. Inherited from		and thus has a value greater than or equal to 1. Inherited from
	[RFC4202], the Switching Capability field and the Encoding field MUST		[RFC4202], the Switching Capability field and the Encoding field MUST
	take the following values for Sonet/SDH interfaces: Switching		take the following values for Sonet/SDH interfaces: Switching
	Capability (8 bits): value 100 (TDM). Encoding (8 bits): value 5 for		Capability (8 bits): value 100 (TDM). Encoding (8 bits): value 5 for
	Sonet/SDH. Reserved (16 bits): must be set to zero when sent and		Sonet/SDH. Reserved (16 bits): must be set to zero when sent and
	ignored when received.		ignored when received.
	Signal Type (8 bits):		Signal Type (8 bits):
	STS-1 SPE / VC-3 [RFC4606]		STS-1 SPE / VC-3 [RFC4606]
	STS-3c SPE / VC-4 [RFC4606]		STS-3c SPE / VC-4 [RFC4606]
			STS-12c SPE/VC-4-4c
	STS-12c SPE/VC-4-4c Exp		STS-48c SPE/VC-4-16c
			STS-192c SPE/VC-4-64c
	STS-48c SPE/VC-4-16c Exp
	STS-192c SPE/VC-4-64c Exp
	Number of Unallocated Timeslots (24 bits):		Number of Unallocated Timeslots (24 bits):
	Specifies the number of identical unallocated timeslots per Signal		Specifies the number of identical unallocated timeslots per Signal
	Type and per TE Link. As such, the initial value(s) of this TLV		Type and per TE Link. As such, the initial value(s) of this TLV
	indicates the total capacity in terms of number of timeslots per TE		indicates the total capacity in terms of number of timeslots per TE
	link. The signal type included in the BW announcement is specific to		link. The signal type included in the BW announcement is specific to
	the layer link being reported and is not derived from some other		the layer link being reported and is not derived from some other
	signal type (e.g. STS-48c is not announced as 16 x STS-3c).		signal type (e.g. STS-48c is not announced as 16 x STS-3c).
	For instance on an OC-192/STM-64 interface either the number of		For instance on an OC-192/STM-64 interface either the number of
	STS-3c SPE/VC-4 unallocated timeslots is initially equal to 64, or		STS-3c SPE/VC-4 unallocated timeslots is initially equal to 64, or
	the number of STS-48c SPE/VC-4-16c unallocated timeslots is equal to		the number of STS-48c SPE/VC-4-16c unallocated timeslots is equal to
	4 or even a combination of both type of signals depending on the		4 or even a combination of both type of signals depending on the
	interface capabilities. Once one of these components gets allocated		interface capabilities. Once one of these timeslots is occupied
	for a given connection, the number of unallocated timeslots is		either by being allocated for a connection at the same or a larger
	decreased by the number of timeslots this connection implies.		signal type or by being blocked due to the allocation of part of
			the timeslot for a connection at a smaller signal type, the number
	4. Routing Information Scope		of unallocated timeslots is decreased by the number of timeslots
			this connection implies.
	4.1. Review of ASON Routing Draft
	[OSPF-ASON] proposed extensions to allow the scope of routing
	Information to allow flexibility between the relationship of The
	advertising router and the TE router. Similar extensions with
	slightly different format were implemented in testing.
	4.2. Link Advertisement (Local and Remote TE Router ID sub-TLVs)
	Implementations followed the concepts defined in [OSPF-ASON] to Allow
	flexible relationship between the Router-ID and the TE Router-ID.
	The following is given in [OSPF-ASON]:
	A Router-ID (Ri) advertising on behalf multiple TE Router_IDs (Lis)
	creates a 1:N relationship between the Router-ID and the TE
	Router-ID. As the link local and link remote (unnumbered) ID
	association is not unique per node (per Li unicity), the
	advertisement needs to indicate the remote Lj value and rely on the
	initial discovery process to retrieve the [Li;Lj] relationship. In
	brief, as unnumbered links have their ID defined on per Li bases, the
	remote Lj needs to be identified to scope the link remote ID to the
	local Li. Therefore, the routing protocol MUST be able to
	disambiguate the advertised TE links so that they can be associated
	with the correct TE Router-ID.
	The tested extensions used two sub-TLVs of the (OSPFv2 TE LSA) top
	level Link TLV that define the local and the remote TE Router-ID.
	These are combined into a single sub-TLV in [OSPF-ASON] (the Local
	and Remote TE Router-ID sub-TLV), however implementation and testing
	began before [OSPF-ASON] was defined.
	The formats of the Local and Remote TE Router-ID sub-TLVs were:
	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 (exp) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local TE Router-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 (exp) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Remote TE Router-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	These sub-TLVs were always included as part of the top level Link TLV
	as it was assumed that the Router-ID could always advertise on behalf
	of multiple TE Router-IDs.
	4.3. Reachability Advertisement (Local TE Router ID sub-TLV)
	When the Router-ID is advertised on behalf of multiple TE Router-IDs
	(Lis), the routing protocol MUST be able to associate the advertised
	reachability information with the correct TE Router-ID.
	For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level Node
	Attribute TLV was introduced in [OSPF-ASON]. Since this sub-TLV had
	not yet been defined at the time of initial implementation, a sub-TLV
	was defined independently for prototype testing. In this case the
	format is the same.
	The tested solution used a new sub-TLV of the (OSPFv2 TE LSA) top
	level Reachable Address TLV (see section 5): the TE Router ID sub-
	TLV.
	The TE Router_ID sub-TLV used the following format:
	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 (exp) | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local TE Router_ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	4.4. New Reachable Address top-level TLV
	When the OSPFv2 extensions for ASON routing were designed for the
	first OIF interoperability demonstrations,
	draft-ietf-ospf-te-node-addr draft was at a very early stage, and the
	Node Attribute top-level TLV was not available to carry reachable
	prefixes. Instead a new experimental top-level TLV was defined: the
	Reachable Address top-level TLV.
	Contrary to [OSPF-ASON] where each Node Attribute top-level TLV
	carries reachable prefixes for a single TE Router ID (so that if a
	Router advertises reachable prefixes on behalf of multiple TE Router
	IDs, it will originate multiple OSPFv2 TE LSAs with a Node Attribute
	TLV), the Reachable Address top-level TLV may be used to advertise
	reachable prefixes attached to multiple TE Router IDs: in order to do
	so, a TE Router ID sub-TLV MUST appear before the Reachable Address
	sub-TLV(s).
	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 (exp) | Length (variable) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TE Router_Id sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Address sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	// . . . //
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Address sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	// . . . //
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| TE Router_Id sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Address sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	// . . . //
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reachable Address sub-TLV |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	This tested format is functionally equivalent to the format defined
	in [OSPF-ASON] but is independent of the function of advertising
	local addresses of a router for MPLS TE LSPs as defined in
	[OSPF-NODE].
	5. Routing Information Dissemination
	Subdivision of ASON Routing Areas as discussed in this section of
	[OSPF-ASON] has not yet been implemented and tested.
	6. Implementation and Testing Results		6. Implementation and Testing Results
			Initial implementation of ASON routing extensions began in 2003.
	Testing of these protocol extensions was carried out at a number of		Testing of these protocol extensions was carried out at a number of
	testing events from 2003-2009, most recently occurring over a period		testing events from 2003-2009, most recently occurring over a period
	of months during July-September 2007 and April-June 2009. There were		of months during July-September 2007 and April-June 2009. There were
	7 independent implementations tested at each event as listed below:		7 independent implementations tested at each event as listed below:
	2007 interop test implementations:		2007 interop test implementations:
	o Alcatel-Lucent		o Alcatel-Lucent
	o Ciena Corporation		o Ciena Corporation
	o Ericsson		o Ericsson
	o Huawei Technologies		o Huawei Technologies
	o Sycamore Networks		o Sycamore Networks
	o Tellabs		o Tellabs
	o ZTE		o ZTE
	2009 interop test implementations:		2009 interop test implementations:
	o Alcatel-Lucent		o Alcatel-Lucent
	o Ciena Corporation		o Ciena Corporation
			o Ericsson
	o Huawei Technologies		o Huawei Technologies
	o Nokia Siemens Networks		o Nokia Siemens Networks
	o Sycamore Networks		o Sycamore Networks
	o Tellabs		o Tellabs
	o ZTE		o ZTE
	Initial implementation and interop testing of ASON routing extensions
	began as early as 2003.
	Further information about the testing conducted can be found at		Further information about the testing conducted can be found at
	http://www.oiforum.com/public/OIF_demos.html		http://www.oiforum.com/public/OIF_demos.html
	All implementations utilized the ASON routing extensions described in		All implementations utilized the ASON routing extensions described in
	this draft.		this draft.
	Results were:		Results were:
	o prototype implementations were interoperable		o prototype implementations were interoperable
	o aligned TE database was achieved by participating implementations		o aligned TE database was achieved by participating implementations
	o path computation was successfully achieved for connections		o path computation was successfully achieved for connections
	o connections were successfully set up at different SONET/SDH rates		o connections were successfully set up at different SONET/SDH rates
	using the TE database		using the TE database
	6.1. Standardization		6.1. Standardization
	These testing results are provided in the interests of achieving		The extensions defined in this draft satisfy a subset of the
	standard OSPFv2 protocol extensions to support ASON routing. The		functionality identified in [RFC4258] and [RFC4652] for ASON
	extensions tested are very similar in functionality to the extensions		routing. The results of implementation and interoperability testing
	defined in [OSPF-ASON], with the exception of the technology-specific
	ISCD sub-TLV used. The results of this implementation and testing
	show that these functions are useful and implementable, and that ASON		show that these functions are useful and implementable, and that ASON
	routing extensions to OSPF should be Standards Track rather than		routing extensions to OSPF may be made Standards Track rather than
	Experimental.		Experimental, using the formats implemented and tested.
	It is believed by the authors that the tested TLVs and sub-TLVs are
	equivalent in functionality to the extensions defined in [OSPF-ASON]
	and could be adopted by IETF as extensions to OSPF used in a
	transport instance.
	This would enhance the adoption of standard GMPLS routing extensions		Standardization of these extensions by IETF for ASON routing support
	for ASON as a set of implementations for these routing extensions		would allow fast adoption in the industry due to the presence of
	will have already been tested and these extensions would as a result		several existing implementations, i.e., running code.
	be available sooner for use in the industry.
	7. IANA Considerations		7. IANA Considerations
	Propose IANA allocate codepoints for new TLV/sub-TLVs for ASON		Propose IANA allocate codepoints for new TLV/sub-TLVs for ASON
	Routing.		Routing from the standard range.
	8. Security Considerations		8. Security Considerations
	This document describes implementation and testing experience with		This document describes implementation and testing experience with
	ASON routing extensions similar to those defined in [OSPF-ASON]. No		ASON routing extensions similar to those defined in [OSPFASON]. No
	additional security issues are identified.		additional security issues are identified.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank the following OIF members for their		The authors would like to thank the following OIF members for their
	comments and support for this document:		comments and support for this document:
	Richard Graveman (Department of Defense)		Richard Graveman (Department of Defense)
	Hans-Martin Foisel (Deutsche Telekom)		Hans-Martin Foisel (Deutsche Telekom)
	Thierry Marcot (France Telecom)		Thierry Marcot (France Telecom)
	Evelyne Roch (Nortel Networks)		Evelyne Roch (Nortel Networks)
			Jonathan Sadler (Tellabs)
	Jonathan Saddler (Tellabs)
	Yoshiaki Sone (NTT Corporation)		Yoshiaki Sone (NTT Corporation)
	Takehiro Tsuritani (KDDI R&D Laboratories)		Takehiro Tsuritani (KDDI R&D Laboratories)
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[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", RFC 2328,April 1998.
	[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering		[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
	(TE) Extensions to OSPF Version 2", RFC 3630,		(TE) Extensions to OSPF Version 2", RFC 3630,
	September 2003.		September 2003.
	[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in		[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
	Support of Generalized Multi-Protocol Label Switching		Support of Generalized Multi-Protocol Label Switching
	(GMPLS)", RFC 4202, October 2005.		(GMPLS)", RFC 4202,February 2005.
	[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
	of Generalized Multi-Protocol Label Switching (GMPLS)",
	RFC 4203, October 2005.
	[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-		[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
	Protocol Label Switching (GMPLS) Extensions for		Protocol Label Switching (GMPLS) Extensions for
	Synchronous Optical Network (SONET) and Synchronous		Synchronous Optical Network (SONET) and Synchronous
	Digital Hierarchy (SDH) Control", RFC 4606, August 2006.		Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
	10.2. Informative References		10.2. Informative References
	[OSPF-ASON]		[OSPFASON] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions
	Papadimitriou, D., "OSPFv2 Routing Protocols Extensions
	for ASON Routing,		for ASON Routing,
	draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in		draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt, work in
	progress", August 2009.		progress", August 2010.
	[OSPF-NODE]
	Aggarwal, R., "Advertising a Router's Local Addresses in
	OSPF TE Extensions, draft-ietf-ospf- te-node-addr, work in
	progress", October 2009.
	[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol		[RFC4258] Brungard, D., "Requirements for Generalized Multi-Protocol
	Label Switching (GMPLS) Routing for the Automatically		Label Switching (GMPLS) Routing for the Automatically
	Switched Optical Network (ASON)", RFC 4258, November 2005.		Switched Optical Network (ASON)", RFC 4258, November 2005.
	[RFC4652] Papadimitriou, D., L.Ong, Sadler, J., Shew, S., and D.		[RFC4652] Papadimitriou, D., L.Ong, Sadler, J., Shew, S., and D.
	Ward, "Evaluation of Existing Routing Protocols against		Ward, "Evaluation of Existing Routing Protocols against
	Automatic Switched Optical Network (ASON) Routing		Automatic Switched Optical Network (ASON) Routing
	Requirements", RFC 4652, October 2006.		Requirements", RFC 4652,February 2006.
	Authors' Addresses		Authors' Addresses
	Lyndon Ong		Lyndon Ong
	Ciena		Ciena
	P.O.Box 308		P.O.Box 308
	Cupertino CA 95015		Cupertino CA 95015
	USA		USA
	Phone: +1 408 962 4929		Phone: +1 408 962 4929
	Email: lyong@ciena.com		Email: lyong@ciena.com
			Andrew Malis
			Verizon
			117 West St.
			Waltham, MA 02451
			USA
			Email: andrew.g.malis@verizon.com
			Phone: +1 781 466 2362
	Remi Theillaud		Remi Theillaud
	Marben Products		Marben Products
	176 rue Jean Jaures		176 rue Jean Jaures
	Puteaux 92800		Puteaux 92800
	France		France
	Email: remi.theillaud@marben-products.com		Email: remi.theillaud@marben-products.com
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with
			respect to this document.
End of changes. 82 change blocks.
	352 lines changed or deleted		258 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/