< draft-ietf-isis-traffic-03.txt		draft-ietf-isis-traffic-04.txt >
	Network Working Group Tony Li		Network Working Group Henk Smit
	INTERNET DRAFT Procket Networks		INTERNET DRAFT Tony Li
	Henk Smit
	Procket Networks		Procket Networks
	June 2001		December 2002
	IS-IS extensions for Traffic Engineering		IS-IS extensions for Traffic Engineering
	<draft-ietf-isis-traffic-03.txt>		<draft-ietf-isis-traffic-04.txt>
	Status		Status
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC 2026 except that the right to		all provisions of Section 10 of RFC 2026 except that the right to
	produce derivative works is not granted.		produce derivative works is not granted.
	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 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.
	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.
	1.0 Abstract		Abstract
	This document describes extensions to the IS-IS protocol to support		This document describes extensions to the IS-IS protocol to support
	Traffic Engineering [1]. The IS-IS protocol is specified in [2],		Traffic Engineering.
	with extensions for supporting IPv4 specified in [3].
	This document extends the IS-IS protocol by specifying new		This document extends the IS-IS protocol by specifying new
	information that a Intermediate System (IS) [router] can place in		information that an Intermediate System [router] can place in Link
	Link State Protocol Data Units (LSPs). This information describes		State Protocol Data Units. This information describes additional
	additional information about the state of the network that is useful		details of the state of the network that are useful for traffic
	for traffic engineering computations.		engineering computations.
	2.0 Introduction		1.0 Introduction
	An IS-IS LSP is composed of a fixed header and a number of tuples,		The IS-IS protocol is specified in ISO 10589 [1], with extensions for
	each consisting of a Type, a Length, and a Value. Such tuples are		supporting IPv4 specified in RFC 1195 [3]. Each Intermediate System
	commonly known as TLVs, and are a good way of encoding information in		(IS) [router] advertises one or more IS-IS Link State Protocol Data
	a flexible and extensible format.		Units (LSPs) with routing information. Each LSP is composed of a
			fixed header and a number of tuples, each consisting of a Type, a
			Length, and a Value. Such tuples are commonly known as TLVs, and are
			a good way of encoding information in a flexible and extensible
			format.
	The changes in this document include the design of new TLVs to		The changes in this document include the design of new TLVs to
	replace the existing IS Neighbor TLV, IP Reachability TLV and add		replace the existing IS Neighbor TLV, IP Reachability TLV and add
	additional information. Mechanisms and procedures to migrate to the		additional information. Mechanisms and procedures to migrate to the
	new TLVs are not discussed in this document.		new TLVs are not discussed in this document.
	The primary goal of these extensions is to add more information about		The primary goal of these extensions is to add more information about
	the characteristics of a particular link to an IS-IS's LSP.		the characteristics of a particular link to an IS-IS's LSP. The
	Secondary goals include increasing the dynamic range of the IS-IS		characteristics described in this document are needed for Traffic
	metric and improving the encoding of IP prefixes. The router id is		Engineering [4] (TE). Secondary goals include increasing the dynamic
	useful for traffic engineering purposes because it describes a single		range of the IS-IS metric and improving the encoding of IP prefixes.
	address that can always be used to reference a particular router.		The router id is useful for traffic engineering purposes because it
			describes a single address that can always be used to reference a
			particular router.
	This document is a publication of the IS-IS Working Group within the		This document is a publication of the IS-IS Working Group within the
	IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual		IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual
	inclusion with ISO 10589 [2].		inclusion with ISO 10589 [1].
	3.0 Introducing Sub-TLVs		2.0 Introducing Sub-TLVs
	This document introduces a new way to encode routing information in		This document introduces a new way to encode routing information in
	IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to		IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to
	regular TLVs. They use the same concepts as regular TLVs. The		regular TLVs. They use the same concepts as regular TLVs. The
	difference is that TLVs exist inside IS-IS packets, while sub-TLVs		difference is that TLVs exist inside IS-IS packets, while sub-TLVs
	exist inside TLVs. TLVs are used to add extra information to IS-IS		exist inside TLVs. TLVs are used to add extra information to IS-IS
	packets. Sub-TLVs are used to add extra information to particular		packets. Sub-TLVs are used to add extra information to particular
	TLVs. Each sub-TLV consists of three fields. A one-octet Type field,		TLVs. Each sub-TLV consists of three fields. A one-octet Type field,
	a one-octet Length field, and zero or more octets of Value. The Type		a one-octet Length field, and zero or more octets of Value. The Type
	field indicates the type of items in the Value field. The Length		field indicates the type of items in the Value field. The Length
	field indicates the length of the Value field in octets. Each sub-		field indicates the length of the Value field in octets. Each sub-
	TLV can potentially hold multiple items. The number of items in a		TLV can potentially hold multiple items. The number of items in a
	sub-TLV can be computed from the length of the whole sub-TLV, when		sub-TLV can be computed from the length of the whole sub-TLV, when
	the length of each item is known. Unknown sub-TLVs are to be ignored		the length of each item is known. Unknown sub-TLVs are to be ignored
	and skipped on receipt.		and skipped on receipt.
	4.0 The extended IS reachability TLV		The Sub-TLV type space is managed by the IETF IS-IS WG
			(http://www.ietf.org/html.charters/isis-charter.html). New type
			values are allocated following review on the IETF IS-IS mailing list.
			This will normally require publication of additional documentation
			describing how the new type is used. In the event that the IS-IS
			working group has disbanded the review shall be performed by a
			Designated Expert assigned by the responsible Area Director.
			3.0 The extended IS reachability TLV
	The extended IS reachability TLV is TLV type 22.		The extended IS reachability TLV is TLV type 22.
	The existing IS reachability (TLV type 2, defined in ISO 10589 [2])
			The existing IS reachability (TLV type 2, defined in ISO 10589 [1])
	contains information about a series of IS neighbors. For each		contains information about a series of IS neighbors. For each
	neighbor, there is a structure that contains the default metric, the		neighbor, there is a structure that contains the default metric, the
	delay, the monetary cost, the reliability, and the 7-octet ID of the		delay, the monetary cost, the reliability, and the 7-octet ID of the
	adjacent neighbor. Of this information, the default metric is		adjacent neighbor. Of this information, the default metric is
	commonly used. The default metric is currently one octet, with one		commonly used. The default metric is currently one octet, with one
	bit used to indicate that the metric is present and one bit used to		bit used to indicate that the metric is present and one bit used to
	indicate whether the metric is internal or external. The remaining 6		indicate whether the metric is internal or external. The remaining 6
	bits are used to store the actual metric, resulting a possible metric		bits are used to store the actual metric, resulting a possible metric
	range of 0-63. This limitation is one of the restrictions that we		range of 0-63. This limitation is one of the restrictions that we
	would like to lift.		would like to lift.
	skipping to change at page 3, line 33 ¶		skipping to change at line 130 ¶
	plus one octet to indicate the pseudonode number if the neighbor is		plus one octet to indicate the pseudonode number if the neighbor is
	on a LAN interface. Thus, the existing TLV consumes 11 octets per		on a LAN interface. Thus, the existing TLV consumes 11 octets per
	neighbor, with 4 octets for metric and 7 octets for neighbor		neighbor, with 4 octets for metric and 7 octets for neighbor
	identification. To indicate multiple adjacencies, this structure is		identification. To indicate multiple adjacencies, this structure is
	repeated within the IS reachability TLV. Because the TLV is limited		repeated within the IS reachability TLV. Because the TLV is limited
	to 255 octets of content, a single TLV can describe up to 23		to 255 octets of content, a single TLV can describe up to 23
	neighbors. The IS reachability TLV can be repeated within the LSP		neighbors. The IS reachability TLV can be repeated within the LSP
	fragments to describe further neighbors.		fragments to describe further neighbors.
	The proposed extended IS reachability TLV contains a new data		The proposed extended IS reachability TLV contains a new data
	structure, consisting of		structure, consisting of:
	7 octets of system Id and pseudonode number
	3 octets of default metric		7 octets of system Id and pseudonode number
	1 octet of length of sub-TLVs		3 octets of default metric
	0-244 octets of sub-TLVs,		1 octet of length of sub-TLVs
	where each sub-TLV consists of a sequence of		0-244 octets of sub-TLVs,
	1 octet of sub-type		where each sub-TLV consists of a sequence of
	1 octet of length		1 octet of sub-type
	0-242 octets of value		1 octet of length of the value field of the sub-TLV
			0-242 octets of value
	Thus, if no sub-TLVs are used, the new encoding requires 11 octets		Thus, if no sub-TLVs are used, the new encoding requires 11 octets
	and can contain up to 23 neighbors. Please note that while the		and can contain up to 23 neighbors. Please note that while the
	encoding allows for 255 octets of sub-TLVs, the maximum value cannot		encoding allows for 255 octets of sub-TLVs, the maximum value cannot
	fit in the overall IS reachability TLV. The practical maximum is 255		fit in the overall IS reachability TLV. The practical maximum is 255
	octets minus the 11 octets described above, or 244 octets. Further,		octets minus the 11 octets described above, or 244 octets. Further,
	there is no defined mechanism for extending the sub-TLV space for a		there is no defined mechanism for extending the sub-TLV space for a
	particular neighbor. Thus, wasting sub-TLV space is discouraged.		particular neighbor. Thus, wasting sub-TLV space is discouraged.
	The metric octets are encoded as a 24-bit unsigned integer. Note that		The metric octets are encoded as a 24-bit unsigned integer. Note that
	the metric field in the new extended IP reachability TLV is encoded		the metric field in the new extended IP reachability TLV is encoded
	as a 32-bit unsigned integer. These different sizes were chosen so		as a 32-bit unsigned integer. These different sizes were chosen so
	that it is very unlikely that the cost of an intra-area route has to		that it is very unlikely that the cost of an intra-area route has to
	be chopped off to fit in the metric field of an inter-area route.		be chopped off to fit in the metric field of an inter-area route.
	To preclude overflow within an SPF implementation, all metrics		To preclude overflow within a SPF implementation, all metrics greater
	greater than or equal to MAX_PATH_METRIC shall be considered to have		than or equal to MAX_PATH_METRIC SHALL be considered to have a metric
	a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC		of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such
	such that MAX_PATH_METRIC plus a single link metric does not overflow		that MAX_PATH_METRIC plus a single link metric does not overflow the
	the number of bits for internal metric calculation. We assume that		number of bits for internal metric calculation. We assume that this
	this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000,		is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32
	2^32 - 2^25).		- 2^25).
	If a link is advertised with the maximum link metric (2^24 - 1), this		If a link is advertised with the maximum link metric (2^24 - 1), this
	link should not be considered during the normal SPF computation.		link MUST NOT be considered during the normal SPF computation. This
	This will allow advertisement of a link for other purposes than		will allow advertisement of a link for other purposes than building
	building the normal Shortest Path Tree. An example is a link that is		the normal Shortest Path Tree. An example is a link that is available
	available for traffic engineering, but not for hop-by-hop routing.		for traffic engineering, but not for hop-by-hop routing.
	Certain sub-TLVs are proposed here:		Certain sub-TLVs are proposed here:
	Sub-TLV type Length (octets) Name
	3 4 Administrative group (color)		Sub-TLV type Length (octets) Name
	6 4 IPv4 interface address		3 4 Administrative group (color)
	8 4 IPv4 neighbor address		6 4 IPv4 interface address
	9 4 Maximum link bandwidth		8 4 IPv4 neighbor address
	10 4 Reservable link bandwidth		9 4 Maximum link bandwidth
	11 32 Unreserved bandwidth		10 4 Reservable link bandwidth
	18 3 TE Default metric		11 32 Unreserved bandwidth
	250-254 Reserved for cisco specific extensions		18 3 TE Default metric
	255 Reserved for future expansion		250-254 Reserved for cisco specific extensions
			255 Reserved for future expansion
	Each of these sub-TLVs is described below. Unless stated otherwise,		Each of these sub-TLVs is described below. Unless stated otherwise,
	multiple occurrences of the information are supported by multiple		multiple occurrences of the information are supported by multiple
	inclusions of the sub-TLV.		inclusions of the sub-TLV.
	4.1 Sub-TLV 3: Administrative group (color, resource class)		3.1 Sub-TLV 3: Administrative group (color, resource class)
	The administrative group sub-TLV contains a 4-octet bit mask assigned		The administrative group sub-TLV contains a 4-octet bit mask assigned
	by the network administrator. Each set bit corresponds to one		by the network administrator. Each set bit corresponds to one
	administrative group assigned to the interface.		administrative group assigned to the interface.
	By convention the least significant bit is referred to as 'group 0',		By convention the least significant bit is referred to as 'group 0',
	and the most significant bit is referred to as 'group 31'.		and the most significant bit is referred to as 'group 31'.
	4.2 Sub-TLV 6: IPv4 interface address		This sub-TLV is OPTIONAL. This sub-TLV SHOULD appear at most once in
			each extended IS reachability TLV.
			3.2 Sub-TLV 6: IPv4 interface address
	This sub-TLV contains a 4-octet IPv4 address for the interface		This sub-TLV contains a 4-octet IPv4 address for the interface
	described by the (main) TLV. This sub-TLV can occur multiple times.		described by the (main) TLV. This sub-TLV can occur multiple times.
	Implementations MUST NOT inject a /32 prefix for the interface		Implementations MUST NOT inject a /32 prefix for the interface
	address into their routing or forwarding table, because this can lead		address into their routing or forwarding table, because this can lead
	to forwarding loops when interacting with systems that do not support		to forwarding loops when interacting with systems that do not support
	this sub-TLV.		this sub-TLV.
	If a router implements the basic TLV extensions in this document, it		If a router implements the basic TLV extensions in this document, it
	is free to add or omit this sub-TLV to the description of an		MAY add or omit this sub-TLV to the description of an adjacency. If
	adjacency. If a router implements traffic engineering, it must		a router implements traffic engineering, it MUST include this sub-
	include this sub-TLV.		TLV.
	4.3 Sub-TLV 8: IPv4 neighbor address		3.3 Sub-TLV 8: IPv4 neighbor address
	This sub-TLV contains a single IPv4 address for a neighboring router		This sub-TLV contains a single IPv4 address for a neighboring router
	on this link. This sub-TLV can occur multiple times.		on this link. This sub-TLV can occur multiple times.
	Implementations MUST NOT inject a /32 prefix for the neighbor address		Implementations MUST NOT inject a /32 prefix for the neighbor address
	into their routing or forwarding table, because this can lead to		into their routing or forwarding table, because this can lead to
	forwarding loops when interacting with systems that do not support		forwarding loops when interacting with systems that do not support
	this sub-TLV.		this sub-TLV.
	If a router implements the basic TLV extensions in this document, it		If a router implements the basic TLV extensions in this document, it
	is free to add or omit this sub-TLV to the description of an		MAY add or omit this sub-TLV to the description of an adjacency. If
	adjacency. If a router implements traffic engineering, it must		a router implements traffic engineering, it MUST include this sub-TLV
	include this sub-TLV on point-to-point adjacencies.		on point-to-point adjacencies.
	4.4 Sub-TLV 9: Maximum link bandwidth		3.4 Sub-TLV 9: Maximum link bandwidth
	This sub-TLV contains the maximum bandwidth that can be used on this		This sub-TLV contains the maximum bandwidth that can be used on this
	link in this direction (from the system originating the LSP to its		link in this direction (from the system originating the LSP to its
	neighbors). This is useful for traffic engineering.		neighbors). This is useful for traffic engineering.
	The maximum link bandwidth is encoded in 32 bits in IEEE floating		The maximum link bandwidth is encoded in 32 bits in IEEE floating
	point format. The units are bytes (not bits!) per second.		point format. The units are bytes (not bits!) per second.
	4.5 Sub-TLV 10: Maximum reservable link bandwidth		This sub-TLV is optional. This sub-TLV SHOULD appear at most once in
			each extended IS reachability TLV.
			3.5 Sub-TLV 10: Maximum reservable link bandwidth
	This sub-TLV contains the maximum amount of bandwidth that can be		This sub-TLV contains the maximum amount of bandwidth that can be
	reserved in this direction on this link. Note that for		reserved in this direction on this link. Note that for
	oversubscription purposes, this can be greater than the bandwidth of		oversubscription purposes, this can be greater than the bandwidth of
	the link.		the link.
	The maximum reservable link bandwidth is encoded in 32 bits in IEEE		The maximum reservable link bandwidth is encoded in 32 bits in IEEE
	floating point format. The units are bytes (not bits!) per second.		floating point format. The units are bytes (not bits!) per second.
	4.6 Sub-TLV 11: Unreserved bandwidth		This sub-TLV is optional. This sub-TLV SHOULD appear at most once in
			each extended IS reachability TLV.
	This sub-TLV contains the amount of bandwidth reservable on this		3.6 Sub-TLV 11: Unreserved bandwidth
			This sub-TLV contains the amount of bandwidth reservable in this
	direction on this link. Note that for oversubscription purposes,		direction on this link. Note that for oversubscription purposes,
	this can be greater than the bandwidth of the link.		this can be greater than the bandwidth of the link.
	Because of the need for priority and preemption, each head end needs		Because of the need for priority and preemption, each head end needs
	to know the amount of reserved bandwidth at each priority level.		to know the amount of reserved bandwidth at each priority level.
	Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers.		Thus, this sub-TLV contains eight 32 bit IEEE floating point numbers.
	The units are bytes (not bits!) per second. The values correspond to		The units are bytes (not bits!) per second. The values correspond to
	the bandwidth that can be reserved with a setup priority 0 through 7,		the bandwidth that can be reserved with a setup priority 0 through 7,
	arranged in increasing order with priority 0 occurring at the start		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.		of the sub-TLV, and priority 7 at the end of the sub-TLV.
	For stability reasons, rapid changes in the values in this sub-TLV		For stability reasons, rapid changes in the values in this sub-TLV
	should not cause rapid generation of LSPs.		SHOULD NOT cause rapid generation of LSPs.
	4.7 Sub-TLV 18: Traffic Engineering Default metric		This sub-TLV is optional. This sub-TLV SHOULD appear at most once in
			each extended IS reachability TLV.
			3.7 Sub-TLV 18: Traffic Engineering Default metric
	This sub-TLV contains a 24-bit unsigned integer. This metric is		This sub-TLV contains a 24-bit unsigned integer. This metric is
	administratively assigned and can be used to present a differently		administratively assigned and can be used to present a differently
	weighted topology to traffic engineering SPF calculations.		weighted topology to traffic engineering SPF calculations.
	To preclude overflow within an SPF implementation, all metrics		To preclude overflow within a SPF implementation, all metrics greater
	greater than or equal to MAX_PATH_METRIC shall be considered to have		than or equal to MAX_PATH_METRIC SHALL be considered to have a metric
	a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC		of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such
	such that MAX_PATH_METRIC plus a single link metric does not overflow		that MAX_PATH_METRIC plus a single link metric does not overflow the
	the number of bits for internal metric calculation. We assume that		number of bits for internal metric calculation. We assume that this
	this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000,		is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32
	2^32 - 2^25).		- 2^25).
	If a link is advertised without this sub-TLV, traffic engineering SPF		This sub-TLV is optional. This sub-TLV SHOULD appear at most once in
	calculations must use the normal default metric of this link, which		each extended IS reachability TLV. If a link is advertised without
	is advertised in the fixed part of the extended IS reachability TLV.		this sub-TLV, traffic engineering SPF calculations MUST use the
			normal default metric of this link, which is advertised in the fixed
			part of the extended IS reachability TLV.
	5.0 The extended IP reachability TLV		4.0 The extended IP reachability TLV
	The extended IP reachability TLV is TLV type 135.		The extended IP reachability TLV is TLV type 135.
	The existing IP reachability TLVs (TLV type 128 and TLV type 130,		The existing IP reachability TLVs (TLV type 128 and TLV type 130,
	defined in RFC 1195 [3]) carry IP prefixes in a format that is		defined in RFC 1195 [3]) carry IP prefixes in a format that is
	analogous to the IS neighbor TLV from ISO 10589 [2]. They carry four		analogous to the IS neighbor TLV from ISO 10589 [1]. They carry four
	metrics, of which only the default metric is commonly used. Of this,		metrics, of which only the default metric is commonly used. Of this,
	the default metric has a possible range of 0-63. This limitation is		the default metric has a possible range of 0-63. This limitation is
	one of the restrictions that we would like to lift.		one of the restrictions that we would like to lift.
	In addition, route redistribution (a.k.a. route leaking) has a key		In addition, route redistribution (a.k.a. route leaking) has a key
	problem that was not fully addressed by the existing IP reachability		problem that was not fully addressed by the existing IP reachability
	TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in		TLVs. RFC 1195 [3] allows a router to advertise prefixes upwards in
	the level hierarchy. Unfortunately there were no mechanisms defined		the level hierarchy. Unfortunately there were no mechanisms defined
	to advertise prefixes downwards in the level hierarchy.		to advertise prefixes downwards in the level hierarchy.
	To address these two issues, the proposed extended IP reachability		To address these two issues, the proposed extended IP reachability
	TLV provides for a 32 bit metric and adds one bit to indicate that a		TLV provides for a 32 bit metric and adds one bit to indicate that a
	prefix has been redistributed 'down' in the hierarchy.		prefix has been redistributed 'down' in the hierarchy.
	The proposed extended IP reachability TLV contains a new data		The proposed extended IP reachability TLV contains a new data
	structure, consisting of:		structure, consisting of:
	4 octets of metric information
	1 octet of control information, consisting of		4 octets of metric information
	1 bit of up/down information		1 octet of control information, consisting of
	1 bit indicating the existence of sub-TLVs		1 bit of up/down information
	6 bits of prefix length		1 bit indicating the presence of sub-TLVs
	0-4 octet of IPv4 prefix		6 bits of prefix length
	0-250 optional octets of sub-TVLs, if present consisting of		0-4 octet of IPv4 prefix
	1 octet of length of sub-TLVs		0-250 optional octets of sub-TVLs, if present consisting of
	0-249 octets of sub-TLVs,		1 octet of length of sub-TLVs
	where each sub-TLV consists of a sequence of		0-249 octets of sub-TLVs,
	1 octet of sub-type		where each sub-TLV consists of a sequence of
	1 octet of length		1 octet of sub-type
	0-247 octets of value		1 octet of length of the value field of the sub-TLV
			0-247 octets of value
	This data structure can be replicated within the TLV, not to exceed		This data structure can be replicated within the TLV, not to exceed
	the maximum length of the TLV.		the maximum length of the TLV.
	The 6 bits of prefix length can have the values 0-32 and indicate the		The 6 bits of prefix length can have the values 0-32 and indicate the
	number of significant bits in the prefix. The prefix is encoded in		number of significant bits in the prefix. The prefix is encoded in
	the minimal number of octets for the given number of significant		the minimal number of octets for the given number of significant
	bits. This implies:		bits. This implies:
	Significant bits Octets		Significant bits Octets
	0 0		0 0
	1-8 1		1-8 1
	9-16 2		9-16 2
	17-24 3		17-24 3
	25-32 4		25-32 4
	The remaining bits of prefix are transmitted as zero and ignored upon		The remaining bits of prefix are transmitted as zero and ignored upon
	receipt.		receipt.
	If a prefix is advertised with a metric larger then MAX_PATH_METRIC		If a prefix is advertised with a metric larger then MAX_PATH_METRIC
	(0xFE000000, see paragraph 4.0), this prefix should not be considered		(0xFE000000, see paragraph 4.0), this prefix MUST NOT be considered
	during the normal SPF computation. This will allow advertisement of a		during the normal SPF computation. This allows advertisement of a
	prefix for other purposes than building the normal IP routing table.		prefix for other purposes than building the normal IP routing table.
	5.1 The up/down bit		4.1 The up/down bit
	Without any additional mechanisms, if routers were allowed to		Without any additional mechanisms, if routers were allowed to
	redistribute IP prefixes freely in both directions between level 1		redistribute IP prefixes freely in both directions between level 1
	and level 2, those routers can not determine looping of routing		and level 2, those routers can not determine looping of routing
	information. A problem occurs when a router learns an prefix via		information. A problem occurs when a router learns a prefix via
	level 2 routing and advertises that prefix down into a level 1 area,		level 2 routing and advertises that prefix down into a level 1 area,
	where another router might pick up the route and advertise the prefix		where another router might pick up the route and advertise the prefix
	back up into the level 2 backbone. If the original source withdraws		back up into the level 2 backbone. If the original source withdraws
	the prefix, those two routers might end up having a routing loop		the prefix, those two routers might end up having a routing loop
	between them, where part of the looped path is via level 1 routing		between them, where part of the looped path is via level 1 routing
	and the other part of the looped path is via level 2 routing. The		and the other part of the looped path is via level 2 routing. The
	solution that RFC 1195 [3] poses is to allow only advertising		solution that RFC 1195 [3] poses is to allow only advertising
	prefixes upward in the level hierarchy, and to disallow the		prefixes upward in the level hierarchy, and to disallow the
	advertising of prefixes downward in the hierarchy.		advertising of prefixes downward in the hierarchy.
	To prevent this looping of prefixes between levels, a new bit of		To prevent this looping of prefixes between levels, a new bit of
	information is defined in the new extended IP reachability TLV. This		information is defined in the new extended IP reachability TLV. This
	bit is called the up/down bit. The up/down bit shall be set to 0		bit is called the up/down bit. The up/down bit SHALL be set to 0
	when a prefix is first injected into IS-IS. If a prefix is		when a prefix is first injected into IS-IS. If a prefix is
	advertised from a higher level to a lower level (e.g. level two to		advertised from a higher level to a lower level (e.g. level two to
	level one), the bit shall be set to 1, to indicate that the prefix		level one), the bit SHALL be set to 1, to indicate that the prefix
	has traveled down the hierarchy. Prefixes that have the up/down bit		has traveled down the hierarchy. Prefixes that have the up/down bit
	set to 1 may only be advertised down the hierarchy, i.e. to lower		set to 1 may only be advertised down the hierarchy, i.e. to lower
	levels.		levels.
	These semantics apply even if IS-IS is extended in the future to have		These semantics apply even if IS-IS is extended in the future to have
	additional levels. By insuring that prefixes follow only the IS-IS		additional levels. By insuring that prefixes follow only the IS-IS
	hierarchy, we have insured that the information does not loop,		hierarchy, we have insured that the information does not loop,
	thereby insuring that there are no persistent forwarding loops.		thereby insuring that there are no persistent forwarding loops.
	If a prefix is advertised from an area to another area at the same		If a prefix is advertised from an area to another area at the same
	level, then the up/down bit shall be set to 1. This situation can		level, then the up/down bit SHALL be set to 1. This situation can
	arise when a router implements multiple virtual routers at the same		arise when a router implements multiple virtual routers at the same
	level, but in different areas.		level, but in different areas.
	The semantics of the up/down bit in the new extended IP reachability		The semantics of the up/down bit in the new extended IP reachability
	TLV are identical to the semantics of the up/down bit defined in		TLV are identical to the semantics of the up/down bit defined in RFC
	RFC 2966 [4].		2966 [2].
	5.2 Expandability of the extended IP reachability TLV with sub-TLVs		4.2 Expandability of the extended IP reachability TLV with sub-TLVs
	The extended IP reachability TLV can hold sub-TLVs that apply to a		The extended IP reachability TLV can hold sub-TLVs that apply to a
	particular prefix. This allows for easy future extensions. If there		particular prefix. This allows for easy future extensions. If there
	are no sub-TLVs associated with a prefix, the bit indicating the		are no sub-TLVs associated with a prefix, the bit indicating the
	presence of sub-TLVs shall be set to 0. If this bit is set to 1, the		presence of sub-TLVs SHALL be set to 0. If this bit is set to 1, the
	first octet after the prefix will be interpreted as the length of		first octet after the prefix will be interpreted as the length of all
	sub-TLVs. Please note that while the encoding allows for 255 octets		sub-TLVs associated with this IPv4 prefix. Please note that while
	of sub-TLVs, the maximum value cannot fit in the overall extended IP		the encoding allows for 255 octets of sub-TLVs, the maximum value
	reachability TLV. The practical maximum is 255 octets minus the 5-9		cannot fit in the overall extended IP reachability TLV. The practical
	octets described above, or 250 octets.		maximum is 255 octets minus the 5-9 octets described above, or 250
			octets.
	This document does not define any sub-TLVs yet for the extended IP		This document does not define any sub-TLVs yet for the extended IP
	reachability TLV.		reachability TLV.
	6.0 The Traffic Engineering router ID TLV		5.0 The Traffic Engineering router ID TLV
	The Traffic Engineering router ID TLV is TLV type 134.		The Traffic Engineering router ID TLV is TLV type 134.
	The router ID TLV contains the 4-octet router ID of the router		The router ID TLV contains the 4-octet router ID of the router
	originating the LSP. This is useful in several regards:		originating the LSP. This is useful in several regards:
	For traffic engineering, it guarantees that we have a single stable		For traffic engineering, it guarantees that we have a single stable
	address that can always be referenced in a path that will be		address that can always be referenced in a path that will be
	reachable from multiple hops away, regardless of the state of the		reachable from multiple hops away, regardless of the state of the
	node's interfaces.		node's interfaces.
	If OSPF is also active in the domain, traffic engineering can compute		If OSPF is also active in the domain, traffic engineering can compute
	the mapping between the OSPF and IS-IS topologies.		the mapping between the OSPF and IS-IS topologies.
			If a router does not implement traffic engineering it MAY add or omit
			the Traffic Engineering router ID TLV. If a router implements
			traffic engineering, it MUST include this TLV in its LSP. This TLV
			SHOULD not be included more than once in a LSP.
	If a router advertises the Traffic Engineering router ID TLV in its		If a router advertises the Traffic Engineering router ID TLV in its
	LSP, and if it advertises BGP routes with the BGP next hop attribute		LSP, and if it advertises prefixes via the Border Gateway Protocol
	set to the BGP router ID, in that case the Traffic Engineering router		(BGP) with the BGP next hop attribute set to the BGP router ID, in
	ID should be the same as the BGP router ID.		that case the Traffic Engineering router ID SHOULD be the same as the
			BGP router ID.
	Implementations MUST NOT inject a /32 prefix for the router ID into		Implementations MUST NOT inject a /32 prefix for the router ID into
	their forwarding table, because this can lead to forwarding loops		their forwarding table, because this can lead to forwarding loops
	when interacting with systems that do not support this TLV.		when interacting with systems that do not support this TLV.
	7.0 Security Considerations		Normative References
	This document raises no new security issues for IS-IS.		[1] ISO 10589, "Intermediate System to Intermediate System Intra-
			Domain Routeing Exchange Protocol for use in Conjunction with the
			Protocol for Providing the Connectionless-mode Network Service (ISO
			8473)" [Also republished as RFC 1142]
	8.0 Acknowledgments		[2] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS",
			T. Li, T. Przygienda, H. Smit, October 2000.
	The authors would like to thank Yakov Rekhter and Dave Katz for their		Informative References
	comments on this work.
	9.0 References		[3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual
			environments", R.W. Callon, December 1990
	[1] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D.		[4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D.
	Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September		Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September
	1999.		1999.
	[2] ISO 10589, "Intermediate System to Intermediate System Intra-		Security Considerations
	Domain Routeing Exchange Protocol for use in Conjunction with the
	Protocol for Providing the Connectionless-mode Network Service (ISO
	8473)" [Also republished as RFC 1142]
	[3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual		This document raises no new security issues for IS-IS.
	environments", R.W. Callon, December 1990
	[4] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS",		Acknowledgments
	T. Li, T. Przygienda, H. Smit, October 2000.
	10.0 Authors' Addresses		The authors would like to thank Yakov Rekhter and Dave Katz for their
			comments on this work.
			Authors' Addresses
	Tony Li		Tony Li
	Procket Networks, Inc.		Procket Networks, Inc.
	1100 Cadillac Court		1100 Cadillac Court
	Milpitas, CA 95035		Milpitas, CA 95035
	Email: tli@procket.com		Email: tli@procket.com
	Voice: +1 408 6357900		Voice: +1 408 6357900
	Fax: +1 408 6356166		Fax: +1 408 6356166
	Henk Smit		Henk Smit
	Procket Networks, Inc.		Email: hhwsmit@freeler.nl
	1100 Cadillac Court
	Milpitas, CA 95035
	Email: henk@procket.com
	Voice: +1 408 6357900
	Fax: +1 408 6356166
End of changes. 61 change blocks.
	139 lines changed or deleted		184 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/