GMPLS Segment Recovery
Extracted elements (25)
Dynamic control (Section 6) allows branch and merge nodes to be identified automatically via PROTECTION object Seg.Flags, avoiding the need for explicit SEROs. The primary difference from explicit control is in how the recovery LSP's ERO is created — dynamically computed rather than derived from SERO contents.
Segment recovery is introduced because end-to-end protection is not always topologically possible, and RFC 4090 fast reroute does not support the full set of recovery types (e.g., facility backup is inapplicable to non-PSC switching technologies). These extensions enable recovery over an arbitrary portion of an LSP, supporting overlapping and nested protection.
In PSC (packet switch capable) environments, it may be desirable to construct the Sender_Template and Session objects for segment recovery LSPs per RFC 4090 conventions. These extensions are intended to be compatible with fast reroute and in some cases used together with it.
A branch node that receives an ADMIN_STATUS object in a Path message MUST relay the ADMIN_STATUS object in a Path on every recovery LSP. When the R-bit is set in the received ADMIN_STATUS, branch nodes MUST wait for Resv messages with matching ADMIN_STATUS from all branches before relaying upstream.
An SERO SHOULD contain at least three subobjects: the first MUST indicate the branch node, the second SHOULD be a protection subobject, and the final MUST be the merge node. The address in the first subobject SHOULD also appear in the ERO or another SERO to ensure the branch node is along the LSP path.
Any received SRRO MUST be transmitted by transit nodes without modification in the corresponding outgoing Path or Resv message. When Resv messages are merged, the merged Resv SHOULD contain all SRROs received in downstream Resv messages.
At a branch node, the Sender_template MUST be updated with the local node address and LSP ID updated for uniqueness; the Session object MUST use the SERO final subobject address as tunnel endpoint and the extended tunnel ID MUST be set to the local node address. Any RROs and EROs from the incoming Path message MUST NOT be included in the recovery LSP.
Branch nodes add NOTIFY_REQUEST objects to Path messages of recovery LSPs with the notify node address set to the local router address. The NOTIFY_REQUEST SHOULD NOT be removed if it is the sole NOTIFY_REQUEST object, to cover backward compatibility scenarios.
Dynamic branch identification MUST NOT be done when the processing node is identified as a branch node in an SERO. If a transit node cannot support the indicated recovery type or identify a merge node, the Path message MUST be processed normally and LSP Segment Recovery Flags MUST NOT be modified.
Non-ingress teardown via PathTear and PathErr with Path_State_Removed set (1) is NOT RECOMMENDED because it can result in removal of the LSP being protected.
RFC 3473 Section 4.2.1 is updated: subsequent NOTIFY_REQUEST objects MUST be propagated in the order received (replacing the old rule that they MAY be ignored and SHOULD NOT be propagated). A locally added NOTIFY_REQUEST object MUST be listed first; received objects follow in reception order.
The ASSOCIATION object with Resource Sharing type MUST NOT be used when association is made according to the methods defined in RFC 4090. The Association ID MUST be set to a value that uniquely identifies the association of LSPs.
When a recovery LSP PathErr with Path_State_Removed set is received and the R-bit of the protected LSP's PROTECTION object is not set (0), the outgoing PathErr SHOULD be sent with Path_State_Removed cleared (0). When the R-bit is set (1), the outgoing PathErr MUST be sent with Path_State_Removed set (1).
When adding SRROs causes a Resv message to exceed maximum size, SRRO subobjects SHOULD be removed, but the first two and last subobject in an SRRO MUST NOT be removed. The subobject following a removed one MUST have the L-bit set (1). If still too large, whole SRROs SHOULD be removed.
When LSP state is removed due to a local failure or a PathErr with Path_State_Removed flag set, the node MUST send a PathTear downstream on all other branches. When an upstream PathErr with Path_State_Removed set (1) is sent, all path state for the protected LSP MUST be removed.
While a dynamically controlled recovery LSP exists, the PROTECTION object in the original Path message MUST also be updated with the In-Place bit set (1), unless overridden by local policy. If dynamic recovery LSP creation fails, it is silently removed with no error sent upstream.
A segment recovery LSP is an independent LSP whose Sender_Template uses the branch node's IP address and whose Session object uses the merge node's IP address as the tunnel endpoint. The branch node (equivalent to RFC 4090's PLR) initiates the recovery LSP; the merge node terminates it.
The Resource Sharing Association Type (value 2) in the ASSOCIATION object enables make-before-break resource sharing for segment recovery LSPs where the LSP endpoint may change — extending RFC 3209 make-before-break which only worked when the LSP egress was the same.
IANA assigned Association Type value 2 as 'Resource Sharing (R)' in the GMPLS Signaling Parameters registry, enabling resource sharing during make-before-break for segment recovery LSPs.
IANA assigned error code value 21 ('LSP Segment Protection Failed') in the Routing Problem subsection of the RSVP PARAMETERS Error Codes and Values registry.
IANA assigned SECONDARY_EXPLICIT_ROUTE as class 200 (11bbbbbb) and SECONDARY_RECORD_ROUTE as class 201 (11bbbbbb) in the RSVP PARAMETERS registry, each with C-types mirroring ERO (C-Num 20) and RRO (C-Num 21) respectively, plus subobject type 37 (PROTECTION).
SEROs and SRROs carry more topology information (LSP path details) than simple EROs and RROs, meaning interception of a signaling message reveals slightly more network state. This is judged a minor risk since the information is already available via routing. No new signaling messages or changed control-plane adjacency relationships are introduced.
The modified PROTECTION object (class 37, C-Type 2) adds an In-Place (I) bit indicating segment recovery is already in place, a Required (R) bit indicating failure to establish protection should fail the protected LSP, and a 6-bit Seg.Flags field with values identical to LSP Flags from RFC 4872.
The SECONDARY_EXPLICIT_ROUTE object (class 200, 11bbbbbb form) has the same format as an EXPLICIT_ROUTE object. It carries a new protection subobject (type 37) with an L-bit (MUST be zero), 1-byte Reserved, 1-byte C-Type, and PROTECTION object contents matching the indicated C-Type.
The SECONDARY_RECORD_ROUTE object uses class number 201 (11bbbbbb range) with the same format as RECORD_ROUTE (class 21), and also supports the protection subobject (type 37). Both SERO and SRRO share the same subobject definitions as their ERO/RRO counterparts.