RSVP-TE Path Diversity Using Exclude Route
updates
- rfc-4874 — Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extracted elements (28)
For PCE-Allocated and Network-Assigned identifier types, transit nodes in a domain and the domain egress node SHOULD NOT process the signaled diversity information unless performing path computation. Only the domain ingress node (which consults a PCE or performs local computation) needs to process the constraint, keeping per-hop processing minimal.
The L-flag semantics from RFC 4874 are reused: L=0 means diversity constraints MUST be satisfied (hard constraint), L=1 means constraints SHOULD be satisfied (soft constraint). This allows operators to express best-effort diversity for single-homed endpoints where strict diversity is impossible.
The Path Affinity Set (PAS) was introduced to minimize the exchange of diversity information between core network nodes (CNs) and client devices (ENs). The PAS is a single abstract SRLG identifier associated with a given path, avoiding the need to share detailed SRLG lists across UNI boundaries where core network topology is confidential.
If the processing node cannot recognize the Diversity XRO/EXRS subobject, it is expected to follow the procedure defined in RFC 4874 for unknown subobjects. The general RFC 4874 processing rules for XRO and EXRS are not changed by this document.
All Diversity subobjects in an XRO/EXRS MUST contain the same Diversity Identifier Type. If a Path message contains an XRO/EXRS with multiple Diversity subobjects of different DI Types, the processing node MUST return a PathErr with error code 'Routing Problem' (24) and error sub-code 'XRO/EXRS Too Complex' (68/69).
An EXRS MAY include a Diversity subobject as specified in this document. The same type values 38 and 39 MUST be used for EXRS subobjects as for XRO subobjects.
If a previously unknown or changed excluded path becomes known to the processing node after initial LSP setup, the node MUST re-evaluate exclusion and diversity constraints. If constraints with L-flag unset are no longer met, it MUST send a PathErr with error code 'Routing Problem' (24) and sub-code 'Route blocked by Exclude Route' (67), with PSR flag MUST NOT be set.
If the L-flag was set and constraints become newly satisfied after previously being violated, the processing node MUST send a PathErr with error code 'Notify Error' (25) and sub-code 'Compliant path exists' (16), with PSR flag MUST NOT be set. The source node MAY then move the LSP to a compliant path.
If the processing node fails to find a path that meets the requested diversity constraint (L-flag not set), it MUST return a PathErr with error code 'Routing Problem' (24) and error sub-code 'Route blocked by Exclude Route' (67).
If the processing node recognizes the Diversity XRO/EXRS subobject but does not support the DI Type, it MUST return a PathErr with error code 'Routing Problem' (24) and error sub-code 'Unsupported Diversity Identifier Type' (36).
The client-initiated identifier MUST use the following fields to represent it: IPv4/IPv6 tunnel sender address, IPv4/IPv6 tunnel endpoint address, Tunnel ID, and Extended Tunnel ID. Based on local policy, the client MAY also include the LSP ID to identify a specific LSP within the tunnel.
The Reserved field and reserved E-Flag (0x08) MUST be set to zero on transmission and MUST be ignored on receipt for both IPv4/IPv6 Diversity XRO subobjects.
When the L-flag is not set and the excluded path referenced in the XRO subobject is unknown to the processing node, the node SHOULD ignore the Diversity XRO subobject and proceed with signaling. After sending the Resv, the node MUST return a PathErr with error code 'Notify Error' (25) and sub-code 'Route of XRO LSP identifier unknown' (14).
When the L-flag is set and the processing node fails to find a diverse path, it SHOULD proceed with a best-effort path and MUST return a PathErr with error code 'Notify Error' (25) and sub-code 'Failed to satisfy Exclude Route' (15). The Path_State_Removed (PSR) flag MUST NOT be set.
The Attribute Flags (A-Flags) field defines four flags for the Diversity XRO/EXRS subobject: 0x01 Destination node exception, 0x02 Processing node exception, 0x04 Penultimate node exception, and 0x08 LSP ID to be ignored (tunnel-level exclusion). Any combination is permitted.
The Exclusion Flags (E-Flags) field defines three flags: 0x01 SRLG exclusion (SRLG disjoint path required), 0x02 Node exclusion (node diverse path required), and 0x04 Link exclusion (link diverse path required). Flag 0x08 is reserved and MUST be set to zero on transmission and MUST be ignored on receipt.
Three types of abstract diversity identifiers are defined: Client-Initiated Identifier (based on tunnel sender/endpoint address, Tunnel ID, Extended Tunnel ID, and optionally LSP ID), PCE-Allocated Identifier (using Path Key from RFC 5520), and Network-Assigned Identifier (using a Path Affinity Set identifier).
Two new Diversity XRO subobjects are defined: IPv4 Diversity (XRO Type 38) and IPv6 Diversity (XRO Type 39). Both contain an L flag, XRO Type, Length, DI Type (4 bits), A-Flags (4 bits), E-Flags (4 bits), Reserved (4 bits), a Diversity Identifier Source Address, and a variable-length Diversity Identifier Value.
New RSVP error sub-codes are assigned: under Routing Problem (24), sub-code 36 'Unsupported Diversity Identifier Type'; under Notify Error (25), sub-codes 14 'Route of XRO LSP identifier unknown', 15 'Failed to satisfy Exclude Route', and 16 'Compliant path exists'.
Two new EXRS subobject types are assigned under the RSVP EXPLICIT_ROUTE object (C-Type 20): IPv4 Diversity (value 38) and IPv6 Diversity (value 39), sharing the same numeric values as the XRO subobject types.
Two new XRO subobject types are assigned under the RSVP EXCLUDE_ROUTE object (C-Type 1): IPv4 Diversity (value 38) and IPv6 Diversity (value 39).
Diversity subobjects MUST be retained in an XRO crossing an administrative boundary, even if other subobjects are removed. Removing an XRO containing diversity subobjects at an administrative boundary would silently drop the diversity request, causing path computation to likely produce a non-diverse path. This retention is based on operator policy and mutual agreement.
This document does not introduce additional security issues beyond those identified in RFC 5920, RFC 2205, RFC 3209, RFC 3473, RFC 2747, RFC 4874, RFC 5520, and RFC 5553. The use of diversity subobjects avoids the need to share the identity of network resources when supporting diversity.
The IPv4 Diversity XRO subobject encodes a 1-bit L flag, 7-bit XRO Type (value 38), 8-bit Length, 4-bit DI Type, 4-bit A-Flags, 4-bit E-Flags, 4-bit Reserved, a 32-bit IPv4 Diversity Identifier Source Address, and a variable-length Diversity Identifier Value. Total length is variable depending on the Diversity Identifier Value.
The IPv6 Diversity XRO subobject has the same header as IPv4 but uses a 128-bit IPv6 Diversity Identifier Source Address, followed by the variable-length Diversity Identifier Value. XRO Type is set to 39.
When DI Type is 'Client-Initiated Identifier' in an IPv4 Diversity XRO subobject, the Diversity Identifier Value MUST encode: 32-bit IPv4 Tunnel Endpoint Address, 16-bit Must Be Zero, 16-bit Tunnel ID, 32-bit Extended Tunnel ID, 16-bit Must Be Zero, and 16-bit LSP ID, as defined in RFC 3209.
When DI Type is 'Network-Assigned Identifier', the Diversity Identifier Value MUST encode a 32-bit Path Affinity Set (PAS) Identifier, scoped by the Diversity Identifier Source Address field, for both IPv4 and IPv6 Diversity XRO subobjects.
When DI Type is 'PCE-Allocated Identifier', the Diversity Identifier Value MUST encode a 16-bit Must Be Zero field followed by a 16-bit Path Key (as defined in RFC 5553), for both IPv4 and IPv6 Diversity XRO subobjects.