Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification
Extracted elements (31)
During protection switching, the approach of dropping more traffic than strictly necessary (disconnecting Extra Traffic before completing the switchover handshake) is preferred over the risk of misconnections, where traffic from the wrong source is delivered to a receiver.
For shared mesh restoration, coarse-grained pre-selection (reserving at TE link level, deferring component link and label selection to activation time) allows flexibility but adds complexity during the time-critical restoration phase. Fine-grained pre-selection avoids this complexity at the cost of less flexibility.
Shared mesh restoration uses pre-reserved (but not pre-instantiated) protection capacity rather than fully pre-provisioned dedicated paths, trading instantiation latency at failure time for more efficient use of network resources across multiple protected LSPs.
The master/slave architecture for 1:1 and M:N span protection is used so that exactly one node initiates protection switching. The determination of master vs. slave may be based on configured information, protocol-specific requirements, or neighbor discovery, providing deployment flexibility.
Under bi-directional 1+1 span protection, the working and protection spans are exposed to routing and signaling as a single TE link, so the switchover SHOULD be transparent to routing and signaling. GMPLS-based mechanisms MAY not be necessary when the underlying transport technology already provides the switchover mechanism.
A node detecting a link failure MUST determine the identities of all affected LSPs and send an End-to-End Failure Indication message to each LSP source. Each intermediate node receiving such a message MUST forward it to the appropriate next node. The message MUST be sent reliably from the detecting node to the LSP source.
Both nodes MUST have a consistent view of the link protection association for spans. This can be achieved using LMP (RFC 4204) or, if LMP is not used, it MUST be configured manually.
Each node on the working or protection path of an LSP MUST have knowledge of the LSP identifier. At end-point nodes, the working and protection paths MUST be associated, and the association information MUST remain until the LSP is explicitly de-provisioned.
For dedicated 1:1 span protection, a Switchover Request message MUST be used to signal the switchover request; this can be done using LMP. GMPLS-based mechanisms MAY not be necessary when the underlying transport technology provides such a mechanism.
For M:N span protection, if the slave detects a failure of a working link it MUST inform the master using a failure indication message. Additionally, affected LSPs MUST be switched to a protection link, with bandwidth for that link adjusted accordingly.
For shared mesh restoration, each node MUST keep local information needed to establish the data plane of the protection path, including local resources to be allocated and fabric cross-connects to be established.
For unidirectional 1+1 span protection, a single TE link encompassing both working and protection links SHOULD be announced with Link Protection Type 'Dedicated 1+1', along with bandwidth parameters for the working link.
In the Switchover Request message, the ID of the protection link and LSP labels (if necessary) MUST be indicated, and these identifiers MUST be consistent with those used in GMPLS signaling.
Pre-emption MUST be supported for dedicated 1:1 protection to accommodate Extra Traffic on the protection link.
Prior to activating secondary bandwidth at each hop along the shared mesh protection path, Extra Traffic MUST be dropped and not forwarded.
Protection-related messages SHOULD be delivered reliably; the protocol mechanisms used SHOULD provide sequencing, acknowledgement, and retransmission, and SHOULD handle situations where messages cannot be delivered.
Signaling MUST be able to provide authentication, integrity, and protection against replay attacks. Privacy and confidentiality are not required; only authentication is required to ensure signaling messages originate from the correct source and have not been modified in transit.
The End-to-End Switchover Request message MUST be sent reliably from the source to the destination of the LSP.
The End-to-End Switchover Response MUST be transmitted in response to each End-to-End Switchover Request message received, and MAY indicate either a positive or negative outcome.
Under bi-directional 1+1 span protection, upon receipt of a Switchover Request message, a node MUST begin receiving from the protection link and send a Switchover Response message to the other node.
Unintended connections MUST be prevented during protection switching. The master node MUST disconnect any pre-empted traffic on the selected protection link before sending the Switchover Request, and the slave MUST disconnect pre-empted traffic before sending the Switchover Response.
When a link failure is detected at the slave node (in 1:1 span protection), a failure indication message MUST be sent to the master node informing it of the link failure.
Bi-directional 1+1 end-to-end path protection pre-establishes a dedicated, resource-disjoint alternate path. Failure detection may be by an intermediate node (which sends a Failure Indication toward the end node) or by the end nodes themselves; switchover is coordinated via Switchover Request and Response messages between the two end nodes.
Reversion (returning an LSP to its original working path) is performed using a bridge-and-switch (make-before-break) procedure involving Bridge and Switch Request, Response, and Completed messages between source and destination nodes, ensuring minimal service disruption.
Shared mesh restoration pre-reserves protection capacity shared among multiple LSPs whose working paths are physically diverse, but requires explicit signaling to instantiate a specific protection LSP after a failure. The protection path can be activated for at most one failed LSP when multiple concurrent failures compete for shared capacity.
The Failure Indication Message is sent from the slave to the master to indicate the identities of one or more failed working links. A single message MAY include multiple failed links detected within a time window; separate messages MAY be sent to meet implementation-dependent time constraints.
The Switchover Request Message is sent reliably from the master to the slave, indicating which LSP(s) on a failed working link should be switched to an available protection link, including the protection link ID and, when necessary, new label mappings. A single Failure Indication may result in multiple Switchover Request messages.
The Switchover Response Message is sent reliably from the slave to the master to indicate completion or failure of the switchover. If the slave cannot switch over, both master and slave notify the operator, and the failure MAY trigger end-to-end recovery.
Poorly secured protection signaling risks triggering false recovery actions via spoofed or replayed Failure Indication messages, potentially causing de-synchronization between the control and data planes, misconnections, and diversion of traffic to unintended destinations, especially when Extra Traffic is involved.
End-to-end bi-directional 1+1 switchover: end node detects failure or receives Failure Indication → starts receiving on protection path and sends Switchover Request to peer → peer starts receiving on protection path and sends Switchover Response → originating node confirms switchover complete.
Span protection involves a master/slave state machine: slave detects failure and sends Failure Indication → master allocates protection link and sends Switchover Request (after disconnecting Extra Traffic) → slave disconnects Extra Traffic, switches to protection link, and sends Switchover Response → master completes switchover on receipt of response.