rfc-5329

Traffic Engineering Extensions to OSPF Version 3

K. Ishiguro, V. Manral, A. Davey, A. Lindem (Editor)
date2008-09 streamIETF areartg wgospf statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc5329 doi10.17487/RFC5329
This document describes extensions to OSPFv3 to support intra-area Traffic Engineering (TE). This document extends OSPFv2 TE to handle IPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. [STANDARDS-TRACK]

Extracted elements (23)

design-rationale §4

The OSPFv2 Link ID sub-TLV cannot be used in OSPFv3 because it relies on IPv4 interface addresses to identify the DR on multi-access networks. OSPFv3 always uses Router IDs for neighbor identification, requiring a new Neighbor ID sub-TLV carrying both Neighbor Interface ID and Neighbor Router ID.

routing, ip

design-rationale §2

Unlike OSPFv2 TE which uses Opaque LSAs to carry TE information, OSPFv3 defines a dedicated Intra-Area-TE-LSA type, exploiting OSPFv3's flexible U-bit flooding mechanism that ensures area-scoped flooding even by routers that do not recognize the new LSA type.

routing

interoperability-note §1

GMPLS (RFC 4203) and Diff-Serv MPLS (RFC 3270) extensions based on OSPFv2 TE can also be extended to OSPFv3 by utilizing the TLVs and sub-TLVs defined in this document.

routing, mpls

normative-requirement §3 MUST NOT

A link-local address MUST NOT be specified for the Router IPv6 Address TLV. The TLV MUST appear in exactly one Traffic Engineering LSA originated by an OSPFv3 router supporting TE extensions.

routing, ip

normative-requirement §6 SHOULD

An implementation of the OSPFv3 TE extensions SHOULD provide appropriate hooks or instrumentation to allow the MIB objects defined in [OSPFV3-MIB] to be implemented, including ospfv3AreaTEEnabled and ospfv3IfTEDisabled variables.

routing, snmp

normative-requirement §4.1 MUST

In OSPFv3, the Link ID sub-TLV SHOULD NOT be sent and MUST be ignored upon receipt; the Neighbor ID sub-TLV MUST be used for link identification instead.

routing

normative-requirement §4.4 MUST NOT

Link-local addresses MUST NOT be advertised in the Remote Interface IPv6 Address sub-TLV. Neighbor addresses from link-LSAs with prefix length 128 and LA-bit set MAY be advertised.

routing, ip

normative-requirement §4 MUST

The Neighbor ID sub-TLV is mandatory for OSPFv3 TE support and MUST appear exactly once in a Link TLV. All other sub-TLVs defined in this document SHOULD NOT occur more than once; subsequent instances are ignored.

routing

normative-requirement §2 MUST

When the U-bit is set to 1, an OSPFv3 router MUST flood the LSA at its defined flooding scope even if it does not recognize the LS type.

routing

protocol-element §2.1

An Intra-Area-TE-LSA contains exactly one top-level TLV, either a Link TLV (type 2) or a Router IPv6 Address TLV (type 3).

routing

protocol-element §2

The Intra-Area-TE-LSA is a new OSPFv3 LSA type with function code 10, U-bit set, and area scope (01). The Link State ID is an arbitrary value with no topological significance used to maintain multiple TE LSAs.

routing

protocol-element §4

The Link TLV describes a single link via sub-TLVs inherited from OSPFv2 TE, except the Link ID sub-TLV which cannot be used in OSPFv3. Three new sub-TLVs are defined: Neighbor ID (18), Local Interface IPv6 Address (19), and Remote Interface IPv6 Address (20).

routing, ip

protocol-element §4.3

The Local Interface IPv6 Address sub-TLV (type 19) specifies one or more IPv6 addresses of the local interface. Multiple addresses MAY be listed; link-local addresses MUST NOT be included. Length is always a multiple of 16 octets.

routing, ip

protocol-element §4.2

The Neighbor ID sub-TLV (type 18, length 8) carries the Neighbor Interface ID (4 octets) and Neighbor Router ID (4 octets), replacing the OSPFv2 Link ID for neighbor link identification in OSPFv3.

routing

protocol-element §4.4

The Remote Interface IPv6 Address sub-TLV (type 20) advertises the neighbor's interface IPv6 address(es) and is used together with the Local Interface IPv6 Address sub-TLV to distinguish parallel links. For multi-access links, the value MAY be set to :: or the sub-TLV may be omitted.

routing, ip

protocol-element §3

The Router IPv6 Address TLV (type 3, length 16) advertises a stable, routable 16-octet IPv6 address reachable via the OSPFv3 router. It must not contain a link-local address.

routing, ip

registry §7

This document assigns OSPFv3 LSA type function code 10 to the Intra-Area-TE-LSA, Router IPv6 Address TLV type 3 from the OSPF TE TLVs registry, and Neighbor ID (18), Local Interface IPv6 Address (19), and Remote Interface IPv6 Address (20) sub-TLV types from the OSPF TE sub-TLVs registry.

registry, routing

security-consideration §5

The OSPFv3 TE extensions do not create new security issues beyond those already present in the base OSPFv3 protocol and OSPFv2 TE. Security considerations from both [OSPFV3] and [TE] apply.

security, routing

wire-format §2

The Intra-Area-TE-LSA header encodes LS type as 0xA020 (U-bit=1, scope=01, function code=10) in a 16-bit field. The LSA body contains one or more nested TLV triplets with 16-bit Type, 16-bit Length, and variable-length Value fields padded to 4-octet alignment.

routing

wire-format §4.3

The Local Interface IPv6 Address sub-TLV has a 16-bit Type (19), a 16-bit Length that MUST be a multiple of 16, and a value consisting of one or more 16-octet global IPv6 addresses.

routing, ip

wire-format §4.2

The Neighbor ID sub-TLV encodes a 16-bit Type (18), 16-bit Length (always 8), followed by a 32-bit Neighbor Interface ID and a 32-bit Neighbor Router ID.

routing

wire-format §4.4

The Remote Interface IPv6 Address sub-TLV has a 16-bit Type (20), a 16-bit Length that MUST be a multiple of 16, and a variable-length list of 16-octet remote IPv6 interface addresses.

routing, ip

wire-format §3

The Router IPv6 Address TLV has a 16-bit Type field set to 3, a 16-bit Length field always set to 16, and a 16-octet value containing a stable routable IPv6 address.

routing, ip