OSPF Application-Specific Link Attributes
obsoleted by
- rfc-9492 — OSPF Application-Specific Link Attributes
Extracted elements (27)
The Application Identifier Bit Masks are placed at the ASLA sub-TLV level rather than within individual attribute sub-sub-TLVs so that the format of previously defined link attributes can be kept unchanged and reused when advertising them inside the ASLA sub-TLV.
The Extended Link Opaque LSA (OSPFv2) and E-Router-LSA (OSPFv3) were chosen as carriers for ASLA rather than the TE Opaque LSA because advertising link attributes there does not implicitly make the link part of the RSVP-TE topology, maintains a clear application distinction, and preserves the TE Opaque LSA as truly opaque to OSPF.
The solution is designed to be easily extensible: new applications can be accommodated by assigning new bits in the Application Identifier Bit Masks without altering the ASLA sub-TLV format or introducing new backwards-compatibility issues.
Zero-length Application Identifier Bit Masks (both SABM and UDABM absent) mean the link attributes are permitted for use by any standard or user-defined application. This is intentional to allow legacy-style shared advertisements, but requires care when introducing new applications that infer enablement from attribute presence (e.g., RSVP-TE).
It is RECOMMENDED to continue advertising RSVP-TE link attributes in the existing OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA for backwards compatibility; RSVP-TE can eventually use application-specific advertisements only for newly defined link attributes designated as application-specific.
Migration from legacy to ASLA advertisements requires a staged approach: (1) send new application-specific advertisements while retaining legacy ones, (2) enable use of application-specific advertisements on all routers, and (3) keep legacy advertisements if needed for RSVP-TE. Only after full migration can incongruent per-application attribute values be advertised.
Routers that do not support the extensions defined in this document will only process legacy TE Opaque LSA advertisements and will infer RSVP-TE is enabled on any link for which legacy advertisements exist. Deployments with a mix of legacy and upgraded routers must maintain legacy advertisements while any legacy router remains in the network.
An application-specific advertisement (ASLA with a matching Application Identifier Bit set) for an attribute MUST always be preferred over an advertisement of the same attribute with zero-length Application Identifier Bit Masks on the same link.
If existing advertisements use zero-length Application Identifier Bit Masks and a new application is introduced that should not use those advertisements, existing advertisements MUST be re-advertised with an explicit set of applications specified before the new application is introduced.
If the same attribute is advertised in more than one ASLA sub-TLV with the application listed in the Application Identifier Bit Masks, the application SHOULD use the first instance and ignore any subsequent advertisements of that attribute.
In cases where multiple applications share a link and one is RSVP-TE, attributes for applications other than RSVP-TE MUST be advertised using application-specific advertisements even when legacy RSVP-TE advertisements are also present.
In deployments mixing legacy and ASLA-capable routers, so long as any legacy router has any application enabled, all routers MUST continue to advertise link attributes using legacy advertisements to maintain interoperability.
Maximum link bandwidth is an application-independent attribute and MUST NOT be advertised in the ASLA sub-TLV; it MAY be advertised as a direct sub-TLV of the Extended Link TLV (OSPFv2 type 23) or Router-Link TLV (OSPFv3 type 23).
Maximum reservable link bandwidth and unreserved bandwidth MUST use the OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA and MUST NOT be advertised in the ASLA sub-TLV, as these are not application-specific attributes.
New applications that future documents define to use ASLA advertisements MUST NOT make use of RSVP-TE LSA advertisements (OSPFv2 TE Opaque LSA or OSPFv3 Intra-Area-TE-LSA), simplifying deployment by eliminating multiple advertisement paths.
The ASLA sub-TLV MUST be used for advertisement of a defined set of link attributes (SRLG, extended metrics, administrative group, extended administrative group, TE metric) if these are advertised inside the OSPFv2 Extended Link TLV or OSPFv3 Router-Link TLV.
The Local Interface IPv6 Address and Remote Interface IPv6 Address sub-TLVs are application-independent and MUST NOT be advertised in the ASLA sub-TLV; they MAY be advertised as sub-TLVs of the OSPFv3 Router-Link TLV (types 24 and 25, respectively).
The SABM Length and UDABM Length fields MUST each be set to 0, 4, or 8. If either field is absent, its length MUST be set to 0. If either length is any value other than 0, 4, or 8, the entire ASLA sub-TLV MUST be ignored by the receiver.
Undefined bits in the SABM and UDABM that are transmitted MUST be set to 0. On receipt, undefined bits and bits not supported by an implementation MUST be ignored. Bits that are not transmitted MUST be treated as if set to 0.
The Application-Specific Link Attributes (ASLA) sub-TLV is a sub-TLV of the OSPFv2 Extended Link TLV (type 10) and OSPFv3 Router-Link TLV (type 11). It carries a Standard Application Identifier Bit Mask (SABM), a User-Defined Application Identifier Bit Mask (UDABM), and nested link attribute sub-sub-TLVs, enabling per-application advertisement of link attributes.
The Standard Application Identifier Bit Mask defines three initial application bits: bit 0 (R-bit) for RSVP-TE, bit 1 (S-bit) for Segment Routing Policy, and bit 2 (F-bit) for Loop-Free Alternate (LFA, including all LFA types). Bit assignments are managed in the 'Link Attribute Applications' registry defined in RFC 8919.
The 'OSPFv2 Extended Link TLV Sub-TLVs' registry (RFC 7684) is updated with new sub-TLV types: 10 (ASLA), 11 (SRLG), 12–18 (extended metrics), 19–20 (administrative groups), 22 (TE Metric), 23 (Maximum link bandwidth). Allocations use the IETF Review procedure.
The 'OSPFv3 Extended-LSA Sub-TLVs' registry (RFC 8362) is updated with new sub-TLV types: 11 (ASLA), 12 (SRLG), 13–19 (extended metrics), 20–21 (administrative groups), 22 (TE Metric), 23 (Maximum link bandwidth), 24 (Local Interface IPv6 Address), 25 (Remote Interface IPv6 Address).
Implementations MUST ensure malformed TLVs and sub-TLVs defined in this document are detected and do not enable attackers to crash the OSPF router or routing process. Reception of malformed TLVs SHOULD be counted and/or logged, and such logging SHOULD be rate-limited to prevent the OSPF control plane from being overwhelmed by a DoS attack.
In deployments where potential attackers may have access to networks within the OSPF routing domain, stronger authentication mechanisms such as those in RFC 5709 (OSPFv2 HMAC-SHA), RFC 7474, RFC 4552 (OSPFv3 auth/confidentiality), or RFC 7166 SHOULD be used.
Tampering with the link attribute information defined in this document may impact applications using it, including traffic engineering path computation. Because ASLA advertisements scope their impact to specific applications via bit masks, the blast radius of tampering is similarly scoped compared to legacy TE advertisements.
The ASLA sub-TLV has a 4-octet header (Type 2 octets, Length 2 octets) followed by SABM Length (1 octet), UDABM Length (1 octet), Reserved (2 octets), then variable-length SABM and UDABM fields, then link attribute sub-sub-TLVs. SABM Length and UDABM Length each encode the length of their respective bit mask in octets.