OSPF Application-Specific Link Attributes
obsoletes
- rfc-8920 — OSPF Application-Specific Link Attributes
Extracted elements (26)
The Application Identifier Bit Masks are kept separate from individual attribute advertisement formats so that the format of any previously defined link attributes can be kept and reused when advertising them in the ASLA sub-TLV without modification.
The Extended Link Opaque LSA (OSPFv2) and E-Router-LSA (OSPFv3) were chosen as the container for ASLA advertisements because advertising link attributes there does not make the link part of the RSVP-TE topology, keeping TE Opaque LSAs and Intra-Area-TE-LSAs truly opaque to OSPF as originally intended.
This document obsoletes RFC 8920 primarily to clarify normative behavior around zero-length SABM/UDABM advertisements. RFC 8920 used the word 'permitted' suggesting optional use, which created interoperability risks. The replacement text makes explicit the conditions under which such advertisements MUST and MUST NOT be used.
Zero-length Application Identifier Bit Masks are defined to allow link attributes to be used by any application, minimizing duplicate advertisements in common cases where multiple applications share the same attribute values. However, this creates ambiguity for applications like RSVP-TE that infer enablement from advertisement presence.
Routers that do not support the ASLA extensions will only process legacy RSVP-TE advertisements and may incorrectly infer RSVP-TE is enabled on links where only non-RSVP-TE application attributes are being advertised. Migration requires sending both legacy and application-specific advertisements simultaneously before cutover.
Standard applications (RSVP-TE, SR Policy, LFA) may continue to use RSVP-TE LSA advertisements when: the application is RSVP-TE, or RSVP-TE is not deployed anywhere, or SR Policy/LFA link sets and attribute values are fully congruent with RSVP-TE. Otherwise, application-specific ASLA advertisements must be used.
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 of advertisement and ignore any subsequent advertisements of that attribute.
In cases where multiple applications use a given link and one is RSVP-TE, attributes for applications other than RSVP-TE MUST be advertised using application-specific advertisements. Legacy advertisements are used for RSVP-TE, resulting in duplicate advertisements for shared attributes.
It is RECOMMENDED to advertise all link attributes for RSVP-TE in the existing OSPFv2 TE Opaque LSA and OSPFv3 Intra-Area-TE-LSA to maintain backwards compatibility. Link attributes not allowed in the ASLA sub-TLV (e.g., maximum reservable link bandwidth, unreserved bandwidth) MUST use those legacy LSAs and MUST NOT be advertised in the ASLA sub-TLV.
Link attributes advertised with zero-length Application Identifier Bit Masks MUST be used by standard and/or user-defined applications when no link attribute advertisements with a non-zero-length matching Application Identifier Bit are present. Otherwise, such advertisements MUST NOT be used.
Maximum link bandwidth is an application-independent attribute and MUST NOT be advertised in the ASLA sub-TLV. Instead, it MAY be advertised as a sub-TLV of the Extended Link TLV in OSPFv2 (type 23) or Router-Link TLV in OSPFv3 (type 23).
New applications that future documents define to make use of ASLA advertisements MUST NOT make use of RSVP-TE LSA advertisements. This simplifies deployment by eliminating the need to support multiple advertisement methods for new applications.
SABM Length and UDABM Length values MUST be 0, 4, or 8. If either length is other than these values, the ASLA sub-TLV MUST be ignored by the receiver.
So long as there is any legacy router in the network that has any of the standard applications enabled, all routers MUST continue to advertise link attributes for these applications using only legacy advertisements. ASLA advertisements for these applications MUST NOT be sent.
The ASLA sub-TLV MUST be used for advertisement of specified link attributes (SRLG, extended metrics, administrative group, TE metric, etc.) if these are advertised inside the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV.
The Local Interface IPv6 Address sub-TLV and Remote Interface IPv6 Address sub-TLV are application-independent attributes and MUST NOT be advertised in the ASLA sub-TLV. They MAY be advertised as sub-TLVs of the Router-Link TLV inside the OSPFv3 E-Router-LSA (types 24 and 25 respectively).
Reused TE link attribute sub-TLVs for OSPFv2 Extended Link TLV include: SRLG (type 11), Unidirectional Link Delay (type 12), Min/Max Unidirectional Link Delay (type 13), Unidirectional Delay Variation (type 14), Unidirectional Link Loss (type 15), Residual/Available/Utilized Bandwidth (types 16-18), Administrative Group (type 19), Extended Administrative Group (type 20), TE Metric (type 22), Maximum link bandwidth (type 23).
Reused TE link attribute sub-TLVs for OSPFv3 Router-Link TLV include: ASLA (type 11), SRLG (type 12), Unidirectional Link Delay (type 13), Min/Max Unidirectional Link Delay (type 14), Unidirectional Delay Variation (type 15), Link Loss (type 16), Residual/Available/Utilized Bandwidth (types 17-19), Administrative Group (type 20), Extended Administrative Group (type 21), TE Metric (type 22), Maximum link bandwidth (type 23), Local Interface IPv6 Address (type 24), Remote Interface IPv6 Address (type 25).
The Application-Specific Link Attributes (ASLA) sub-TLV is defined as a sub-TLV of the OSPFv2 Extended Link TLV (type 10) and OSPFv3 Router-Link TLV (type 11). It contains Standard Application Identifier Bit Mask (SABM), User-Defined Application Identifier Bit Mask (UDABM), and Link Attribute sub-TLVs, allowing advertisement of application-specific link attribute values.
The Standard Application Identifier Bit Mask (SABM) defines bits for: Bit 0 (R-bit) for RSVP-TE, Bit 1 (S-bit) for SR Policy (data plane independent), and Bit 2 (F-bit) for Loop-Free Alternate (includes all LFA types). Bit assignments are managed via the 'Link Attribute Application Identifiers' registry defined in RFC 9479.
This document updates the 'OSPFv2 Extended Link TLV Sub-TLVs' registry (originally defined in RFC 7684), assigning types 10-23 for ASLA and reused TE link attributes including SRLG, extended metrics, administrative groups, TE metric, and maximum link bandwidth.
This document updates the 'OSPFv3 Extended-LSA Sub-TLVs' registry (originally defined in RFC 8362), assigning types 11-25 for ASLA and reused TE link attributes including SRLG, extended metrics, administrative groups, TE metric, maximum link bandwidth, and local/remote interface IPv6 addresses.
Existing OSPF security extensions (RFC 2328, RFC 5340, RFC 8362) apply. In deployments where potential attackers have access to one or more OSPF networks, stronger authentication mechanisms (RFC 5709, RFC 7474, RFC 4552, or RFC 7166) SHOULD be used.
Implementations must detect malformed TLVs and sub-TLVs and ensure they do not facilitate vulnerabilities. Reception of a malformed TLV SHOULD be counted and/or logged, and such logging SHOULD be rate-limited to prevent denial-of-service attacks from overloading the OSPF control plane.
Tampering with ASLA link attribute advertisements may impact applications using them, including TE path computation. Because ASLA advertisements limit scope to specific applications, the impact of tampering is similarly limited in scope compared to legacy advertisements.
The ASLA sub-TLV format includes: 2-octet Type, 2-octet Length, 1-octet SABM Length (must be 0, 4, or 8), 1-octet UDABM Length (must be 0, 4, or 8), 2-octet Reserved, variable-length SABM, variable-length UDABM, and Link Attribute sub-TLVs. Type is 10 for OSPFv2 and 11 for OSPFv3.