RFC 4426

Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification

📅 published March 2006, from ietf

Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification ✨

Okay bestie, this is RFC 4426 💖 It's a Standards Track doc from March 2006, written by J. Lang, B. Rajagopalan, and D. Papadimitriou (all three are listed as editors, Ed.). It's about how GMPLS networks recover from failures, meaning protection and restoration 🛡️ The title block doesn't list any documents it obsoletes or updates, so it doesn't replace or change anything else. 🎀

Status of This Memo

Okay so this one is an Internet standards track protocol for the Internet community 🌐 It's open for discussion and suggestions for improvements, so people are invited to weigh in 💬 If you want to know its official standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1) 📋 And yes, distribution of this memo is unlimited, so share it with everyone 🦋

Copyright Notice

Abstract

Okay, the vibe here is that this doc gives a functional description of the protocol extensions needed for GMPLS-based recovery, which is protection and restoration 🔥 The specific protocol formats and mechanisms get their own companion documents 🧚

Table of Contents 🌸

   1.  Introduction .................................................  2
       1.1.  Conventions Used in This Document ......................  3
   2.  Span Protection ..............................................  3
       2.1.  Unidirectional 1+1 Dedicated Protection ................  4
       2.2.  Bi-directional 1+1 Dedicated Protection ................  5
       2.3.  Dedicated 1:1 Protection with Extra Traffic ............  6
       2.4.  Shared M:N Protection ..................................  8
       2.5.  Messages ............................................... 10
             2.5.1.  Failure Indication Message ..................... 10
             2.5.2.  Switchover Request Message ..................... 11
             2.5.3.  Switchover Response Message .................... 11
       2.6.  Preventing Unintended Connections ...................... 12
   3.  End-to-End (Path) Protection and Restoration ................. 12
       3.1.  Unidirectional 1+1 Protection .......................... 12
       3.2.  Bi-directional 1+1 Protection .......................... 12
             3.2.1.  Identifiers .................................... 13
             3.2.2.  Nodal Information .............................. 14
             3.2.3.  End-to-End Failure Indication Message .......... 14
             3.2.4.  End-to-End Failure Acknowledgement Message ..... 15
             3.2.5.  End-to-End Switchover Request Message .......... 15
             3.2.6.  End-to-End Switchover Response Message ......... 15
       3.3.  Shared Mesh Restoration ................................ 15
             3.3.1.  End-to-End Failure Indication and
                     Acknowledgement Message ........................ 16
             3.3.2.  End-to-End Switchover Request Message .......... 16
             3.3.3.  End-to-End Switchover Response Message ......... 17
   4.  Reversion and Other Administrative Procedures ................ 17
   5.  Discussion ................................................... 18
       5.1.  LSP Priorities During Protection ....................... 18
   6.  Security Considerations ...................................... 19
   7.  Contributors ................................................. 20
   8.  References ................................................... 21
       8.1.  Normative References ................................... 21
       8.2.  Informative References ................................. 22

1. Introduction ✨

Okay so the big requirement is that optical and electronic switching gear need one common control plane 🔌 That control plane has to support signaling, routing, and link management mechanisms that handle data plane fault recovery, and that's the whole point 💅 In this doc, "recovery" is the umbrella word for both protection and restoration. The specific words "protection" and "restoration" only come out when you need to tell them apart 👑 The subtle difference is based on how resources get allocated during the recovery period (see [RFC4427]) 🎀

An LSP (label-switched path) might get local (span), segment, and/or end-to-end recovery 🦋 Local span protection covers the link between two neighboring switches, and every LSP marked for span protection that's routed over that link comes along for the ride. Segment protection is about recovering an LSP segment (what ITU-T calls an SNC) between two nodes, which are the boundary nodes of that segment. End-to-end protection covers an entire LSP from the ingress port to the egress port 🌈 The end-to-end models in this doc also apply to segment protection, where "source" and "destination" mean the protected segment instead of the whole LSP. A single LSP can use multiple recovery levels at once for extra resiliency 💪 The catch is that the interaction between levels matters: if one direction of the LSP gets switched, both directions of the LSP end up switched to a new span, segment, or end-to-end path 😭

Unless it says otherwise, every mention of "link" in this doc means a bi-directional link. That link might actually be a pair of unidirectional links 🔗

Now picture the control plane messages flowing while an LSP gets set up 🧚 The flow goes from an initiating (or source) node to a terminating (or destination) node, hopping through a sequence of intermediate nodes. A node is "upstream" from another node if it shows up first in that sequence, and the other node is "downstream" from it. Basically, an upstream node is closer to the initiating node than a node further downstream 🌸 Unless otherwise stated, "upstream" and "downstream" are always measured along the control plane message flow 💜

Data traffic goes the other way around, from ingress (source node) to egress (destination node) 🍓 For bi-directional LSPs, there are two separate data plane flows, one for each direction 🫶 This doc gives a protocol functional description that supports GMPLS-based recovery (protection and restoration). The protocol-specific formats, encoding, and mechanisms come later, in companion documents ✨

1.1. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 🔥

Also, the reader is assumed to already know the terminology used in [RFC3945], [RFC3471], and the other documents referenced here, plus [RFC4427] 🧠

2. Span Protection 🛡️

Okay, picture a working link i between two nodes, A and B 💖 There are two basic models for span protection. The first one is 1+1 protection. In this model, a dedicated link j is pre-assigned to protect link i. LSP traffic is permanently bridged onto both link i and link j at the ingress node, and the egress node picks the signal (aka the normal traffic) from i or j using a selection function, like signal quality 📡 With unidirectional 1+1 span protection (Section 2.1), each node A and B acts on its own to pick the signal from the working link i or the protection link j. With bi-directional 1+1 span protection (Section 2.2), nodes A and B coordinate their selection so they both pick the signal from the same link, either i or j 🤝

The second model is for a set of N working links protected by a set of M protection links, usually with M =< N. If any of the N working links fails, the traffic gets switched to one of the M protection links that's available 🔁 This is usually a three-step process. First, the data plane failure is detected at the egress node and reported (notification). Second, a protection link gets selected. Third, the LSPs on the failed link get moved to the protection link 🦋 If reversion is supported, there's a fourth step: the traffic goes back to the working link once it has recovered from the failure ✨ Section 2.3 covers 1:1 span protection, and Section 2.4 covers M:N span protection, where M =< N 🌈

2.1. Unidirectional 1+1 Dedicated Protection 💅

Suppose a bi-directional LSP is routed over link i between two nodes, A and B. Under unidirectional 1+1 protection, a dedicated link j is pre-assigned to protect the working link i 🔗 LSP traffic is permanently bridged onto both links at the ingress node, and the egress node picks the normal traffic from one of them, i or j. If node A or B detects a span failure, it autonomously kicks off a process to receive the traffic from the protection span 😭 So it's totally possible for node A to pick the signal from link i in the B-to-A direction of the LSP, while node B picks the signal from link j in the A-to-B direction 🙈

The following functionality is required for 1+1 unidirectional span protection:

Routing: A single TE link that covers both the working and protection links SHOULD be announced with a Link Protection Type "Dedicated 1+1", along with the bandwidth parameters for the working link. As resources get consumed or released, the TE link's bandwidth parameters get adjusted to match 📈 The encoding of the Link Protection Type and bandwidth parameters in IS-IS is specified in [RFC4205]. The encoding of this information in OSPF is specified in [RFC4203] 🧚
Signaling: The Link Protection object/TLV SHOULD be used to request "Dedicated 1+1" link protection for that LSP. This object/TLV is defined in [RFC3471] 🎀 If the Link Protection object/TLV isn't used, link selection is a matter of local policy. No additional signaling is required when a fail-over occurs 🌸
Link management: Both nodes MUST have a consistent view of the link protection association for the spans. This can be done with the Link Management Protocol (LMP) [RFC4204]. If LMP isn't used, this MUST be configured manually 🫶

2.2. Bi-directional 1+1 Dedicated Protection ✨

okay so picture this, bestie 🦋 we've got a bi-directional LSP routed over link i between two nodes, A and B. Under bi-directional 1+1 protection, there's a dedicated link j that's pre-assigned to protect the working link i. The LSP traffic is permanently duplicated on both links 💖 Under normal conditions, the traffic from link i gets received by nodes A and B (in the appropriate directions). If link i fails, A and B both switch over to the traffic on link j in their respective directions. The catch: some form of signaling is required to make sure both A and B start receiving traffic from the protection link 🫶 it's giving teamwork, no cap.

The basic steps in 1+1 bi-directional span protection go like this:

If a node (A or B) detects the failure of the working link (or a degradation of signal quality over the working link), it SHOULD begin receiving on the protection link and send a Switchover Request message reliably to the other node (B or A, respectively). This message SHOULD indicate the identity of the failed working link and provide other relevant information. 🔥
Upon receipt of the Switchover Request message, a node MUST begin receiving from the protection link and send a Switchover Response message to the other node (A or B, respectively). Because both the working/protect spans are exposed to routing and signaling as a single link, the switchover SHOULD be transparent to routing and signaling. ✨👑

The following functionality is required for 1+1 bi-directional span protection:

The routing procedures are the same as in 1+1 unidirectional. 🌸
The signaling procedures are the same as in 1+1 unidirectional. 🌸
In addition to the procedures described in 1+1 (unidirectional), a Switchover Request message MUST be used to signal the Switchover Request. This can be done using LMP [RFC4204]. Note that GMPLS-based mechanisms MAY not be necessary when the underlying span (transport) technology provides such a mechanism. 💅

2.3. Dedicated 1:1 Protection with Extra Traffic 🎀

okay, consider two adjacent nodes, A and B. Under 1:1 protection, a dedicated link j between A and B is pre-assigned to protect working link i. Link j may be carrying (pre-emptable) Extra Traffic 🧚 If link i fails, the corresponding LSP(s) get restored to link j. Extra Traffic that's riding over link j might need to be pre-empted to make room for the LSPs that have to be restored 😭

Once a fault is isolated or localized, the affected LSP(s) MUST be moved to the protection link. Moving an LSP from a failed (working) link to a protection link MUST be initiated by one of the nodes, A or B. This node is called the "master" 👑 The other node is called the "slave". Which one is which may be based on configured information or protocol specific requirements.

The basic steps in dedicated 1:1 span protection (ignoring reversion) go like this:

If the master detects or localizes a link failure event, it invokes a process to allocate the protection link to the affected LSP(s). 🌈
If the slave detects a link failure event, it informs the master of the failure using a failure indication message. The master then invokes the same procedure as (1) to move the LSPs to the protection link. If the protection link is carrying Extra Traffic, the slave stops using the span for the Extra Traffic. 🦋
Once the span protection procedure is invoked in the master, it requests the slave to switch the affected LSP(s) to the protection link. Before this, if the protection link is carrying Extra Traffic, the master stops using the span for this traffic (so the traffic gets dropped by the master and is not forwarded into or out of the protection link) 🙈
The slave sends an acknowledgement to the master. Before this, the slave stops using the link for Extra Traffic (so that traffic gets dropped by the slave and is not forwarded into or out of the protection link). Then it starts sending the normal traffic on the selected protection link. 🍓
When the master receives the acknowledgement, it starts sending and receiving the normal traffic over the new link. And just like that, the switchover of the LSPs is complete 🎉✨

Note: Yes this mechanism means more traffic gets dropped than strictly necessary, but it's preferred over possible misconnections during the recovery process. Honestly, being safe > being fast here 💜

From all of that, it's clear that 1:1 span protection may require up to three signaling messages for each failed span: a failure indication message, an LSP Switchover Request message, and an LSP Switchover Response message. Also, it may be possible to switch multiple LSPs from the working span to the protection span simultaneously 🌸

The following functionality is required for dedicated 1:1 span protection:

Pre-emption MUST be supported to accommodate Extra Traffic. 💅
Routing: A single TE link encompassing both working and protection links is announced with a Link Protection Type "Dedicated 1:1". If Extra Traffic is supported over the protection link, then the bandwidth parameters for the protection link MUST also be announced. The differentiation between bandwidth for working and protect links is made using priority mechanisms. In other words, the network MUST be configured such that bandwidth at priority X or lower is considered Extra Traffic. 🫶

If there is a failure on the working link, then the normal traffic is switched to the protection link, pre-empting Extra Traffic if necessary. The bandwidth for the protection link MUST be adjusted accordingly. ✨

Signaling: To establish an LSP on the working link, the Link Protection object/TLV indicating "Dedicated 1:1" SHOULD be included in the signaling request message for that LSP. To establish an LSP on the protection link, the appropriate priority (indicating Extra Traffic) SHOULD be used for that LSP. These objects/TLVs are defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy. 🎀
Link management: Both nodes MUST have a consistent view of the link protection association for the spans. This can be done using LMP [RFC4204] or via manual configuration. 👑
When a link failure is detected at the slave, a failure indication message MUST be sent to the master informing the node of the link failure. 🔥

2.4. Shared M:N Protection ✨

okay so shared M:N protection is all about two neighbors, A and B, and here's the setup 💅

At any moment, A and B have two sets of links between them: a working set of N (bi-directional) links carrying the traffic we're protecting, and a protection set of M (bi-directional) links. A protection link may be carrying Extra Traffic 🦋 There's no a priori relationship between the two sets, but the value of M and N MAY be pre-configured. The specific links in the protection set MAY be pre-configured to be physically diverse, so one failure event can't wreck a big chunk of the protection links (along with the working ones) 🫶
When a working link fails, the normal traffic gets diverted to a protection link, if one is available. Fun detail: that protection link might already be carrying more than one LSP, like an OC-192 link holding four STS-48 LSPs 🌈
More than one working link can be hit by the same failure event 😭 In that case there might not be enough protection links for all the affected traffic. Which affected working links actually get restored over the available protection links is decided by policies (for example, based on relative priority of working traffic). Those policies are not specified in this document 💀
When normal traffic has to move off a failed working link onto a protection link, the choice of which protection link is always made by one of the nodes, A or B. That node is the "master", and it is required to both apply any policies and select the specific protection links to divert working traffic. The other node is the "slave" 👑 Whether a node is master or slave MAY be based on configured information, protocol-specific requirements, or the result of running a neighbor discovery procedure 🧚
Failures get detected by transport layer mechanisms when they're available (like SONET Alarm Indication Signal (AIS)/Remote Defect Indication (RDI)) ✨ A bi-directional link is really a pair of unidirectional links, so a failure from A to B is typically caught by B, and a failure in the opposite direction is caught by A. It's also possible for one failure to hit both directions at once. Then A and B will detect the failures concurrently, B-to-A and A-to-B respectively 🔥

The basic steps in M:N protection (ignoring reversion) go like this 🎀

If the master detects a failure of a working link, it autonomously invokes a process to allocate a protection link to the affected traffic.
If the slave detects a failure of a working link, it MUST inform the master of the failure using a failure indication message. The master then invokes the same procedure as above to allocate a protection link. (It is possible that the master has itself detected the same failure, for example, a failure simultaneously affecting both directions of a link.) 🙈
Once the master has determined the identity of the protection link, it indicates this to the slave and requests the switchover of the traffic (using a "Switchover Request" message). Prior to this, if the protection link is carrying Extra Traffic, the master stops using the link for this traffic (i.e., the traffic is dropped by the master and not forwarded into or out of the protection link). 💜
The slave sends a "Switchover Response" message back to the master. Prior to this, if the selected protection link is carrying traffic that could be pre-empted, the slave stops using the link for this traffic (i.e., the traffic is dropped by the slave and not forwarded into or out of the protection link). It then starts sending the normal traffic on the selected protection link. 🦋
When the master receives the Switchover Response, it starts sending and receiving the traffic that was previously carried on the now-failed link over the new link. 🌸

Note: Although this mechanism implies more traffic dropped than necessary, it is preferred over possible misconnections during the recovery process. Dropping a bit extra is the lesser evil here, bestie 💅

From all of that, it's clear that M:N span restoration (involving LSP local recovery) MAY require up to three messages for each working link being switched: a failure indication message, a Switchover Request message, and a Switchover Response message 🍓

The following functionality is required for M:N span restoration 👑

Pre-emption MUST be supported to accommodate Extra Traffic.
Routing: A single TE link encompassing both sets of working and protect links should be announced with a Link Protection Type "Shared M:N". If Extra Traffic is supported over a set of the protection links, then the bandwidth parameters for the set of protection links MUST also be announced. The differentiation between bandwidth for working and protect links is made using priority mechanisms.

If there is a failure on a working link, then the affected LSP(s) MUST be switched to a protection link, pre-empting Extra Traffic if necessary. The bandwidth for the protection link MUST be adjusted accordingly. 🌈

Signaling: To establish an LSP on the working link, the Link Protection object/TLV indicating "Shared M:N" SHOULD be included in the signaling request message for that LSP. To establish an LSP on the protection link, the appropriate priority (indicating Extra Traffic) SHOULD be used. These objects/TLVs are defined in [RFC3471]. If the Link Protection object/TLV is not used, link selection is a matter of local policy. ✨
For link management, both nodes MUST have a consistent view of the link protection association for the links. This can be done using LMP [RFC4204] or via manual configuration. 🫶

2.5. Messages 💌

The following messages are used in local span protection procedures.

These messages SHOULD be delivered reliably. Therefore, the protocol mechanisms used to deliver these messages SHOULD provide sequencing, acknowledgement, and retransmission. The protocol SHOULD also handle situations where the message(s) cannot be delivered.

The messages described in the following subsections are abstract; their format and encoding will be described in separate documents. 🧚

2.5.1. Failure Indication Message 🚨

This message is sent from the slave to the master to indicate the identities of one or more failed working links. This message MAY not be necessary when the transport plane technology itself provides for such a notification.

The number of links included in the message depends on the number of failures detected within a window of time by the sending node. A node MAY choose to send separate failure indication messages in the interest of completing the recovery for a given link within an implementation-dependent time constraint. ⏰

2.5.2. Switchover Request Message 🔁

Under bi-directional 1+1 span protection, this message is used to coordinate the selecting function at both nodes. This message originated at the node that detected the failure.

Under dedicated 1:1 and shared M:N span protection, this message is used as an LSP Switchover Request. This message is sent from the master node to the slave node (reliably) to indicate that the LSP(s) on the (failed) working link can be switched to an available protection link. If so, the ID of the protection link, as well as the LSP labels (if necessary), MUST be indicated. These identifiers MUST be consistent with those used in GMPLS signaling. 🎀

A working link may carry multiple LSPs. Since the normal traffic carried over the working link is switched to the protection link, it MAY be possible for the LSPs on the working link to be mapped to the protection link without re-signaling each individual LSP. For example, if link bundling [RFC4201] is used where the working and protect links are mapped to component links, and the labels are the same on the working and protection links, it MAY be possible to change the component links without needing to re-signal each individual LSP. Optionally, the labels MAY need to be explicitly coordinated between the two nodes. In this case, the Switchover Request message SHOULD carry the new label mappings. 🌸

The master may not be able to find protection links to accommodate all failed working links. Thus, if this message is generated in response to a Failure Indication message from the slave, then the set of failed links in the message MAY be a sub-set of the links received in the Failure Indication message. Depending on time constraints, the master may switch the normal traffic from the set of failed links in smaller batches. Thus, a single failure indication message MAY result in the master sending more than one Switchover Request message to the same slave node. 🦋

2.5.3. Switchover Response Message 💬

This message is sent from the slave to the master (reliably) to indicate the completion (or failure) of switchover at the slave. In this message, the slave MAY indicate that it cannot switch over to the corresponding free link for some reason. In this case, the master and slave notify the user (operator) of the failed switchover. A notification of the failure MAY also be used as a trigger in an end-to-end recovery. 🔔

2.6. Preventing Unintended Connections 🚫

An unintended connection occurs when traffic from the wrong source is delivered to a receiver. This MUST be prevented during protection switching. This is primarily a concern when the protection link is being used to carry Extra Traffic. In this case, it MUST be ensured that the LSP traffic being switched from the (failed) working link to the protection link is not delivered to the receiver of the pre-empted traffic. Thus, in the message flow described above, the master node MUST disconnect (any) pre-empted traffic on the selected protection link before sending the Switchover Request. The slave node MUST also disconnect pre-empted traffic before sending the Switchover Response. In addition, the master node SHOULD start receiving traffic for the protected LSP from the protection link. Finally, the master node SHOULD start sending protected traffic on the protection link upon receipt of the Switchover Response. 🙅‍♀️

3. End-to-End (Path) Protection and Restoration 🌍

End-to-end path protection and restoration refer to the recovery of an entire LSP from the initiator to the terminator. Suppose the primary path of an LSP is routed from the initiator (Node A) to the terminator (Node B) through a set of intermediate nodes. 🛤️

The following subsections describe three previously proposed end-to-end protection schemes and the functional steps needed to implement them. 🧠

3.1. Unidirectional 1+1 Protection

okay so, a dedicated, resource-disjoint alternate path gets pre-established to protect the LSP 💖 Traffic is sent on both paths at the same time, and the end nodes A and B receive it from one of the working paths 🦋 There's no explicit signaling involved in this mode, so it's giving low-drama 💅

3.2. Bi-directional 1+1 Protection

bestie, this one is a whole vibe ✨ A dedicated, resource-disjoint alternate path gets pre-established to protect the LSP. Traffic is sent on both paths simultaneously. Under normal conditions, nodes A and B receive the traffic from the working path (in the appropriate directions). If a failure hits the working path, both A and B switch over to the traffic on the protection path in their respective directions 🔥

Note that this requires coordination between the end nodes to switch to the protection path. Both sides have to be on the same page 🫶

The basic steps in bi-directional 1+1 path protection are as follows:

Failure detection: There are two possibilities for this 🙈
1. A node in the working path detects a failure event. Such a node MUST send a Failure Indication message toward the upstream or/and downstream end node of the LSP (node A or B). This message MAY be forwarded along the working path, or routed over a different path if the network has general routing intelligence.

Mechanisms provided by the data transport plane MAY also be used for this, if available 🧚

The end nodes (A or B) detect the failure themselves (e.g., loss of signal).

Switchover: The action taken when an end node detects a failure in the working path is as follows: start receiving from the protection path. At the same time, send a Switchover Request message to the other end node to enable switching at the other end.

The action taken when an end node receives a Switchover Request message is as follows:

Start receiving from the protection path. At the same time, send a Switchover Response message to the other end node.

GMPLS signaling mechanisms MAY be used to (reliably) signal the Failure Indication message, as well as the Switchover Request and Response messages. These messages MAY be forwarded along the protection path if no other routing intelligence is available in the network 🌈

3.2.1. Identifiers

okay this part is so organized 🎀

LSP Identifier: A unique identifier for each LSP. The LSP identifier is within the scope of the Source ID and Destination ID.

Source ID: ID of the source (e.g., IP address).

Destination ID: ID of the destination (e.g., IP address).

3.2.2. Nodal Information

every node on the working or protection path of an LSP MUST know the LSP identifier, no exceptions 👑 If the network doesn't provide routing intelligence, nodal information MAY also include the previous and next nodes in the LSP, so restoration messages can get forwarded properly 🦋 When the network has general routing intelligence, messages MAY be forwarded along paths other than the LSP's own path.

At the end-point nodes, the working and protection paths MUST be associated 💅 That association MAY be provisioned using signaling, or MAY be configured when LSP provisioning doesn't involve signaling (e.g., provisioning through a management system). The association information MUST remain until the LSP is explicitly de-provisioned. Don't you dare delete it early 💀

3.2.3. End-to-End Failure Indication Message

this message gets sent (reliably) by an intermediate node toward the source of an LSP ✨ For instance, a node like that might have tried local span protection and failed. This message MAY not be necessary if the data transport layer has its own way of notifying the LSP failure to the endpoints (i.e., if the LSP endpoints are co-located with a corresponding data (transport) maintenance/recovery domain) 🫶

Say a node detects a link failure. That node MUST determine the identities of all LSPs affected by the failure of the link, and send an End-to-End Failure Indication message to the source of each LSP 😭 For scalability reasons, Failure Indication messages MAY contain the identity and status of multiple LSPs rather than just one. Each intermediate node that receives such a message MUST forward it to the appropriate next node, so the message ultimately reaches the LSP source. There's no requirement that this message flows back toward the source along the same path as the failed LSP, so it can take a different route 🦋 Also, if an intermediate node is generating its own Failure Indication message, there SHOULD be a mechanism to suppress all but one source of Failure Indication messages 👑 Finally, the Failure Indication message MUST be sent reliably from the node detecting the failure to the LSP source. Reliability MAY be achieved, for example, by retransmitting the message until an acknowledgement is received. However, retransmission of Failure Indication messages SHOULD not cause further message drops. This MAY be achieved through the appropriate configuration and use of congestion and flow control mechanisms 🌸

3.2.4. End-to-End Failure Acknowledgement Message

this one is sent by the source node to acknowledge receipt of an End-to-End Failure Indication message 💖 It goes back to the originator of the Failure Indication message. The Acknowledge message SHOULD be sent for each Failure Indication Message received. Each intermediate node that receives the Failure Acknowledgement message MUST forward it toward the destination of the message. Again, there's no requirement that it flows toward the destination along the same path as the failed LSP 🧚

This message MAY not be required if other means of ensuring reliable message delivery are used 🍓

3.2.5. End-to-End Switchover Request Message

this message is generated by the source node when it gets an indication of failure in an LSP 🔥 It's sent to the LSP destination, and it carries the identifier of the LSP being restored. The End-to-End Switchover Request message MUST be sent reliably from the source to the destination of the LSP. no excuses 💅

3.2.6. End-to-End Switchover Response Message

this is sent by the destination node when it receives an End-to-End Switchover Request message, and it goes back toward the source of the LSP 🦋 This message SHOULD identify the LSP being switched over. It MUST be transmitted in response to each End-to-End Switchover Request message received, and it MAY indicate either a positive or negative outcome 🌈

3.3. Shared Mesh Restoration

okay the vibe shifts here, so pay attention 👀 Shared mesh restoration refers to schemes where protection paths for multiple LSPs share common link and node resources. Under these schemes, the protection capacity is pre-reserved. That means link capacity is allocated to protect one or more LSPs, but explicit action is required to instantiate a specific protection LSP. This requires restoration signaling along the protection path. Typically, the protection capacity is shared only among LSPs whose working paths are physically diverse. This criterion can be enforced when provisioning the protection path. Specifically, provisioning-related signaling messages may carry information about the working path to nodes along the protection path. This can be used as call admission control, to accept or reject connections along the protection path based on the identification of the resources used for the primary path ✨

So, shared mesh restoration is designed to protect an LSP after a single failure event, meaning a failure that affects the working path of at most one LSP sharing the protection capacity. A protection path may not be successfully activated when multiple, concurrent failure events occur. In that case, shared mesh restoration capacity may be claimed for more than one failed LSP, and the protection path can be activated for only one of them (at most) 😭

For implementing shared mesh restoration, the identifier and nodal information related to signaling along the control path are as defined for 1+1 protection in Sections 3.2.1 and 3.2.2. On top of that, each node MUST also keep (local) information needed to establish the data plane of the protection path 🔥 This information MUST indicate the local resources to be allocated, the fabric cross-connect to be established to activate the path, etc. The precise nature of this information depends on the type of node and LSP (the GMPLS signaling document describes different types of switches [RFC3471]). It also depends on whether the information is fine-grained or coarse-grained. For example, fine-grained information would indicate pre-selection of all details about protection path activation, such as outgoing link, labels, etc. Coarse-grained information, on the other hand, would let some details get determined during protection path activation. For example, protection resources may be pre-selected at the level of a TE link, while the specific component link and label get selected during protection path activation 🎀

Coarser specification gives some flexibility in choosing the precise resource to activate, but it also adds complexity to decision-making and signaling during the time-critical restoration phase 💀 Furthermore, the procedures for assigning bandwidth to protection paths MUST take into account the total resources in a TE link, so that single-failure survivability requirements are satisfied 👑

3.3.1. End-to-End Failure Indication and Acknowledgement Message

the End-to-End failure indication and acknowledgement procedures and messages are the same as in Sections 3.2.3 and 3.2.4 🫶

3.3.2. End-to-End Switchover Request Message

this message is generated by the source node when it gets an indication of failure in an LSP 🔥 It's sent to the LSP destination along the protection path, and it identifies the LSP being restored. If any intermediate node can't establish cross-connects for the protection path, then it's desirable that no other node in the path establishes cross-connects for the path. This lets shared mesh restoration paths get used efficiently 🌸

The End-to-End Switchover message MUST be sent reliably from the source to the destination of the LSP along the protection path 💅

3.3.3. End-to-End Switchover Response Message

this is sent by the destination node when it gets an End-to-End Switchover Request message, and it goes back toward the source of the LSP along the protection path 🦋 This message SHOULD identify the LSP that is being switched over. Before activating the secondary bandwidth at each hop along the path, Extra Traffic (if used) MUST be dropped and not forwarded 🚫 This message MUST be transmitted in response to each End-to-End Switchover Request message received ✨

4. Reversion and Other Administrative Procedures ✨

okay so reversion is when an LSP gets moved back to its original working path after the failure is cleared and the path is repaired 🔧🦋. It applies to both local span and end-to-end path-protected LSPs. Reversion is wanted for two reasons, bestie. First, the protection path might not be optimal next to the working path when you look at routing and resource consumption 🤔. Second, moving the LSP back to its working path frees up the protection resources so they can protect other LSPs 💅. The tea is that reversion causes a second service disruption, so it's totally up to the operator whether they use it 🙃. Reversion also means a working path stays allocated to the LSP that was originally routed over it, even after a failure 📌. It's giving that mechanisms letting reversion happen with minimal service disruption for the customer are super important 🫶. This can be done with a "bridge-and-switch" approach (often called make-before-break) 🌸.

The basic steps for bridge-and-switch go like this:

The source node kicks things off by "bridging" the normal traffic onto both the working and the protection paths (or links, in the case of span protection) 🌉.
Once bridging is complete, the source node sends a Bridge and Switch Request message to the destination. This identifies the LSP and any other info needed to do reversion. When the destination gets it, it selects the traffic from the working path, and at the same time it bridges the transmitted traffic onto both the working and protection paths ✨.
The destination then sends a Bridge and Switch Response message back to the source, confirming the operation is done 💖.
When the source gets that message, it switches to receive from the working path and stops transmitting traffic on the protection path. Then it sends a Bridge and Switch Completed message to the destination to confirm the LSP has been reverted 🎀.
When the destination gets that message, it stops transmitting along the protection path and de-activates the LSP along that path. The de-activation procedure should remove the crossed connections along the protection path (and free up the resources to be used for restoring other failures) 🧚.

Other administrative procedures besides reversion include forcing a switchover (from working to protection or vice versa), and locking out switchover, which means preventing an LSP from moving from working to protection administratively 🔒. These administrative conditions have to be supported by signaling 📡.

5. Discussion 💬

5.1. LSP Priorities During Protection 👑

Under span protection, one failure event could affect more than one working link, and there could be fewer protection links than failed working links 😬. On top of that, a working link may hold multiple LSPs with different priorities. So in this scenario, a decision has to be made about which working links (and therefore which LSPs) get protected 🛡️. This decision MAY be based on LSP priorities 💅.

A node might detect failures one at a time, so not all the failed working links get detected at the same moment, just one after another 🕰️. In that case, under the proposed signaling procedures, LSPs on a working link MAY be switched over to a given protection link, but then another failure (of a working link carrying higher-priority LSPs) might get detected soon afterward 😭. When that happens, the new LSPs may bump the ones that were already switched over to the protection link 🥊.

For end-to-end shared mesh restoration, priorities MAY be implemented for allocating shared link resources under multiple failure scenarios 🌈. As described in Section 3.3, more than one LSP can claim shared resources under multiple failure scenarios. If those resources get allocated to a lower-priority LSP first, they MAY have to be reclaimed and given to a higher-priority LSP 🫢.

6. Security Considerations 🔐

Okay, security is serious, so listen up 🚨. There are a number of security threats that MAY be experienced because of the messages and information exchanged, as detailed in this document. Some examples are interception, spoofing, modification, and replay of control messages 😱. So the following security requirements apply to the mechanisms in this document:

Signaling MUST be able to provide authentication, integrity, and protection against replay attacks 🔑.
Privacy and confidentiality are not required. Only authentication is required, to make sure the signaling messages are coming from the right place and haven't been modified in transit 🫶.
Protection of the identity of the data plane end-points (in Failure Indication messages) is not required 🙈.

The consequences of poorly secured protection may raise the risk of triggering recovery actions because of false Failure Indication messages, including LSP identifiers that are not actually under failure 💀. That info could then kick off "false" recovery actions even though there's no reason to 🙃. Also, if the LSP identification gets tampered with in a Failure Indication message, recovery actions will involve nodes where the LSPs show no failure condition, or where no Failure Indication message was received 😵. The consequences of that are unpredictable and MAY lead to de-synchronisation between the control and the data plane, and they can increase the risk of misconnections 🌪️. Poorly applied protection can also increase the risk of misconnection. With Extra Traffic in the picture, it's totally possible to deliver the wrong traffic to the wrong destination 📦❌. And an intruder who sets up what looks like a valid protection LSP and then causes a fault may be able to divert traffic 🕵️‍♀️.

Tampering with a routing information exchange may also affect traffic engineering 🗺️. So any mechanisms used for securing and authenticating the transmission of routing information SHOULD be applied in this context 💜.

7. Contributors 🎀

This document was the product of many individuals working together in the CCAMP WG Protection and Restoration design team 🤝. The following are the authors who contributed to it:

Deborah Brungard (AT&T)
200 S. Laurel Ave.
Middletown, NJ 07748, USA

EMail: dbrungard@att.com


Sudheer Dharanikota

EMail: sudheer@ieee.org


Jonathan P. Lang (Sonos)
223 East De La Guerra Street
Santa Barbara, CA 93101, USA

EMail: jplang@ieee.org


Guangzhi Li (AT&T)
180 Park Avenue,
Florham Park, NJ 07932, USA

EMail: gli@research.att.com


Eric Mannie

EMail: eric_mannie@hotmail.com


Dimitri Papadimitriou (Alcatel)
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium

EMail: dimitri.papadimitriou@alcatel.be

Bala Rajagopalan
Microsoft India Development Center
Hyderabad, India

EMail: balar@microsoft.com


Yakov Rekhter (Juniper)
1194 N. Mathilda Avenue
Sunnyvale, CA 94089, USA

EMail: yakov@juniper.net

8. References 📚

8.1. Normative References 💖

[RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3471]    Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Functional Description", RFC 3471,
             January 2003.

[RFC4201]    Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
             in MPLS Traffic Engineering (TE)", RFC 4201, October
             2005.

[RFC4203]    Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions
             in Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4203, October 2005.

[RFC4204]    Lang, J., Ed., "Link Management Protocol (LMP)", RFC
             4204, October 2005.

[RFC4205]    Kompella, K., Ed. and Y. Rekhter, Ed., "Intermediate
             System to Intermediate System (IS-IS) Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 4205, October 2005.

8.2. Informative References 🦋

[RFC3945]    Mannie, E., "Generalized Multi-Protocol Label Switching
             (GMPLS) Architecture", RFC 3945, October 2004.

[RFC4427]    Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
             (Protection and Restoration) Terminology for Generalized
             Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
             2006.

Editors' Addresses ✍️

Jonathan P. Lang
Sonos, Inc.
223 East De La Guerra Street
Santa Barbara, CA 93101

EMail: jplang@ieee.org


Bala Rajagopalan
Microsoft India Development Center
Hyderabad, India

Ph: +91-40-5502-7423
EMail: balar@microsoft.com


Dimitri Papadimitriou
Alcatel
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium

Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be

Full Copyright Statement 🌈

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅.

Intellectual Property 🔍

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📜.

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🗂️.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 🫶

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 💖.

📦 where this page comes from

ietf: rfc4426 2006-03
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms