IS-IS Application-Specific Link Attributes
obsoleted by
- rfc-9479 — IS-IS Application-Specific Link Attributes
Extracted elements (27)
Existing legacy link attribute advertisements do not support application-specific values for a given attribute, nor do they indicate which applications are using the advertised value. This creates ambiguity when multiple applications (e.g., RSVP-TE and SR Policy) coexist, potentially causing RSVP-TE head-end routers to attempt path setup over links not enabled for RSVP-TE.
For RSVP-TE, advertisement of application-specific link attributes implies RSVP is enabled on that link, while for SR Policy and LFA, such advertisements do not imply enablement — SR Policy is implicitly enabled on all SR-topology links and LFA is controlled by local configuration.
The solution is designed to be easily extensible to new applications and new use cases without altering advertisement formats or introducing backwards-compatibility issues, since evolution of link attribute use cases is expected to continue.
In deployments where multiple applications share all link attributes with RSVP-TE, interoperability is achieved by using legacy advertisements combined with ASLA advertisements with the L-flag set and no link attribute values, avoiding duplication.
Migration from legacy to ASLA advertisements requires a three-step process: (1) send ASLA while continuing legacy (duplicated advertisements), (2) enable use of ASLA on all routers, (3) remove legacy advertisements. Only after migration can incongruent per-application values be advertised.
So long as any legacy router in the network has any of the defined applications (RSVP-TE, SR Policy, LFA) enabled, all routers MUST continue to advertise link attributes using legacy advertisements, since legacy routers will only process legacy advertisements.
At least one set of link identifiers (IPv4, IPv6, or Link Local/Remote) MUST be present in the Application-Specific SRLG TLV. Multiple occurrences of the same identifier type MUST NOT be present. TLVs not meeting this requirement MUST be ignored.
For a given application, the setting of the L-flag MUST be the same in all ASLA sub-TLVs for a given link. If this constraint is violated, the L-flag MUST be considered set for that application.
If the SABM or UDABM Length in the Application Identifier Bit Mask is greater than 8, the entire ASLA sub-TLV MUST be ignored.
Maximum link bandwidth is an application-independent attribute; when advertised using the ASLA sub-TLV, multiple different values for the same link MUST NOT be advertised. If different values are advertised, all values MUST be ignored.
Maximum reservable link bandwidth and unreserved bandwidth are RSVP-TE-specific; when advertised in the ASLA sub-TLV, bits other than the RSVP-TE R-bit MUST NOT be set. Advertisements with other bits set MUST be ignored.
New applications that future documents define to use these advertisements MUST NOT make use of legacy advertisements, simplifying deployment by eliminating the need to support multiple advertisement mechanisms for new applications.
SABM and UDABM lengths SHOULD be the minimum required to send all bits that are set, in order to minimize advertisement size.
Undefined bits in SABM/UDABM that are transmitted MUST be transmitted as 0 and MUST be ignored on receipt. Bits that are not transmitted MUST be treated as if set to 0 on receipt. Bits not supported by an implementation MUST be ignored on receipt.
When conflicting values for the same application/attribute/link are advertised in multiple ASLA sub-TLVs, the first advertisement received in the lowest-numbered LSP SHOULD be used and subsequent conflicting advertisements SHOULD be ignored.
When the L-flag is set in the Application-Specific SRLG TLV, SRLG values MUST NOT be included; any SRLG values advertised MUST be ignored, and the corresponding legacy TLV's SRLG values MUST be used by the specified applications.
The Application Identifier Bit Mask encodes two variable-length bit masks: the Standard Application Identifier Bit Mask (SABM, 0-8 octets) identifying standardized applications (RSVP-TE R-bit, SR Policy S-bit, LFA F-bit) and the User-Defined Application Identifier Bit Mask (UDABM, 0-8 octets) for non-standard applications. Both masks are prefixed by a 1-octet length+flag field.
The Application-Specific Link Attributes (ASLA) sub-TLV (Type 16) is defined for TLVs 22, 23, 25, 141, 222, and 223. Its value contains an Application Identifier Bit Mask followed by link attribute sub-sub-TLVs whose format matches the corresponding legacy sub-TLV formats.
The Application-Specific SRLG TLV (Type 238) is a new TLV that advertises application-specific SRLGs for a link. Unlike TLVs 138 and 139, it supports IPv4, IPv6, and unnumbered link identifiers in a single TLV using sub-TLVs, and includes the Application Identifier Bit Mask.
IANA created a new 'Link Attribute Application Identifiers' registry under 'IGP Parameters' with Expert Review policy. Initial bits: 0=RSVP-TE (R-bit), 1=Segment Routing Policy (S-bit), 2=Loop-Free Alternate (F-bit), 3-63 unassigned. Bits SHOULD be assigned to fill lowest available octet first.
IANA created a new 'Sub-sub-TLV Codepoints for Application-Specific Link Attributes' registry under 'IS-IS TLV Codepoints' with Expert Review policy. Initial entries mirror legacy sub-TLV types 3, 9-11, 14, 18, 33-39 from RFC 5305, RFC 7308, and RFC 8570.
IANA created a new 'Sub-TLVs for TLV 238' registry under 'IS-IS TLV Codepoints' with Expert Review policy. Initial entries include types 4 (Link Local/Remote Identifiers), 6 (IPv4 interface address), 8 (IPv4 neighbor address), 12 (IPv6 Interface Address), 13 (IPv6 Neighbor Address).
IANA registered Application-Specific SRLG TLV Type 238 in the IS-IS 'TLV Codepoints Registry', applicable to LSPs only (not IIH, SNP, or Purge).
IANA registered ASLA sub-TLV Type 16 in the 'Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223' registry, applicable to TLVs 22, 23, 25, 141, 222, and 223.
Tampering with the application-specific link attribute advertisements defined in this document may impact traffic engineering applications. Because the advertisements are scoped to specific applications, the impact of tampering is similarly limited in scope. Stronger IS-IS authentication mechanisms from RFC 5304 and RFC 5310 SHOULD be used in deployments where potential attackers have access to the IS-IS routing domain.
The Application Identifier Bit Mask header consists of two octets: SABM Length+Flag (bit 7 is the L-flag/Legacy Flag, bits 0-6 encode SABM length in octets 0-8) and UDABM Length+Flag (bit 7 is reserved, bits 0-6 encode UDABM length in octets 0-8), followed by variable-length SABM and UDABM fields.
The Application-Specific SRLG TLV (Type 238) value contains: Neighbor System-ID + pseudonode ID (7 octets), Application Identifier Bit Mask (variable), Length of sub-TLVs (1 octet), Link Identifier sub-TLVs (variable), and 0 or more 4-octet SRLG values.