RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
updated by
- rfc-4873 — GMPLS Segment Recovery
- rfc-6780 — RSVP ASSOCIATION Object Extensions
- rfc-9270 — GMPLS Signaling Extensions for Shared Mesh Protection
updates
- rfc-3471 — Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
Extracted elements (29)
Both the S (Secondary) bit and P (Protecting) bit are required because the S bit alone is insufficient to determine whether resource allocation should be performed for an LSP within the protected entity. A single bit cannot distinguish a secondary protecting LSP from other LSP roles; the P bit resolves this unambiguously.
Full LSP rerouting uses the make-before-break mechanism (SE reservation style, same Tunnel IDs, different LSP ID) not to avoid traffic disruption (already broken by failure) but to retain and reuse resources allocated on the original LSP segments that the new alternate LSP will traverse, avoiding double-counting.
LSP Protection Type values are given end-to-end significance but processed hop-by-hop. This design allows easier implementation of reversion signaling and enables transparent delivery of protected services, since intermediate nodes need not interpret the Protection Type semantics — only the S and P bits matter locally.
The PRIMARY_PATH_ROUTE object is assigned Class-Num of the form 0bbbbbbb (Class-Num=38) so that nodes that do not support it MUST return a PathErr with 'Unknown Object Class'. This ensures that shared-mesh resource sharing is only attempted when all nodes along the secondary path explicitly support the object, preventing silent misallocation.
End-to-end GMPLS recovery has no impact on RSVP-TE Fast Reroute (RFC 4090). Objects introduced by end-to-end recovery are ignored by RFC 4090-conformant implementations, and FRR can operate on a per-LSP basis as defined in RFC 4090. Both mechanisms may be used simultaneously on the same LSP.
The PRIMARY_PATH_ROUTE object MAY only be used when all GMPLS nodes along the path support it. Its Class-Num (0bbbbbbb form) ensures non-supporting nodes return a PathErr 'Unknown Object Class' rather than silently passing it, making its deployment scope explicitly negotiated.
A pair of working/protecting LSPs SHOULD be resource-disjoint (link, node, and SRLG) for dedicated recovery types. For shared recovery, a group of working LSPs SHOULD be mutually resource-disjoint to allow a single shared protecting LSP. Resource disjointness is a necessary but not sufficient condition for recoverability.
During LSP preemption, the preempting node SHOULD NOT forward the Path message downstream before resource de-allocation has completed. Forwarding before de-allocation may cause misconnection if the downstream node reassigns the resources more quickly than the upstream node releases them.
For 1+1 bidirectional and 1:N protection switchover, the end-node initiating the switchover MUST send a reliable Notify message to the peer with error code/sub-code 'Notify Error/LSP Failure'. This message MUST include the MESSAGE_ID object with the ACK_Desired flag set, requiring the receiver to acknowledge per RFC 2961.
For 1:N (N>1) protection, the protecting LSP's Association ID MUST by default be set to the LSP ID of the protected LSP corresponding to N=1. Each working LSP sets its Association ID to the protecting LSP ID.
For all protection types, working and protecting LSPs belonging to the same protected entity MUST use the same SESSION object (same Tunnel Endpoint Address, Tunnel ID, and Extended Tunnel ID), but MUST use different LSP ID values to distinguish the individual LSPs within the session.
For secondary protecting LSPs (Rerouting without Extra-Traffic), the primary working LSP_ID MUST be known before signaling of the secondary LSP, since the ASSOCIATION object's Association ID must reference it. Resources for the secondary LSP SHOULD be pre-reserved but MUST NOT be committed at the data plane level until explicit activation.
Intermediate and egress nodes processing a Path message with a PROTECTION object MUST verify that the requested LSP Protection Type can be satisfied by the incoming interface. If it cannot, the node MUST generate a PathErr message with error code/sub-code 'Routing problem/Unsupported LSP Protection'.
The PRIMARY_PATH_ROUTE object MUST NOT be used in Path messages when the S bit is 0 in the PROTECTION object. If a PPRO is received when S=0, the receiving node MUST return a PathErr with error code/sub-code 'Routing Problem/PRIMARY_PATH_ROUTE object not applicable'. PPROs are only valid for secondary protecting LSPs (S=1, P=1) with Protection Type 0x02.
The S and P bits in the PROTECTION object MUST be processed on a hop-by-hop basis, independently of the LSP Protection Type context. This allows intermediate nodes to determine resource allocation status without needing to interpret the end-to-end Protection Type semantics.
The S bit (Secondary) set to 1 with the P bit (Protecting) set to 0 is not a valid combination in the PROTECTION object. Working LSPs are always primary (S=0, P=0); only protecting LSPs may be secondary (S=1, P=1).
When a secondary protecting LSP is being activated and its pre-reserved resources are in use by lower-priority LSPs, those LSPs MUST be preempted. The preempting node MUST send PathTear and PathErr messages with error code/sub-code 'Policy Control failure/Hard preempted' with the Path_State_Removed flag set for each preempted LSP.
Four status bits in the PROTECTION object characterize LSP role: S (Secondary) distinguishes primary from secondary LSPs; P (Protecting) distinguishes working from protecting LSPs; N (Notification) indicates control-plane-only coordination during switching; O (Operational) indicates the protecting LSP is currently carrying normal traffic after switchover. The combination S=1, P=0 is explicitly invalid.
The ASSOCIATION object links working and protecting LSPs. When carried on the working LSP, the Association ID identifies the protecting LSP_ID; when carried on the protecting LSP, it identifies the protected LSP_ID. For full rerouting LSPs, the Association ID MUST be set to the LSP ID of the signaled LSP itself.
The LSP Protection Type Flags field in the PROTECTION object is 6 bits wide and encodes the desired end-to-end recovery type: 0x00=Unprotected, 0x01=Full Rerouting, 0x02=Rerouting without Extra-Traffic, 0x04=1:N Protection with Extra-Traffic, 0x08=1+1 Unidirectional Protection, 0x10=1+1 Bidirectional Protection. Only one value SHOULD be set at a time.
The PRIMARY_PATH_ROUTE object (PPRO) informs intermediate nodes along a secondary protecting LSP's path about the link and node resources used by the associated primary protected LSP. It is derived from the EXPLICIT ROUTE and/or RECORD ROUTE objects of the primary working LSP and enables recovery resource sharing in shared-mesh scenarios.
This document defines PROTECTION object C-Type 2 (Class-Num=37) for end-to-end LSP recovery, PRIMARY_PATH_ROUTE object Class-Num 38 (C-Type 1), new RSVP error subcodes ('Routing problem/Unsupported LSP Protection', 'Routing Problem/Bad PRIMARY_PATH_ROUTE object', 'Routing Problem/PRIMARY_PATH_ROUTE object not applicable'), and Notify error subcodes ('LSP Locally Failed', 'LSP Failure', 'LSP Recovered').
End-to-end GMPLS recovery signaling extends RSVP-TE and inherits its security considerations (RFC 3473). The recovery mechanisms introduce additional attack surfaces: unauthorized protection switching via forged Notify messages, misuse of the lockout (L) bit to block recovery, and resource exhaustion by establishing numerous secondary LSPs without activation. Operators SHOULD apply RSVP-TE authentication (RFC 2747) to protect recovery signaling.
End-to-end 1:1 protection switchover (3-step): (1) Detecting end-node disconnects extra-traffic and sends Notify 'LSP Failure' (Switchover Request) with ACK_Desired; (2) Peer receives request, disconnects extra-traffic, begins sending/receiving normal traffic on protecting LSP, sends Notify response with MESSAGE_ID_ACK; (3) Initiator begins receiving normal traffic on protecting LSP and sends final Ack.
Reversion sequence for dedicated and 1:N protection: (1) Source sends traffic on both working and protecting LSPs, then sends reliable Notify 'LSP Recovered' (Switchback Request) with ACK_Desired; (2) Destination selects working LSP, transmits on both, sends Notify response with ACK; (3) Source switches reception to working LSP, sends Ack; (4) Destination stops transmitting on protecting LSP. Finally, protecting LSP's O bit or S bit is cleared.
Secondary LSP lifecycle: (1) Pre-provisioned state — S=1, P=1 in PROTECTION object; resources pre-reserved at control plane, no data plane cross-connection. (2) Activated/primary state — triggered by a modified Path message with S=0; link and node resources are allocated at the data plane and the LSP becomes capable of carrying normal traffic.
The ADMIN_STATUS object (Class-Num=196, C-Type=1) is extended with a 1-bit Lockout (L) field. When set, L forces the recovery LSP to be temporarily unavailable to transport traffic (either normal or extra-traffic). It MUST be set together with the Reflect (R) bit in the Path message.
The PRIMARY_PATH_ROUTE object (Class-Num=38, C-Type=1) carries a variable-length list of subobjects encoding resources used by the associated primary working LSP. Subobject length MUST always be a multiple of 4 and at least 4. Defined sub-types are IPv4 Address (1), IPv6 Address (2), Label (3), and Unnumbered Interface (4).
The PROTECTION object (Class-Num=37, C-Type=2) is a 96-bit object carrying four 1-bit flags (S, P, N, O), 5 reserved bits, a 6-bit LSP Protection Type Flags field, 10 reserved bits, a 6-bit Link Flags field, and a 32-bit reserved field whose encoding is detailed in RFC 4873.