Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions
Extracted elements (25)
Only 2-octet Autonomous System Numbers are supported in the AS Number subobject, consistent with PCEP and RSVP-TE. The document acknowledges that both protocols will need coordinated updates when 4-octet AS Numbers become more common.
The SRLG subobject's Attribute field SHOULD be set to 2 (SRLG interpretation) and SHOULD be ignored on receipt, because an SRLG subobject is unambiguously an SRLG — the Attribute field is structurally present for consistency with other subobjects but carries no useful information for the SRLG type.
The XRO is permitted on PCRep messages for two purposes: on a PCRep with NO-PATH it identifies which XRO elements prevented a path from being found; on a successful PCRep it provides exclusions to be signaled during LSP setup via RSVP-TE XRO, which is particularly useful in per-domain path computation scenarios.
A PCE that does not support EXRS will treat an IRO containing an EXRS as a malformed object per RFC 5440 rules. The PCE MAY include the IRO in the PCErr, in which case the IRO SHOULD be terminated immediately after the unrecognized EXRS.
An EXRS MUST NOT be sent with no subobjects, and if received with no subobjects, MUST be ignored.
An XRO with no subobjects MUST NOT be sent and SHOULD be ignored on receipt.
If a PCE supporting EXRS encounters an unrecognized EXRS subobject with X-bit clear, it MUST respond with a PCErr with Error-Type 'Unrecognized EXRS subobject' and set the Error-Value to the EXRS subobject type code. If X-bit is set, the PCE MAY respond with PCErr or MAY ignore the subobject per local policy.
If the PCE does not recognize the XRO, it MUST return a PCErr with Error-Type 'Unknown Object'. If the PCE is unwilling or unable to process the XRO, it MUST return a PCErr with Error-Type 'Not supported object'.
If the PCE finds more than one XRO in a PCReq message, it MUST use the first one and MUST ignore subsequent instances.
When a PCE expands a PKS in an XRO to perform local path computation (either by recognizing itself as the PCE-ID or by querying the identified PCE), the resulting XRO subobjects MUST NOT be shared with other PCEs.
When a PCE processes an XRO and computes a path, the returned path MUST NOT include any resources encoded with X-bit clear, and SHOULD NOT include any with X-bit set unless no alternate path satisfying other constraints is available.
Path-Key Subobjects (PKSs) from RFC 5520 may appear as XRO subobjects to support inter-domain diverse path computation where segments of the primary path are kept confidential. The L bit of the PKS subobject in the XRO MUST be ignored.
The Attribute field in XRO subobjects controls interpretation: 0 means interpret as interface(s), 1 means interpret as node(s), and 2 means interpret as SRLG (exclude all resources sharing any SRLG with the identified resource).
The Exclude Route Object (XRO) is a new PCEP object with Object-Class 17 and Object-Type 1. It conveys the Exclude Route List — the set of abstract nodes, resources, and SRLGs that a PCE is requested to exclude from a computed path.
The Explicit Exclusion Route Subobject (EXRS) is a new subobject for the IRO with type 33. It contains one or more XRO-compatible subobjects and limits exclusion scope to the single hop between the previous and subsequent elements in the IRO.
The F (Fail) flag in the XRO Flags field, when set, indicates that the PCC requires computation of a new path for a failed TE LSP. When F is set, the path of the existing LSP MUST be provided in the PCReq via an RRO to avoid double bandwidth booking.
The X-bit in each XRO subobject controls exclusion strictness: X=0 means the PCE MUST exclude the identified resource; X=1 means the PCE SHOULD exclude it but MAY include it if no viable path exists without it.
IANA added subobject type 33 ('Explicit Exclusion Route subobject (EXRS)') to the Include Route Object (IRO) entry in the PCEP Objects subregistry.
IANA allocated Error-Type 11 ('Unrecognized EXRS subobject') in the Error Types and Values subregistry of the PCEP Parameters registry. The Error-Value is set to the unrecognized EXRS subobject type code.
IANA allocated Object-Class 17 ('XRO', Object-Type 1: Route exclusion) in the PCEP Objects subregistry of the PCEP Parameters registry. The XRO object may carry subobjects of types 1, 2, 4, 32, 34, 64, and 65.
IANA created the 'XRO Flag Field' subregistry under PCEP Parameters, containing a 16-bit flags field. Bit 15 (F-bit, Fail) was the initial allocation. New bits may be allocated only by IETF Consensus.
The route exclusion extensions allow finer control over PCE-computed paths, increasing risk if PCEP messages are intercepted, modified, or spoofed — an attacker could manipulate exclusion constraints to force undesirable paths or make path computation fail. The security mechanisms defined in RFC 5440 are therefore considered more critical in deployments using these extensions. Conversely, route exclusions can also be used to route around vulnerable network segments, improving overall security.
The EXRS format contains an L bit (MUST be zero, MUST be ignored on receipt), a Type field, a Length field, a 16-bit Reserved field (MUST be zero, SHOULD be ignored), followed by one or more XRO-format subobjects.
The XRO body consists of a 16-bit Reserved field (MUST be zero on transmission), a 16-bit Flags field (currently defines the F-bit at position 15), followed by one or more variable-length subobjects.
XRO supports five subobject types: IPv4 prefix (type 1, 8 bytes), IPv6 prefix (type 2, 20 bytes), Unnumbered Interface ID (type 4, 12 bytes with TE Router ID and Interface ID), Autonomous System Number (type 32, 4 bytes with 2-octet AS number), and SRLG (type 34, 8 bytes with 4-byte SRLG ID).