PathErr Message Triggered MPLS and GMPLS LSP Reroutes
Extracted elements (25)
PathErr messages are used to signal reroute requests because they propagate upstream without changing path state in transit nodes (per RFC 2205), enabling non-disruptive rerouting where data traffic continues on the existing LSP until a new path is established.
The ERROR_SPEC address and TLVs—not the error code or value—identify the resource to be avoided. This design reuses the existing ERROR_SPEC structure from RFC 4920 to carry reroute targeting information without requiring new object types.
The 'Reroute' error code is introduced specifically to allow future definition of reroute-application-specific error values (e.g., for soft-preemption, graceful shutdown), while the existing 'Notify' error codes are retained for backwards compatibility with nodes that do not support the new code.
A conformant implementation MUST check for all three error code/value combinations that signal a reroute request (both 'Notify' variants and the new 'Reroute' code), ensuring interoperability with nodes that use the older backwards-compatible codes.
This document's mechanisms apply only to point-to-point LSPs; support for point-to-multipoint LSPs is explicitly left for further study.
When the Path_State_Removed flag (defined in RFC 3473) is not supported by the node, a ResvTear message MUST also be sent upon LSP removal at timeout expiry, maintaining interoperability with RFC 3473-unaware nodes.
A transit node whose policy permits reroute processing MUST examine incoming PathErr messages and MUST check for any of the three error code/value combinations from Section 2.1. When local repair is possible, standard local repair processing MUST be followed.
After initiating a reroute request when LSP removal on timeout is desired, the initiating node MUST start a timeout period. Upon receipt of a PathTear or a trigger Path message with an ERO avoiding the indicated resource, the timeout MUST be canceled.
An ingress node supporting reroute processing MUST check received PathErr messages for reroute requests, MUST check for all three error code combinations, and MUST attempt to identify an alternate path avoiding the resource identified in ERROR_SPEC. If no alternate is found, the request MUST be discarded; if found, make-before-break procedures MUST be followed.
Before initiating a reroute request, the requesting node MUST check that the Explicit Route Object (ERO) in the LSP's incoming Path message does not preclude LSP rerouting. The actual repair action SHOULD be performed only after verification that local policy allows local repair.
If the reroute request timeout expires, the initiating node MUST remove the LSP and its state/resources, signal removal downstream via PathTear, and signal upstream via a PathErr with error code 'Service preempted'. The Path_State_Removed flag MUST be set if supported; if not supported, a ResvTear MUST also be sent.
The IF_ID ERROR_SPEC object format MUST be used when a reroute request is more specific than an interface (e.g., reroute around a specific label or component).
When a boundary transit node triggers rerouting per RFC 4920, it MUST first identify an alternate path within the domain. When such a path is available, the node MUST terminate the PathErr and issue a Path message reflecting the alternate path. When no alternate is available, the node MUST propagate the PathErr to the previous hop.
When a transit or egress node cannot act locally on a reroute, it MUST issue a PathErr message containing an ERROR_SPEC object with one of three error code/value combinations: 'Notify/Local node maintenance required', 'Notify/Local link maintenance required', or 'Reroute/<any Reroute error value>'.
When an alternate path is identified at the ingress, a make-before-break LSP SHOULD be initiated and standard make-before-break procedures MUST be followed.
When the reroute decision redirects traffic around the local node, the local node MUST be indicated in the ERROR_SPEC object. When only an interface is impacted, the interface MUST be indicated and IF_ID ERROR_SPEC format SHOULD be used.
A reroute request is conveyed via a RSVP PathErr message carrying an ERROR_SPEC object. The address and TLVs in the ERROR_SPEC identify the resource to be avoided; the error code and value indicate the type of reroute request. This mechanism enables non-disruptive LSP rerouting without removing state.
Three valid error code/value combinations signal a reroute request: (1) 'Notify/Local node maintenance required' for node reroute with backwards compatibility, (2) 'Notify/Local link maintenance required' for interface reroute with backwards compatibility, and (3) 'Reroute/<any Reroute error value>' for future use.
IANA assigned error code 34 ('Reroute') in the 'Error Codes and Globally-Defined Error Value Sub-Codes' section of the 'RSVP Parameters' registry. Error value 0 is defined as 'Generic LSP reroute request'. Values 0-32767 require IETF Consensus; values 32768-65535 are Private Use.
The new 'Reroute' error code (34) is functionally equivalent to existing 'Notify/Local node maintenance required' and 'Notify/Local link maintenance required' semantics, so no new security considerations are introduced. Implementors should consult Sections 9 of RFC 4920 and RFC 4736 for the applicable security analysis.
Reroute request timeout state machine: initiating node enters 'awaiting response' state after sending PathErr; transitions to 'complete' on receiving PathTear or a trigger Path message with conforming ERO; transitions to 'LSP removal' on timeout expiry, triggering PathTear downstream and PathErr ('Service preempted') upstream.
Component (unnumbered) reroute request uses an IF_ID ERROR_SPEC (C-Type=3) with a TLV of Type=3, Length=12 carrying a Router ID (4 bytes) and Interface ID (4 bytes) identifying the specific component link to be avoided.
Interface reroute request uses an IF_ID ERROR_SPEC object (Class-Num=6, C-Type=3) with the node's TE router address, error code/value, and a TLV of Type=1, Length=8 carrying an IPv4 interface address identifying the interface to be avoided.
Label reroute request uses an IF_ID ERROR_SPEC (C-Type=3) with two TLVs: Type=1/Length=8 carrying the interface IP address and Type=6/Length=8 carrying the DOWNSTREAM_LABEL value identifying the specific label to be avoided.
Node reroute request uses an IPv4 ERROR_SPEC object (Class=6, C-Type=1) with the IPv4 Error Node Address field set to the local node's TE router address, followed by Flags (1 byte), Error Code (1 byte), and Error Value (2 bytes).