8.4. End-to-End Shared Mesh Protection
8.4.1.1. Functional Description
Shared mesh protection refers to an end-to-end protection scheme whereby network resources are shared by multiple protection paths. Typically, protection paths of connections whose working path are resource-disjoint (e.g., link disjoint) share resources. The idea is that with a single failure, at most one of the working paths will be affected, and hence the protection path of the corresponding connection may be activated. In this regard, we have to understand what a “single” failure means. To do this, first consider the types of failures that may occur:
Thus, a given failure event may affect more than one link between the same pair of nodes or even links between different node pairs. The concept of Shared Risk Link Group (SRLG, see Chapter 6) allows the network operator to assign a unique identifier to each entity that could fail due to a given event. For example, considering item (1) above, each link between a pair of nodes could be assigned an SRLG value. Similarly, considering item (3) above, each link that is routed over the same conduit could be assigned a distinct SRLG value. Thus, a link could have multiple SRLG values assigned, depending on the types of failures that are recognized.
A working path of a connection is said to be SRLG-diverse from the working path of another connection if the corresponding routes do not share any links with common SRLG values. Depending on the failure modes against which connections are protected, different SRLG values would be assigned to links. Then, if the working paths of two connections are SRLG-diverse, then any of the above types of failures that are covered by the SRLG assignment can be considered a “single” failure. That is, such a failure will not affect both connections simultaneously. Figure 8-6 illustrates this. Here, the two protection paths P1 and P2 share the bandwidth on the link between C1 and C2. The corresponding working paths are shown to be node disjoint.
Figure 8-6. Shared Protection Resources
Mesh protection requires prior soft-reservation of capacity along the protection path. Soft-reservation means that capacity is reserved but not allocated to a specific connection (i.e., no cross-connections are made in NEs to activate a specific protection path). The protection capacity may be kept idle or allocated to extra traffic that can be preempted. The protection path is explicitly activated after a failure event. Thus, unlike the 1 + 1 case, shared mesh protection requires actions at each intermediate node along the protection path during protection switching. It is possible that a protection path of a connection may not be successfully activated when multiple, concurrent failure events occur. In this case, the shared protection capacity can be assigned to at most one connection whose working path failed.
Shared mesh protection requires nodes and connections identified as described in section 8.3.3. Furthermore, each node in the working and protection path of a connection must know the identities of its upstream and downstream neighbors. Each node in the protection path of a connection must also know the cross-connection needed to establish the data plane. This information could be of the following form:
{Connection ID, <Incoming Port, Channel, etc.>, <Outgoing Port, Channel, etc.> }
The precise nature of the Port, Channel, etc. information would depend on the type of node and connection.
Under mesh protection, failure detection and indication are similar to the procedures described for end-to-end 1 + 1 protection. Once the source NE learns of the failure, it activates the protection path by sending an end-to-end switchover request along the protection path. This message results in certain actions in the intermediate nodes. The destination activates the protection path and sends an end-to-end switchover response message. This activates the protection path in each intermediate NE and the source. The details are as follows.
8.4.2. Messages
8.4.2.1. END-TO-END FAILURE INDICATION AND ACKNOWLEDGMENT
The end-to-end failure indication and acknowledgment procedures and messages are as defined in section 8.3.3.
8.4.2.2. END-TO-END SWITCHOVER REQUEST
This message is generated by the source node after receiving an indication of failure in the working path. It is sent to the connection destination along the protection path, and it carries the ID of the connection being restored. This message must allow intermediate nodes to record whether they are able to activate the protection path. Suppose that some intermediate node is not able to establish the cross-connects for the protection path. It is then desirable that no other node in the protection path establishes cross-connects for the path. This would allow shared mesh protection paths to be efficiently utilized. This requirement implies that the switchover to the protection path should occur in two phases: In the forward phase, the Switchover Request message indicates the impending protection switch to the intermediate nodes in the protection path and collects information as to their ability to switch. In the reverse phase, the actual protection switching occurs if all nodes in the path indicate their ability to switch over.
8.4.2.3. END-TO-END SWITCHOVER RESPONSE
The destination node sends this message in response to each End-to-End Switchover Request it receives. This message is sent along the protection path toward the source of the connection. This message indicates the ID of the connection being switched over, and whether all the intermediate nodes have agreed to switch over (as determined in the forward phase using the Switchover Request message).
8.4.2.4. REVERSION
Reversion refers to the process of moving traffic back to the working path from its protection path after the former is repaired. With shared mesh protection, reversion is desired for the following reasons. First, the protection route may not be as efficient as the route of the working path. Second, moving a connection to its working path allows the protection resources to be used to protect other connections.
Reversion requires the following steps:
We shall see how the reversion signaling could be realized in section 8.4.3.4.
8.4.3. Signaling Procedures
As before, signaling can be bit-oriented or based on a higher-level protocol. Similar functionality has to be achieved in either case. In the following, we consider the possible use of GMPLS RSVP-TE signaling for shared mesh protection. As before, this discussion is not based on any specific standard that has been proposed for protection signaling, but merely an examination of the possibilities.
8.4.3.1. PROVISIONING THE PROTECTION PATH
Unlike the 1 + 1 case, the protection path is distinct from the working path in that resources are reserved but not allocated to the connection along the protection path. Such a shared protection path can be established by using the GMPLS RSVP-TE Path message with the appropriately set protection object (see section 7.5.1.7). Specifically, in the protection object, the S (Secondary) bit and bit 2 of the link flags must be set to indicate shared mesh protection. As in the case of 1 + 1 protection, the working and protection paths must be associated using the same LSP ID (see section 7.4.2.1). Finally, the Path state in each node in the protection path must reflect the fact that the path is not active. This requires some extensions to the existing RSVP-TE scheme.
8.4.3.2. END-TO-END FAILURE INDICATION AND ACKNOWLEDGMENT
The Notify message can be used in the same manner as described for 1 + 1 protection in section 8.3.4.2.
8.4.3.3. END-TO-END SWITCHOVER REQUEST AND RESPONSE
The Path message can be used as the End-to-End Switchover Request mechanism. As described in section 8.4.2.2, the intermediate NEs along the protection path must record their ability to activate the protection path in this message. As in the 1 + 1 case, the Administrative Status object can be used to both indicate that the protection path is being activated and to record the inability of an intermediate node to activate the path. To do this, the P bit in the object is set to 1 to indicate protection switching as before. The R bit is set to 1 to request the receiver to reflect the received Administrative Status object. A new bit is used to indicate whether all NEs can activate the protection path. Let us call this the N bit. The new Administrative Status object is depicted in Figure 8-7. The N bit is set to 0 by the source, and an intermediate NE sets it to 1 if it cannot activate the protection path. If the receiver sees the N bit set to 0, it activates the protection path. Regardless of the status of the N bit, the receiver reflects the received Administrative Status object in a Resv message. This message acts as the End-to-End Switchover Response and traverses to the source along the protection path. Each intermediate NE examines the N bit, and if it is 0, activates the protection path.
Figure 8-7. Enhanced Administrative Status Object
The message sequence for shared mesh protection is similar to that shown in Figure 8-5, except for the addition of the N bit to the Administrative Status object.
8.4.3.4. REVERSION
With GMPLS RSVP-TE, reversion is realized as follows:
The working path is reestablished using Path and Resv message exchanges.
The traffic is switched from the protection path to the working path using Path and Resv messages with Administrative Status objects, as described in section 8.3.4 for bidirectional 1 + 1 protection.
The protection path resources are deallocated as follows. The source NE sends a Path message to the destination along the protection path. This message has an Administrative Status object with the D and R bits set to 1. The destination returns a Resv message in response along the reverse path. In this message, the Administrative Status object has the D bit set to 1, and the R bit is set to 0. Each intermediate node then releases the cross-connections and makes the shared protection capacity available to other connections.