ietf-corpus

rfc-3630

Traffic Engineering (TE) Extensions to OSPF Version 2

D. Katz, K. Kompella, D. Yeung
date2003-10 streamIETF areartg wgospf statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc3630 doi10.17487/RFC3630
This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link State Advertisements.

updated by

updates

Extracted elements (26)

design-rationale §2.4.2

Only one Link TLV is permitted per TE LSA to allow fine-granularity topology change updates; a single link change can be flooded without bundling unrelated link changes in the same LSA.

routing

design-rationale §2.1

Only Type 10 (area-local scope) Opaque LSAs are used, deliberately restricting TE information distribution to a single OSPF area. Inter-area and inter-AS TE distribution is explicitly left for future documents.

routing

design-rationale §1

The TE extensions deliberately make no changes to OSPFv2 flooding procedures. The existing Network LSA is reused for multi-access link descriptions, avoiding the need for a new LSA type for multi-access topology.

routing

interoperability-note §2.4.1

If IS-IS is also active in the domain, the Router Address TLV can be used to correlate OSPF and IS-IS TE LSAs from the same router, enabling a unified Traffic Engineering Database (TED) to be built from both protocols.

routing

interoperability-note §4

Routers that do not implement these TE extensions will silently ignore Opaque LSAs, so there are no interoperability issues. The result is that the traffic engineering topology will be incomplete, but if the topology is connected, TE paths can still be computed.

routing

normative-requirement §2.4.1 SHOULD

If a router advertises BGP routes with the BGP next-hop set to the BGP router ID, the Router Address TLV SHOULD be set to the same value as the BGP router ID.

routing, bgp

normative-requirement §1 MUST

Non-TE-capable nodes MUST flood TE LSAs as any other type 10 area-local scope Opaque LSAs, ensuring TE topology information is propagated across the area even when intermediate routers do not understand TE extensions.

routing

normative-requirement §2.5.7 SHOULD

The Maximum Reservable Bandwidth SHOULD be user-configurable; the default value should equal the Maximum Bandwidth.

routing, qos

normative-requirement §3 SHOULD

The origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one per MinLSInterval. Implementations MAY set thresholds (e.g., bandwidth change threshold) that trigger immediate flooding while batching smaller changes.

routing

normative-requirement §2.4.2 REQUIRED

Within the Link TLV, the Link Type (sub-TLV 1) and Link ID (sub-TLV 2) are mandatory and must appear exactly once. All other sub-TLVs defined in this document may occur at most once. Unrecognized sub-TLVs are ignored.

routing

protocol-element §2.5.9

The Administrative Group sub-TLV (type 9, 4 octets) is a bitmask where each bit represents an administrative group (also called Resource Class or Color). Bit 0 (LSB) is group 0, bit 31 (MSB) is group 31. A link may belong to multiple groups.

routing, qos

protocol-element §2.5.2

The Link ID sub-TLV (type 2, 4 octets) identifies the far end of the link: the neighbor's Router ID for point-to-point links, or the interface address of the designated router for multi-access links. The value is identical to the Link ID field in the Router LSA.

routing

protocol-element §2.4.2

The Link TLV (type 2, variable length) describes a single link using a set of sub-TLVs with no required ordering. Only one Link TLV shall be carried per LSA to allow fine-granularity topology change updates.

routing

protocol-element §2.5.1

The Link Type sub-TLV (type 1, 1 octet) defines the link type: value 1 for point-to-point, value 2 for multi-access.

routing

protocol-element §2.5.7

The Maximum Reservable Bandwidth sub-TLV (type 7, 4 octets) specifies the maximum bandwidth that may be reserved on the link in a given direction. This value MAY exceed the Maximum Bandwidth, enabling oversubscription.

routing, qos

protocol-element §2.4.1

The Router Address TLV (type 1, length 4, value is a 4-octet IP address) specifies a stable, always-reachable IP address of the advertising router, typically a loopback. It must appear in exactly one TE LSA originated by a router.

routing

protocol-element §2.1

The Traffic Engineering LSA is a Type 10 (area-local scope) Opaque LSA used to distribute TE topology information within an OSPF area. It describes routers, point-to-point links, and connections to multi-access networks, analogous to a Router LSA but with extended link attributes.

routing, mpls, registry

protocol-element §2.5.8

The Unreserved Bandwidth sub-TLV (type 8, 32 octets) specifies available bandwidth at each of eight priority levels (0–7) in IEEE floating point format, with priority 0 at the start. Initial values equal Maximum Reservable Bandwidth; each value must not exceed Maximum Reservable Bandwidth.

routing, qos

protocol-element §3

Upon receipt of a changed TE LSA or Network LSA, a router should update its traffic engineering database. No SPF or other route calculations are required, as TE LSAs are not used for normal IP routing.

routing

registry §6

IANA maintains a registry for sub-TLV Types within the Link TLV. Sub-types 1–9 are defined by this document; sub-types 10–32767 require Standards Action; sub-types 32768–32777 are experimental (MUST NOT be mentioned by RFCs); sub-types 32778–65535 are reserved.

routing, registry

registry §6

IANA maintains a registry for top-level TLV Types in TE LSAs. Types 1–2 are defined by this document; types 3–32767 require Standards Action; types 32768–32777 are for experimental use and MUST NOT be mentioned by RFCs; types 32778–65535 are reserved pending a Standards Track RFC.

routing, registry

security-consideration §5

Future OSPFv2 security and authentication mechanisms should be designed to be general enough to cover Opaque LSAs, ensuring TE LSAs receive the same protection as standard LSA types.

routing, security

security-consideration §5

TE LSAs are not used for SPF computation or normal IP routing, so tampering with them does not directly affect IP forwarding. However, tampering can corrupt traffic engineering computations; therefore all security mechanisms applied to normal OSPF LSAs (including RFC 2328 and RFC 2154 digital signatures) should equally apply to Opaque TE LSAs.

routing, security

wire-format §2.4.2

Bandwidth values in the Link TLV (Maximum Bandwidth, Maximum Reservable Bandwidth, Unreserved Bandwidth) are encoded in 32-bit IEEE 754 floating point format with units of bytes per second.

routing

wire-format §2.3.2

Each TLV in the TE LSA payload has a 16-bit Type field, a 16-bit Length field (value portion only, in octets), and a variable-length Value field. TLVs are padded to 4-octet alignment; padding is not included in the Length. Unrecognized types are ignored.

routing

wire-format §2.2

The LSA ID field is 32 bits: the high 8 bits are the Opaque type (value 1 for TE LSA), and the low 24 bits are an Instance field. Up to 16,777,216 TE LSAs may be sourced by a single router. The LSA ID has no topological significance.

routing