Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
updated by
- rfc-6001 — Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
- rfc-8390 — RSVP-TE Path Diversity Using Exclude Route
updates
Extracted elements (27)
An alternative design of reusing ERO subobject type bits (e.g., the top bit) to distinguish inclusion vs. exclusion was rejected because RFC 3209 allocates only 32 IETF-consensus subobject types in that scheme, which was considered an unacceptably small number for future protocol expansion. Separate new objects and subobject types were chosen instead.
The Attribute octet in IPv4/IPv6/Unnumbered Interface subobjects was introduced to allow a single interface address to express exclusion of the interface only (0), the whole node (1), or all SRLGs associated with that interface (2). This avoids needing separate subobjects for each exclusion granularity.
The XRO Class-Num is encoded as 11bbbbbb (value 232) so that nodes not supporting XRO will forward the Path message uninspected rather than failing. This allows route exclusion constraints to traverse network segments that cannot parse the new object while still being applied by capable nodes downstream.
The XRO is designed to carry only the minimal set of exclusions needed to constrain loose-hop expansion, not to enumerate all undesired paths. Subobjects can be removed from the XRO by intermediate nodes as they become irrelevant, keeping signaling overhead bounded by the length of the primary LSP's RRO.
A node MAY reject a Path message if its XRO is too large or complex per local policy. In that case, the node MUST send a PathErr with error code 'Routing Error' and error value 'XRO Too Complex' (68). An ingress LSR receiving this MAY reduce XRO complexity or route around the rejecting node.
A node MUST NOT introduce any explicit or abstract node in the XRO that it also introduced in the ERO, regardless of the L flag value.
A node that supports the XRO but not a particular subobject or subobject attribute MUST ignore that specific subobject rather than failing. Examples: only prefix-32 of IPv4 prefix may be supported, or the Attribute field may not be recognized.
An EXRS MUST NOT be present in an XRO. The L bit in the outer EXRS ERO subobject MUST be set to zero on transmission and MUST be ignored on receipt; the L bits in the inner EXRS subobjects carry the exclude/avoid semantics as defined for XRO subobjects.
If the XRO contains subobjects with inconsistencies (e.g., an IPv4 prefix subobject with an interface address but an attribute of 'interface' or 'SRLG' when 'node' is implied), the node SHOULD return a PathErr with error code 'Routing Problem' and error value 'Inconsistent Subobject' (65).
Minimum compliance requires: XRO MUST be supported with IPv4/32 and IPv6/128 prefix subobjects using interface and node attributes. EXRS support is optional (MAY); if not supported, an encountered EXRS MUST be rejected as an unknown ERO subobject with PathErr 'Bad EXPLICIT_ROUTE object'.
When a Path message with an XRO is received, a node MUST check whether it is a member of any abstract node listed in the XRO with L=0 (mandatory exclusion). If so, it SHOULD return a PathErr with error code 'Routing Problem' and error value 'Local Node in Exclude Route' (66).
When both XRO and EXRS are present during ERO expansion, an LSR MUST exclude all SRLGs, nodes, links, and resources listed in both. Where an element appears in both lists with different strictness, the stricter constraint (MUST exclude) wins over the softer one (SHOULD avoid).
When choosing a next hop or expanding a loose hop, a node MUST NOT introduce any explicit or abstract node that equals or is a member of any XRO subobject with L=0 (mandatory exclusion), and MUST NOT introduce links or resources identified by a mandatory SRLG subobject. The number of avoided (L=1) nodes and SRLGs SHOULD be minimized.
When XRO and ERO subobjects contradict each other, mandatory exclusions in the XRO (L=0) MUST take precedence: the implementation MUST reject the Path message and return a PathErr 'Route blocked by Exclude Route' (67). Advisory XRO exclusions (L=1) do not override ERO; an implementation MAY continue or reject.
The EXCLUDE_ROUTE object (XRO) is a new RSVP-TE object (Class 232, C_Type 1) that carries a list of abstract nodes and resources that must not or should not be traversed by the LSP path. It contains a series of variable-length subobjects encoding IPv4 prefixes, IPv6 prefixes, unnumbered interface IDs, autonomous system numbers, and SRLGs.
The Explicit Exclusion Route Subobject (EXRS) is a new ERO subobject (Type 33) that encodes exclusions scoped to the path segment between two adjacent abstract nodes in the ERO. An EXRS contains one or more nested EXRS subobjects with the same format as XRO subobjects, and MUST NOT appear inside an XRO.
IANA assigned new RSVP-TE Class Number 232 (class type 11bbbbbb) for the EXCLUDE_ROUTE object (XRO), C_Type 1. Subobject types 1, 2, 4, and 32 are reused from the Explicit Route Object; new subobject types 33 (EXRS) and 34 (SRLG) are assigned by this document.
IANA registered new ERO subobject type 33 (Explicit Exclusion Route subobject, EXRS) under the RSVP PARAMETERS registry, EXPLICIT_ROUTE class (20). The EXRS may appear in the ERO but not in the RRO or XRO.
IANA registered six new error value sub-codes under Error Code 24 ('Routing Problem'): 64 (Unsupported Exclude Route Subobject Type), 65 (Inconsistent Subobject), 66 (Local Node in Exclude Route), 67 (Route Blocked by Exclude Route), 68 (XRO Too Complex), 69 (EXRS Too Complex).
Administrative boundaries that strip EROs from Path messages for security reasons SHOULD also strip the XRO, since the XRO reveals topology and routing constraints that may be equally sensitive. The same security considerations from RFC 3209 and RFC 3473 continue to apply.
An arbitrarily complex XRO or EXRS sequence could be used as a denial-of-service attack, forcing additional processing at every node on the LSP path. The attacker would need to control an otherwise-authenticated LSR. Nodes may defend by rejecting over-complex objects with 'XRO Too Complex' or 'EXRS Too Complex' PathErr responses per local policy.
The EXRS outer subobject format is: 1-bit L (MUST be zero, ignored on receipt), 7-bit Type (33), 1-byte Length, 2-byte Reserved, followed by one or more inner EXRS subobjects each formatted identically to XRO subobjects.
The IPv4 Prefix subobject for XRO is 8 bytes: 1-bit L flag, 7-bit Type (1), 1-byte Length, 4-byte IPv4 address, 1-byte Prefix Length, and 1-byte Attribute. The Attribute octet distinguishes interface exclusion (0), node exclusion (1), and SRLG exclusion (2), allowing a single interface address to exclude the whole node or all its SRLGs.
The IPv6 Prefix subobject for XRO is 20 bytes: 1-bit L flag, 7-bit Type (2), 1-byte Length, 16-byte IPv6 address, 1-byte Prefix Length, and 1-byte Attribute (0=interface, 1=node, 2=SRLG), mirroring the IPv4 subobject semantics.
The SRLG subobject (Type 34) is 8 bytes: 1-bit L flag, 7-bit Type (34), 1-byte Length (always 8), 4-byte SRLG Id, and 2 bytes Reserved. For use in XRO/EXRS the L bit SHOULD be set to zero and ignored; it identifies a 32-bit SRLG whose resources must be excluded.
The Unnumbered Interface ID subobject for XRO is 12 bytes: 1-bit L flag, 7-bit Type (4), 1-byte Length, 1-byte Reserved, 1-byte Attribute, 4-byte TE Router ID, and 4-byte Interface ID. Attribute values are 0 (interface), 1 (node), and 2 (SRLG).
The XRO wire format is Class 232, C_Type 1, and consists of a variable-length sequence of subobjects. Supported subobject types are: 1 (IPv4 prefix), 2 (IPv6 prefix), 4 (Unnumbered Interface ID), 32 (Autonomous System Number), 34 (SRLG). The L bit in each subobject is repurposed from loose/strict to indicate mandatory exclusion (L=0, MUST exclude) or soft avoidance (L=1, SHOULD avoid).