GMPLS Signaling Extensions for Shared Mesh Protection
updates
Extracted elements (26)
SMP differs from SMR in that SMP activates a protecting LSP via the Automatic Protection Switching (APS) protocol in the data plane when a working LSP fails, while SMR activates via control plane signaling. This distinction necessitates a new LSP Protection Type so nodes can behave appropriately during recovery.
SMP preconfigures protecting LSPs by pre-reserving resources without activating them (e.g., cross-connects are not preestablished), allowing link and node resources to be shared by protecting LSPs of multiple disjoint working LSPs. SMP is always revertive.
SMP preemption priority is distinct from the GMPLS Setup and Holding priorities in the SESSION_ATTRIBUTE object. Using separate priorities avoids the complexity of defining a unified policy that serves both GMPLS control plane LSP preemption and SMP shared resource competition resolution.
APS configuration between adjacent nodes along the protecting LSP path must be done by means other than GMPLS signaling, before any protecting LSP is set up. The APS protocol may use different identifiers than GMPLS signaling to identify the protecting LSP, and these identifiers are expected to be technology-specific or vendor-specific.
The rules in Section 14.2 of RFC 4872 ensure that all nodes along an SMP LSP are SMP-aware (via the Protection Type check during signaling), so there are no backward-compatibility issues with the new 0x20 Protection Type value.
A preempted LSP MUST NOT be terminated even after its resources have been deallocated. End nodes MUST keep refreshing both working and protecting LSPs regardless of failure or preemption status.
After protection switching completes, the protecting LSP MUST be signaled with S bit=0 and O bit=1 in the PROTECTION object, at which point link and node resources MUST be allocated for the LSP, which becomes a primary LSP ready to carry traffic.
If an intermediate node fails to allocate a protection resource during protection switching, it MUST send a Notify message to notify the requesting end node, which will then stop bridging/selecting traffic and proceed to remove the protection allocation per the APS protocol.
Primary working LSPs are signaled with the PROTECTION object S bit=0, P bit=0, N bit=1, and the ASSOCIATION object Association ID set to the associated secondary protecting LSP_ID. The N bit indicates protection switching signaling is done via the data plane.
Resources for the secondary LSP MUST be pre-reserved but not committed at the data plane level, meaning switch internals need not be established until explicit activation. Activation is performed by the APS protocol in the data plane.
Secondary protecting LSPs are signaled with the PROTECTION object S bit=1, P bit=1, N bit=1, and the ASSOCIATION object Association ID set to the primary working LSP_ID, which MUST be known before signaling the secondary LSP. The Path message MUST include at least one PRIMARY_PATH_ROUTE object.
To associate a secondary protecting LSP with its primary working LSP, both LSPs MUST use the same SESSION object. The LSP ID, however, MUST be different to distinguish between them.
Upon receipt of a 'Shared resources unavailable' Notify message, the end node MUST stop sending and selecting traffic to/from its protecting LSP and try switching traffic to another protecting LSP, if available.
When a lower-priority protecting LSP is preempted, the intermediate node MUST send a Notify message with error code 25 ('Notify Error') and error sub-code 17 ('Shared resources unavailable') to the end nodes of that protecting LSP.
When a protecting LSP occupies shared resources making them unavailable, the intermediate node MUST send a 'Shared resources unavailable' Notify message to all end nodes of protecting LSPs with lower SMP preemption priorities. If the shared resources fail, the same message MUST be sent to all end nodes of protecting LSPs configured to use those resources.
When an intermediate node on the protecting LSP receives a Path message, the SMP preemption priority value in the Preemption Priority field MUST be stored for that protecting LSP, to be used by the APS protocol when resolving resource competition.
When shared resources become available, a Notify message with error code 25 and error sub-code 18 ('Shared resources available') MUST be generated by the intermediate node and sent to the end nodes of lower-priority preempted protecting LSPs.
A new LSP Protection Type 'Shared Mesh Protection' (0x20) is added to the LSP Flags field of the PROTECTION object. This value is only applicable to bidirectional LSPs as required by G.808.3.
The Notification (N) bit in the PROTECTION object is updated: when set to 1, it indicates control plane message exchange is only used for notification during protection switching (not for actual switching). When the LSP Protection Type is 0x20 (SMP), the N bit MUST be set to 1; otherwise it MUST be set to 0 for types other than 0x04, 0x08, 0x10, or 0x20.
The Operational (O) bit in the PROTECTION object is updated: when set to 1, it indicates the protecting LSP is carrying traffic after protection switching. The O bit is only applicable when the P bit is set to 1 and the LSP Protection Type is 0x04, 0x08, 0x10, or 0x20.
IANA added two new error value sub-codes to the 'Sub-Codes - 25 Notify Error' subregistry of the 'Resource Reservation Protocol (RSVP) Parameters' registry: value 17 ('Shared resources unavailable') and value 18 ('Shared resources available'), both referencing RFC 9270.
Security threats from RFC 4872 apply to this document due to its use of RSVP Notify messages. It is important to use the security mechanisms defined in RFC 4872.
SMP preemption introduces an indirect attack vector: an attacker can disrupt traffic on one protecting LSP by targeting a link used by a higher-priority primary LSP elsewhere in the network, causing preemption of the protecting LSP. Detailed knowledge of network topology, routes, and LSP priorities can significantly improve attack efficacy.
During SMP protection switching: on failure detection (SF/SD), end node sends APS request to adjacent intermediate node; if resource available, intermediate sends confirmation upstream and forwards request downstream, triggering cross-connect setup; if resource unavailable (used by higher-priority LSP), intermediate sends 'Shared resources unavailable' Notify; if intermediate fails to allocate, it notifies end node which stops bridging and removes protection allocation.
The Preemption Priority (Preempt Prio) field is an 8-bit field allocated from the formerly reserved bits in the 32-bit PROTECTION object header (as modified by RFC 4873). It indicates the SMP preemption priority of a protecting LSP; a lower value indicates a higher priority.
The updated 32-bit field in the PROTECTION object has the layout: I(1 bit) | R(1 bit) | Reserved(6 bits) | Seg.Flags(6 bits) | Reserved(8 bits) | Preempt Prio(8 bits). The Preemption Priority field occupies bits 24-31 of this 32-bit word.