ietf-corpus

rfc-5305

IS-IS Extensions for Traffic Engineering

T. Li, H. Smit
date2008-10 streamIETF areartg wgisis statusPROPOSED STANDARD pages17 canonicalhttps://www.rfc-editor.org/rfc/rfc5305 doi10.17487/RFC5305
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (26)

design-rationale §3

MAX_PATH_METRIC is defined as 4,261,412,864 (0xFE000000, 2^32 - 2^25) to prevent SPF overflow: the value is chosen so that MAX_PATH_METRIC plus a single link metric does not overflow 32 bits, the assumed internal metric calculation width.

routing

design-rationale §3

The Extended IS Reachability TLV uses a 24-bit metric while the Extended IP Reachability TLV uses a 32-bit metric. This asymmetry is intentional: it makes it very unlikely that the cost of an intra-area route exceeds the capacity of the inter-area metric field, avoiding truncation of route costs when leaking between levels.

routing

design-rationale §4.3

The Traffic Engineering Router ID TLV provides a single stable loopback-style address for TE computation, ensuring that path references remain valid regardless of individual interface state changes, and enabling OSPF-to-IS-IS topology mapping when both protocols are active.

routing

design-rationale §4.1

The up/down bit prevents routing loops when prefixes are redistributed between IS-IS levels. Without it, a prefix learned via level 2 could be advertised down to level 1 and then readvertised back up to level 2, causing persistent forwarding loops if the original source withdraws the prefix.

routing

interoperability-note §4.3

If a router advertises the TE Router ID TLV and also advertises prefixes via BGP with the BGP next-hop attribute set to the BGP router ID, the TE Router ID SHOULD be the same as the BGP router ID to ensure consistent topology references.

routing, bgp

interoperability-note §3

Sub-TLV types 250-254 are reserved for Cisco-specific extensions and type 255 is reserved for future expansion in the Extended IS Reachability TLV sub-TLV registry, enabling backward compatibility with deployed Cisco implementations.

routing

normative-requirement §3 MUST NOT

A link advertised with the maximum link metric (2^24 - 1) MUST NOT be considered during normal SPF computation, allowing the link to be advertised for TE purposes without participating in hop-by-hop routing.

routing

normative-requirement §3.6 SHOULD NOT

For stability reasons, rapid changes in Unreserved Bandwidth (Sub-TLV 11) values SHOULD NOT cause rapid generation of LSPs.

routing

normative-requirement §3.7 MUST

If a link is advertised without Sub-TLV 18 (TE Default Metric), traffic engineering SPF calculations MUST use the normal default metric advertised in the fixed part of the extended IS reachability TLV.

routing

normative-requirement §4 MUST NOT

If a prefix is advertised with a metric larger than MAX_PATH_METRIC (0xFE000000), this prefix MUST NOT be considered during the normal SPF computation, allowing advertisement for purposes other than normal IP routing.

routing, ip

normative-requirement §4.3 MUST

If a router implements traffic engineering, it MUST include the Traffic Engineering Router ID TLV (type 134) in its LSP. Implementations MUST NOT inject a /32 prefix for the router ID into their forwarding table.

routing

normative-requirement §3.2 MUST NOT

Implementations MUST NOT inject a /32 prefix for the IPv4 interface address (Sub-TLV 6) or neighbor address (Sub-TLV 8) into their routing or forwarding table, as this can cause forwarding loops with systems not supporting these sub-TLVs.

routing, ip

normative-requirement §4.1 MUST

The up/down bit SHALL be set to 0 when a prefix is first injected into IS-IS, and MUST be set to 1 when a prefix is advertised from a higher level to a lower level (e.g., level 2 to level 1). Prefixes with the up/down bit set to 1 may only be advertised down the hierarchy.

routing

normative-requirement §2 OPTIONAL

Unknown sub-TLVs are to be ignored and skipped upon receipt, providing forward compatibility for future sub-TLV extensions.

routing

protocol-element §3.1

Sub-TLV 3 (Administrative Group / color / resource class) carries a 4-octet bitmask where each set bit corresponds to one administrative group assigned to the interface. The least significant bit is group 0 and the most significant is group 31.

routing

protocol-element §4

The Extended IP Reachability TLV (type 135) replaces TLV types 128 and 130, providing a 32-bit metric, a 6-bit prefix length, variable-length IPv4 prefix (0-4 octets), and a control byte with up/down bit and sub-TLV presence indicator.

routing, ip

protocol-element §3

The Extended IS Reachability TLV (type 22) replaces the existing IS Neighbor TLV (type 2) and encodes each neighbor entry as 7 octets of system ID and pseudonode number, 3 octets of default metric (24-bit unsigned integer), 1 octet sub-TLV length, and 0-244 octets of sub-TLVs.

routing

protocol-element §4.3

The Traffic Engineering Router ID TLV (type 134) carries the 4-octet router ID of the originating IS, providing a single stable address for TE path computation and OSPF-to-IS-IS topology mapping.

routing

registry §5.2.2

A new IANA registry for Sub-TLVs of the Extended IP Reachability TLV (TLV 135) is created with values 0-255, requiring Designated Expert approval. No codepoints are defined by this document.

routing, registry

registry §5.1

Three new TLV codepoints are registered in the IS-IS TLV codepoint registry: type 22 (Extended IS Reachability TLV), type 134 (TE Router ID TLV), and type 135 (Extended IP Reachability TLV), all valid in LSPs only.

routing, registry

security-consideration §6

This document raises no new security issues for IS-IS. General IS-IS security considerations, including cryptographic authentication, are addressed in RFC 5304.

routing, security

wire-format §3

Each entry in the Extended IS Reachability TLV (type 22) encodes: 7-octet system ID + pseudonode number, 3-octet default metric (24-bit unsigned integer), 1-octet sub-TLV length, followed by 0-244 octets of sub-TLVs. Each sub-TLV consists of 1-octet sub-type, 1-octet value length, and 0-242 octets of value.

routing

wire-format §3.7

Sub-TLV 18 (TE Default Metric) carries a 24-bit unsigned integer representing an administratively assigned metric for TE SPF calculations. It is 3 octets in length and SHOULD appear at most once per Extended IS Reachability TLV entry.

routing

wire-format §3.2

Sub-TLV 6 (IPv4 Interface Address) and Sub-TLV 8 (IPv4 Neighbor Address) each carry a single 4-octet IPv4 address (fixed length 4 octets); both may occur multiple times within the Extended IS Reachability TLV.

routing, ip

wire-format §3.4

Sub-TLVs 9 (Maximum Link Bandwidth) and 10 (Maximum Reservable Link Bandwidth) each carry a 4-octet IEEE 754 floating-point value in bytes per second. Sub-TLV 11 (Unreserved Bandwidth) carries eight such 4-octet IEEE floating-point values (32 octets total), one per priority level 0-7.

routing

wire-format §4

The Extended IP Reachability TLV (type 135) encodes each prefix entry as: 4-octet metric, 1-octet control (1 bit up/down, 1 bit sub-TLV presence, 6 bits prefix length), 0-4 octets of IPv4 prefix (minimal encoding by significant bits), and optional sub-TLVs preceded by a 1-octet length field.

routing, ip