Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
updates
- rfc-3209 — RSVP-TE: Extensions to RSVP for LSP Tunnels
Extracted elements (15)
Error conditions for TE LSPs fall into two categories: fatal errors (disruptive to the TE LSP, termed 'Hard Preemption') and non-fatal errors (non-disruptive). This distinction governs whether control-plane and data-plane state must be cleared at the detecting node.
In fatal error cases, the LSP has usually already failed in the data plane and traffic has already been disrupted before the PathErr is sent. When the error arises during LSP establishment, there is no traffic disruption since no traffic flows until the LSP is fully established.
This document clarifies and restates procedures from RFC 3209 and RFC 3473 without defining new protocol extensions. Implementations must reconcile the Path_State_Removed flag behavior from RFC 3473 with the general RFC 2205 rule that PathErr messages do not modify node state.
Any node clearing either or both the Path or Resv state of a TE LSP MUST also free up the data-plane resources allocated to the corresponding TE LSP.
In the case of a fatal error (Hard Preemption), the detecting node MUST send a PathErr message reporting the error condition and MUST clear the corresponding Path and Resv control-plane states, which also releases data-plane resources and results in traffic disruption.
In the case of non-fatal errors, the detecting node should send a PathErr message but must not clear control-plane or data-plane state, preserving the TE LSP.
Per RFC 2205 Section 3.7.1, a node receiving a PathErr message MUST take no action upon it and must not clear Path or Resv control-plane or data-plane state, regardless of whether the error is fatal or non-fatal.
RSVP states at receiving nodes should only be modified upon receiving a PathTear or ResvTear message, or in the event of a Path or Resv state timeout — not upon receiving a PathErr message.
When the Path_State_Removed flag is set on a received PathErr, the receiving node should remove its own Path state before forwarding the message, but may alternatively retain state and clear the flag before forwarding.
Error Code=12 ('Service preempted'), defined in RFC 2205, is used to report a preempted TE LSP and is classified as a fatal error.
Error Code=2 ('Policy Control Failure') with Error Value=5 ('Flow was preempted'), defined in RFC 2750, is used to report a preempted TE LSP and is classified as a fatal error.
PathErr (Path Error) messages are routed hop-by-hop upstream toward the head-end of the TE LSP using the path state established when the Path message was routed. They carry an ERROR_SPEC object that includes the IP address of the detecting node, an Error Code field, and an Error Value field.
RFC 3473 defines a Path_State_Removed flag in the ERROR_SPEC object carried on a PathErr message. When set, this flag indicates that the message sender has removed Path state (and any associated Resv and data-plane state) for the TE LSP.
The ERROR_SPEC object contains three key fields: the Error Node Address (IP address of the node that detected the error), the Error Code (category of the error), and the Error Value (qualifies the error code for more precision).
This document does not introduce new security concerns beyond those of existing MPLS-TE as specified in RFC 3209 and RFC 3473. By clarifying node behavior, it reduces the security risk introduced by non-conformant implementations that might incorrectly clear or retain state.