MPLS-TP Ring Protection
draft-weingarten-mpls-tp-ring-protection-03.txt

Abstract

This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document [TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimzing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, without the need of specification of new constructs or protocols.

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on December 31, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
    1.1.  Problem statement
    1.2.  Terminology and Notation
    1.3.  Contributing Authors
2.  P2P Ring Protection
    2.1.  Wrapping
    2.2.  Steering
    2.3.  P2P ring protection with SPME
        2.3.1.  Path SPME for Steering
        2.3.2.  Wrapping with segment based SPME
        2.3.3.  Wrapping node protection
        2.3.4.  Wrapping for link and node protection
    2.4.  Analysis of p2p protection
3.  P2MP protection
    3.1.  Wrapping for p2mp LSP
        3.1.1.  Comparison of Wrapping and ROM-Wrapping
        3.1.2.  Multiple Failures Comparison
    3.2.  Steering for p2mp paths
4.  Coordination protocol
5.  Interconnected rings
6.  Conclusions and Recommendations
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  Informative References
§  Authors' Addresses

1.  Introduction

Multi-Protocol Label Switching Transport Profile (MPLS-TP) is being standardized as part of a joint effort between the Internet Engineering Task Force (IETF) and the International Telecommunication Union Standardization (ITU-T). These specifications are based on the requirements that were generated from this joint effort.

The requirements for MPLS-TP [TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) indicates a requirement to support a network that may include sub-networks that constitute a MPLS-TP ring as defined in the requirements. There were no requirements specific to a ring topology indicated in the requirements document. However, the requirements state that specific protection mechanisms aimed at ring topologies may be developed if these allow the network to optimize:

• Number of OAM entities needed to trigger the protection
• Number of recovery objects needed
• Number of labels required
• Number of control and management plane transactions during a recovery operation
• Impact of signaling and routing information exchanged, in presence of control plane

This document will propose a set of basic mechanisms that could be used for the protection of the data flows that traverse a MPLS-TP ring. The mechanism is based on existing MPLS and MPLS-TP protection mechanisms. We show that this mechanism provides the ability to protect all of the basic conditions within a reasonable time frame and does optimize the criteria set out in [TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) as summarized above.

1.1.  Problem statement

Ring topologies, as definied in [TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.), are used in transport networks due to their ability to easily support both p2p and p2mp transport paths. When designing a protection mechanism for a ring topology, there is a need to address both –

1. Simple case of a transport path that enters a MPLS-TP capable ring at one node, the ingress node, and exits the ring at a single egress node possibly continuing beyond the ring.
2. Case where the ring is being used as a branching point, i.e. the transport path enters the MPLS-TP capable ring at the ingress node and exits through a number of egress nodes, possibly continuing beyond the ring.

Within the ring segment of the transport path there is the need to address the following different cases –

1. One of the ring links causes a fault condition. This could be either a unidirectional or bidirectional fault, and should be detected by the neighboring nodes.
2. One of the ring nodes causes a fault condition. This condition is invariably a bidirectional fault (although in rare cases of misconfiguration this could be detected as a unidirectional fault) and should be detected by the two neighboring ring nodes.
3. An operator command is issued to a specific ring node. Examples of these commands include Manual Switch, Forced Switch, or Clear operations.

The protection domain addressed in this document is limited to the traffic that is traversing the ring. Traffic on the transport path prior to the ring ingress node or beyond the egress nodes may be protected by some other mechanism.

1.2.  Terminology and Notation

The terminology used in this document is based on the terminology defined in the MPLS-TP framework documents:

• MPLS-TP Framework[TPFwk] (Bocci, M., Bryant, S., Frost, D., and L. Levrau, “MPLS-TP Framework,” May 2010.)
• MPLS-TP OAM Framework[OAMFwk] (Niven-Jenkins, B., Allan, D., and I. Busi, “MPLS-TP OAM Framework,” May 2010.)
• MPLS-TP Survivability Framework[SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.)

In addition, we describe the use of the label stack in connection with the redirecting of data packets by the protection mechanism. The following syntax will be used to describe the contents of the label stack:

1. The label stack will be enclosed in square brackets ("[]")
2. Each level in the stack will be separated by the '|' character
3. The bottom of the stack will be denoted by the string "BOS"
4. The label of an ingress LSP will be denoted by the string "LI" and the label of the egress LSP will be denoted by the string "LE"
5. The label for a SPME will be denoted by Px(y) where x and y are LSR identifiers and the intention is to the label for LSR-x to transmit to LSR-y over the SPME.

For example - the label stack [PB(G)|LI|BOS] denotes a stack whose top-label is the SPME label for LSR-B to transmit the data packet to LSR-G, the packet originated from a LSP that arrived at the ring with label LI.

1.3.  Contributing Authors

Akira Sakurai (NEC), Rolf Winter (NEC)

2.  P2P Ring Protection

Classically there are two protection architecture mechanisms for ring topologies, based on SDH specifications [G.841] (, “Types and characteristics of SDH network protection architectures,” October 1998.), that have been proposed in various forums to perform recovery of a topological ring network – "wrapping" and "steering". The following sub-sections will examine these two mechanisms.

2.1.  Wrapping

Wrapping is defined as a "local" protection architecture. This mechanism is local to the LSRs that are neighbors to the detected fault. When a fault is detected (either a link or node failure), the neighboring LSR can identify that the fault would prevent forwarding of the data along the data path. Therefore, in order to continue the data along the path, there is need to "wrap" all data traffic around the ring, on an alternate data path, until arriving at the LSR that is on the opposite side of the fault. When this LSR also detects that there is a fault condition on the LSP, it can identify that the data traffic that is arriving on the alternate (protecting) data path is intended for the "broken" LSP. Therefore, again taking a local decision, can wrap the data back onto the normal working path until the egress from the ring segment.

                                     ____
                           =========>/ LSR\
                                   * \__B_/ *
                                  * @@@@@@@# *
                                 * @       @# *
                             ___* @         @# *___
                            /LSR\ @          @#/LSR\
                            \_C_/ @           #\_A_/
                              *  @             # *
                              *  @              XX
                             _*_ @              #*_
                            /LSR\@             /LSR\
                            \_D_/@            @\_F_/
                                * @          @#*
                                 * @       @@#*
                                  * @@____@##*
                                    */ LSR\*
                                     \__E_/========>

		===> connected LSP  *** physical link
		###  working path   @@@ wrapped data path

In this figure we have a ring with a LSP that enters the ring at LSR-B and exits at LSR-E. The normal working path follows through B-A-F-E. If a signal fault is detected on the link A<—>F, then the wrapping mechanism decides that LSR-A would wrap the traffic around the ring, on a wrapped data path A-B-C-D-E-F, to arrive at LSR-F (on the far side of the failed link). LSR-F would then wrap the data packets back onto the working path F—>E to the egress node. In this protection scheme, the traffic will follow the path – B-A-B-C-D-E-F-E.

This protection scheme is simple in the sense that there is no need for coordination between the different LSR in the ring – only the LSRs that detect the fault must wrap the traffic, either onto the wrapped data path (at the near-end) or back to the working path (at the far-end). Coordination would only be needed to maintain co-routed bidirectional traffic even in cases of a unidirectional fault condition.

The following considerations should be taken into account when considering use of wrapping protection:

• Detection of loss-of-continutiy or misconnectivity, should be performed at the link level and/or per LSR when using node-level protection. Configuration of the protection being performed (i.e. link protection or node protection) needs to be performed a-priori, since the configuration of the proper protection path is dependent upon this decision.
• There is a need to define a data-path that traverses the alternate path around the ring to connect between the two neighbors of the detected fault. If protecting both the links and the nodes of a LSP, then, for a ring with N nodes, there is a need for O(2N) alternate paths.
• When wrapping, the data is transmitted over some of the links twice, once in each direction. For example, in the figure above the traffic is transmitted both B—>A and then A—>B, later it is transmitted E—>F and F—>E. This means that there is additional bandwith needed for this protection.
• If a double-fault situation occurs in the ring, then wrapping will not be able to deliver any packets except between the ingress and the first fault location. This is based on the need for wrapping to connect between the neighbors of the fault location, and this is not possible in the segmented ring.
• The resource allocation for the alternate-paths could be problematic, since most of these alternate paths will not be used simultaneously. One possibility could be to allocate '0' resources and depend on the NMS to allocate the proper resources around the ring.
• Wrapping also involves greater latency in delivering the packets, as a result of traversing the entire ring. This could be very restrictive for large rings.

2.2.  Steering

The second common scheme for ring protection redirects the traffic from the ingress point to the alternate route around the ring to the egress point. This is illustrated in Figure 2 (A MPLS-TP ring), where if a Signal Fault is detected on the working path (B-A-F), then the traffic would be redirected by B to the alternate path (i.e. B-C-D-E-F).

This mechanism is similar to linear 1:1 protection [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.). The two paths around the ring act as the working and recovery paths. There is need to communicate to the ingress node the need to switch over to the recovery path and there is a need to coordinate the switchover between the two end-points of the protected domain.

The following considerations must be taken into account regarding the steering architecture:

• It is necessary for the ingress node to be "informed" of the fault condition in order to perform the protection switching.
• The process of "informing" the ingress node adds to the latency of the protection switching process, after the detection of the fault condition.
• While there is no need for double bandwidth for the data path, there is the necessity for the ring to maintain enough capacity for all of the data in both directions around the ring.

2.3.  P2P ring protection with SPME

The MPLS-TP Framework document [TPFwk] (Bocci, M., Bryant, S., Frost, D., and L. Levrau, “MPLS-TP Framework,” May 2010.) defines a Sub-Path Maintenance Entity (SPME) construct that can be defined between any two LSRs of a MPLS-TP LSP. For MPLS-TP purposes, such a SPME may be configured as a bidirectional co-routed path. A SPME may be used to aggregate all LSP traffic that traverses the segment (from ingress LSR to egress LSR) that is delineated by the SPME. This SPME may be monitored using the OAM mechanisms as specified in the MPLS-TP OAM Framework document [OAMFwk] (Niven-Jenkins, B., Allan, D., and I. Busi, “MPLS-TP OAM Framework,” May 2010.).

When defining a MPLS-TP ring as a protection domain, there is a need to design a protection mechanism that protects all the LSPs that cross the MPLS-TP ring. For this purpose, we associate a (working) SPME with the segment of the transport path that traverses the ring. In addition, we configure an alternate (protecting) SPME that traverses the ring in the opposite direction around the ring. The exact selection of the two SPMEs is dependent on the type of transport path and protection that is being implemented and will be detailed in the following sections.

Based on this architectural configuration for ring protection, it is possible to restrict the number of alternate paths needed to protect the data traversing the ring. Similarly, we can minimize the number of OAM sessions needed to monitor the data traffic of the ring - by monitoring the SPMEs, rather than monitoring each individual LSP.

The following figure shows a MPLS-TP ring that is part of a larger MPLS-TP network. The ring could be used as a network segment that may be traversed by numerous LSPs. In particular, the figure shows that for all LSPs that connect to the ring at LSR-B and exit the ring from LSR-F, we configure two SPME through the ring (the first SPME traverses along B-A-F, and the second SPME traverses B-C-D-E-F).

                               ____
                    =========>/ LSR\
                            * \__B_/ *
                           * @      # *
                          * @        # *
                       __* @          # *___
                     /LSR\ @           #/LSR\
                     \_C_/ @           #\_A_/
                       *  @             # *
                       *  @              #*
                      _*_ @              #*_
                     /LSR\@             /LSR\========>
                     \_D_/@             \_F_/
                         * @           @*
                          * @         @*
                           * @@____@@*
                             */ LSR\*
                              \__E_/


        ===> connected LSP    *** physical link
        ###  primary SPME      @@@ secondary SPME

In all of the following subsections, we use 1:1 linear protection [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.) [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.) to perform protection switching and coordination when a signal fault is detected. The actual configuration of the SPMEs used may change dependent upon the choice of methodology and this will be detailed in the following sections. However, in all of these configurations the mechanism will be to transmit the data traffic on the primary SPME, while using OAM functionlity to detect signal fault conditions on either the primary or the secondary SPME. If a signal fault is detected on the primary SPME, then the mechanism described in [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.) shall be used to coordinate a switch-over of data traffic to the secondary SPME.

Assuming that the SPME is implemented as an hierarchial LSP, packets that arrive at LSR-B with a label stack [L1|BOS] will have the SPME label pushed at LSR-B (i.e. the packet will arrive at LSR-A with a label stack of [PA(F)|L1|BOS], arrive at LSR-F with [PF(F)|L1|BOS]). The SPME label will be popped by LSR-F and the LSP label will be treated appropriately at LSR-F and forwarded along the LSP. This scenario is true for all LSP that are aggregated by this primary SPME.

2.3.1.  Path SPME for Steering

A p2p SPME that traverses part of a ring has two Maintenance Entity Group End Points (MEPs), each one acts as the ingress and egress in one direction of the bidirectional SPME. Since the SPME is traversing a ring we can take advantage of another characteristic of a ring - there is always an alternative path between the two MEPs, traversing the ring in the opposite direction. This alternative SPME can be defined as the protection path for the working path that is configured as part of the LSP and defined as a SPME.

For each pair of SPMEs that are defined in this way, it is possible to verify the connectivity and continuity by applying the MPLS-TP OAM functionality to both the working and recovery SPME. If a discontinuity or mis-connectivity is detected then the MEPs will become aware of this condition, and could perform a protection switch of all LSPs to the alternate, recovery SPME.

This protection mechanism is identical to application of 1:1 linear protection[SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.) [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.) to the pair of SPMEs. Under normal conditions, all LSP data traffic will be transmitted on the working SPME. If the linear protection is triggered, by either the OAM indication, an other fault indication trigger, or an operator command, then the MEPs will select the recovery SPME to transmit all LSP data packets.

The recovery SPME will continue to transmit the data packets until the stable recovery of the fault condition. Upon recovery, the ingress LSR could switch traffic back to the working SPME, if the protection domain is configured for revertive behavior.

The control of the protection switching, especially for cases of operator commands, would be covered by the protocol defined in [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.).

2.3.2.  Wrapping with segment based SPME

It is possible to use the SPME mechanism to perform segment-based protection. For each link in the ring, we define two SPME - the first is a SPME between the two LSRs that are connected by the link, and the second SPME between these same two LSRs but traversing the entire ring (except the link that connects the LSRs). In Figure 3 (Segment SPMEs) we show the primary SPME that connects LSR-A & LSR-F over a segment connection, and the secondary SPME that connects these same LSRs by traversing the ring in the opposite direction.

                               ____
                              / LSR\
                            * \__B_/ *
                           * @      @ *
                          * @        @ *
                       __* @          @ *___
                     /LSR\ @           @/LSR\
                     \_C_/ @            \_A_/
                       *  @              #*
                       *  @              #*
                      _*_ @              #*_
                     /LSR\@             /LSR\
                     \_D_/@             \_F_/
                         * @           @*
                          * @         @*
                           * @@____@@*
                             */ LSR\*
                              \__E_/


                    *** physical link
        ###  primary SPME      @@@ secondary SPME

By applying OAM monitoring of these two SPME (at each LSR), it is possible to affect a wrapping protection mechanism for the LSP traffic that traverses the ring. The LSR on either side of the segment would identify that there is a fault condition on the link and redirect all LSP traffic to the secondary SPME. The traffic would traverse the ring until arriving at the neighboring (relative to the segment) LSR. At this point, the LSP traffic would be redirected onto the original LSP, quite likely over the neighboring SPME.

Following the progression of the label stack through this switching operation:

1. The data packet arrives at LSR-A with label stack [LI|BOS] (i.e. top label from the LSP and bottom-of-stack indicator)
2. In the normal case (no switching), LSR-A forwards the packet with label stack [PA1(F)|LE|BOS] (i.e. swap the label for the LSP, to be acceptable to the SPME egress, and push the label for the primary SPME from LSR-A to LSR-F).
3. When switching is in-effect, LSR-A forwards the packet with label stack [PA2(F)|LE|BOS] (i.e. LSR-A pushed the label for the secondary SPME from LSR-A to LSR-F, after swapping the label of the lower level LSP).
4. When the packet arrives at LSR-F, it will pop the SPME label, process the LSP label, and forward the packet to the next point, possibly pushing a SPME label if the next segment is likewise protected.

2.3.3.  Wrapping node protection

Implementation of protection at the node level would be similar to the mechanism described in the previous sub-section. The difference would be in the SPMEs that are used. For node protection, the primary SPME would be configured between the two LSR that are connected to the node that is being protected (see SPME between LSR-A and LSR-E through LSR-F in Figure 4 (Node-protection SPMEs)), and the secondary SPME would be configured between these same nodes, going around the ring (see secondary SPME in Figure 4 (Node-protection SPMEs)).

                               ____
                              / LSR\
                            * \__B_/ *
                           * @      @ *
                          * @        @ *
                       __* @          @ *___
                     /LSR\ @           @/LSR\
                     \_C_/ @            \_A_/
                       *  @              #*
                       *  @              #*
                      _*_ @              #*_
                     /LSR\@             /LSR\
                     \_D_/@             \_F_/
                         * @           # *
                          * @         # *
                           * @@____  # *
                             */ LSR\#*
                              \__E_/


                  *** physical link
        ###  primary SPME      @@@ secondary SPME

The protection mechanism would work similarly - based on 1:1 linear protection [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.), triggered by OAM functions on both SPMEs, and wrapping the data packets onto the secondary SPME at the ingress MEP (e.g. LSR-A in the figure) of the SPME and back onto the continuation of the LSP at the egress MEP (e.g. LSR-E in the figure) of the SPME.

2.3.4.  Wrapping for link and node protection

In the different types of wrapping presented in sections 2.3.2 and 2.3.3, there is a limitation that the protection mechanism must a priori decide whether it is protecting for link or node failure. In addition, the neighboring LSR, that detects the fault, cannot readily differentiate between a link failure or a node failure.

It is possible to combine the link protection mechanism presented in section 2.3.2 with the protection mechanism of section 2.3.3 to give more complete coverage. For each segment, we configure both a secondary link protection SPME as well as a two secondary node protection SPME, i.e. one for each direction of the bidirectional segment SPME (see Figure 5 (Segment & Node protection SPMEs)). When a protection switch is triggered, the ingress LSR of the segment will examine the packet ring destination. Only if this destination is for the LSR connected to the "secondary link" SPME, then the packets will be wrapped onto this secondary SPME. For all other cases, the data packets will be wrapped onto the "secondary node" SPME. In all cases the egress LSR for the secondary SPME will wrap the data traffic back onto the working LSP/SPME.

                               ____
                              / LSR\
                            * \__B_/ *
                           * @+$   +@ *
                          * @+$     +@ *
                       __* @+$       +@ *___
                     /LSR\ @+$        +@/LSR\
                     \_C_/ @+$          \_A_/
                       *  @+$            #*
                       *  @+$            #*
                      _*_ @+$            #*_
                     /LSR\@+$           /LSR\
                     \_D_/@+$           \_F_/
                         * @+$          $+*
                          * @+$       $+*
                           * @++$+$+$+*
                             */ LSR\*
                              \__E_/


                     *** physical link
        ###  primary SPME           @@@ secondary node#1 SPME
        $$$  secondary node#2 SPME  +++ secondary segment SPME

2.4.  Analysis of p2p protection

Analyzing the mechanisms described in the above subsections we can point to the following observations (based on a ring with N nodes):

• Number of SPME that need to be configured – for path SPME (sec 2.3.1) = O(2N^2) [two SPME from each ingress LSR to each other node in the ring], for segment SPME (sec 2.3.4) = O(4N) [four SPME for each link in the ring]
• Number of OAM sessions at each node – for path SPME = O(2N), for segment SPME = 4
• Bandwidth requirements – for path SPME: single bandwidth at each link, for segment SPME: double bandwidth at links that are between ingress and wrapping node and between second wrapping node and egress.
• Special considerations – for path SPME: latency of OAM detection of fault condition by ingress MEP [using Alarm-reporting could optimize over using CC-V only], for segment SPME: need to examine data packet ring destination before selecting bypass SPME.

3.  P2MP protection

[TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) requires that ring protection must provide protection for unidirectional point-to-multipoint paths through the ring. Ring topologies provide a ready platform for supporting such data paths. A p2mp LSP in an MPLS-TP ring would be characterized by a single ingress LSR and multiple egress LSRs. The following sub-sections will present methods to address the protection of the ring-based sections of these LSP.

3.1.  Wrapping for p2mp LSP

When protecting a p2mp ring data path using the wrapping architecture, the basic operation is similar to the description given, as the traffic has been wrapped back onto the normal working path on the far-side of the detected fault and will continue to be transported to all of the egress points.

It is possible to optimize the performance of the wrapping mechanism when applied to p2mp LSPs by exploiting the topology of ring networks.

This improved mechanism, which we call Ring Optimized Multicast Wrapping (ROM-Wrapping), behaves much the same as classical wrapping. There is one difference – rather than configuring the recovery LSP between the end nodes of a failed link (link protection) or between the upstream and downstream node of a failed node (node protection), the improved mechanism configures a recovery p2mp LSP from the upstream (with respect to the failure) node and all egress nodes (for the particular LSP) downstream from the failure.

Referring to Figure 6 (P2MP ROM Wrapping), it is possible to identify the protected (working) LSP (A-B-[C]-[D]-E-[F]) and one possible backup (protection) LSP. This protection LSP will be used to wrap the data back around the ring to protect against a failure on link B-C. This protection LSP is also a p2mp LSP that is configured with egress points (at nodes F, D, & C) complimentary to the broken working data path.

                                       |
                                       |
                                       V  Ingress
                    ___               _V_                ___
                   /LSR\             /LSR\**************/LSR\
                <@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
                    @ *                                    *
                    @ *                                    *
                    @ *                                  XXXX Failure
                    @ *                                    *
                    @_*               ___                __*
                   /LSR\*************/LSR\**************/LSR\
                   \_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
                                      @                  @
                                      @                  @
                                      V                  V


                    ***  working LSP      @@@ protection LSP

Using this mechanism, there is a need to configure a particular protection LSP for each node on the working LSP. In the table below, "X's Backup" is the backup path activated by node X as a consequence of a failure affecting node Y (downstream node with respect to X) or link X-Y, and square brackets, in the path,indicate egress nodes.

Protected LSP: A–>B–>[C]–>[D]–>E–>[F]

—— LINK/NODE PROTECTION——

It should be noted that ROM-Wrapping is an LSP based protection mechanism, as opposed to the SPME based protection mechanisms that are presented in other sections of this draft. While this may seem to be limited in scope, the mechanism may be very efficient for many applications that are based on p2mp distribution schemes. While ROM-Wrapping can be applied to any network topology, it is particularly efficient for interconnected ring topologies.

3.1.1.  Comparison of Wrapping and ROM-Wrapping

It is possible to compare the Wrapping and the ROM-Wrapping mechanisms in different aspects, and show some improvements offered by ROM-Wrapping.

When configuring the protection LSP for Wrapping it is necessary to configure for a specific failure: link protection or node protection. If the protection method is configured to protect node failures but the actual failure affects a link, this could result in failing to deliver traffic to the node, when it should be possible to.

ROM-Wrapping however does not have this limitation, because there is no distinction between node and link protection. Whether link B-C or node C fails, in either case the rerouting will attempt to reach C. If the failure is on the link, the traffic will be delivered to C, while if the failure is at node C, the traffic will be rerouted correctly until node D, and will be blocked at this point. However, all egress nodes upto the failure will be able to deliver the traffic properly.

A second aspect is the number of hops needed to properly deliver the traffic. Referring to the example shown in Figure 6 (P2MP ROM Wrapping), where a failure is detected on link B-C, the following table lists the set of nodes traversed by the data in the protection:

Basic Wrapping:

ROM Wrapping:

Comparing the two lists of nodes, it is possible to see that in this particular case the number of hops crossed using the simple Wrapping is significantly higher than the number of hops crossed by the traffic when ROM-Wrapping is used. Generally, the number of hops for basic Wrapping is always higher or at least equal compared to ROM-Wrapping. This implies a certain waste of bandwidth on all links that are crossed in both directions.

Considering the ring network previously seen, it is possible to do some bandwidth utilization considerations. The protected LSP is set up from A to F clockwise and an M Mbps bandwidth is reserved along the path. All the protection LSPs are preprovisioned counterclockwise, each of them may also have reserved bandwidth M. These LSPs share the same bandwidth in a SE (Shared Explicit) [RSVP] (Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) - Functional Specifications,” September 1997.) style.

The bandwidth reserved counterclockwise is not used when the protected LSP is properly working and could, in theory, be used for extra traffic [RFC4427] (Mannie, E. and D. Papadimitriou, “Recovery (Protection and Restoration) Terminology for GMPLS,” March 2006.). However, it should be noted that [TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) does not require support of such extra traffic.

The two recovery mechanism require different protection bandwidths. In the case of Wrapping, the bandwidth used is M in both directions of many of the links. While in case of ROM-Wrapping, only the links from the ingress node to the node performing the actual wrapping utilize M bandwidth in both directions, while all other links utilize M bandwidth only in the counterclockwise direction.

Consider the case of a failure detected on link B-C as shown in Figure 6 (P2MP ROM Wrapping). The following table lists the bandwidth utilization on each link (in units equal to M), for each recovery mechanism and for each direction (CW=clockwise, CCW=counterclockwise).

3.1.2.  Multiple Failures Comparison

A further comparison between Wrapping and ROM-Wrapping can be done with respect to their ability to react to multiple failures. The wrapping recovery mechanism does not have the ability to recover from multiple failures on a ring network, while ROM-Wrapping is able to recover, from some multiple failures.

Consider, for example, a double link failure affecting links B-C and C-D shown in Figure 6 (P2MP ROM Wrapping). The Wrapping mechanism is not able to recover from the failure because B, upon detecting the failure, has no alternative paths to reach C. The whole P2MP traffic is lost. The ROM-Wrapping mechanism is able to partially recover from the failure, because the backup P2MP LSP to node F and node D is correctly set up and continues delivering traffic.

3.2.  Steering for p2mp paths

To take advantage of the ring topology in protecting the data traffic over p2mp LSPs, we can configure two p2mp unidirectional SPME from each node on the ring that traverse the ring in both directions. These SPME will be configured with an egress at each ring node. For every LSP that enters the ring at a given node the traffic will be sent through one of these SPME (the working SPME) – pushing the SPME label onto the packet label stack. Each LSR on the ring will forward a copy of the packet along the SPME, but check the packet by popping the SPME label and examining the underlying LSP label. If this LSR is an egress point for the LSP it will treat the data packet appropriately. If the LSR is not an egress point for the LSP, the packet will be silently dropped.

                            ^            ^            ^
                           _|_          _|_          _|_
                    ----->/LSR\********/LSR\********/LSR\
                          \_A_/========\_B_/========\_C_/
                           +*              <+++++++++*||
                           +*                       +*||
                           +*                       +*||
                           +*                       +*||
                           +*_ ++++++++     +++++++++*||
                          /LSR\********/LSR\********/LSR\
                          \_F_/<=======\_E_/========\_D_/
                            |            |            |
                            V            V            V

        ---> connected LSP      *** physical link
        ===  primary p2mp SPME  +++ secondary p2mp SPME

Using this SPME architecture, we define a 1+1 linear protection mechanism [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.) for all protected data traffic traversing the MPLS-TP ring. The data for a particular p2mp LSP is transmitted on both the working and recovery SPME, using a permanent bridge. While each node detects that there is connectivity from the ingress point, it continues to select the data that is coming from the working path. If a particular node stops receiving the connectivity messages from the working path SPME, it identifies that it must switch its selector to read the data packets from the recovery SPME.

Figure 7 (P2MP SPMEs) shows the two unidirectional p2mp SPME that are configured from LSR-A with egress points at all of the nodes on the ring. The clockwise SPME (i.e. A-B-C-D-E-F) is configured as the working SPME, that will aggregate all traffic for p2mp LSPs that enter the ring at LSR-A and must be sent out of the ring at any subset of the ring nodes. The counter-clockwise SPME (i.e. A-F-E-D-C-B) is configured as the recovery SPME. Applying 1+1 linear protection to these two SPME – a packet that arrives at LSR-A with a label stack [LI|BOS] will be forwarded on the clockwise SPME with a label stack [PA1(F)|LE|BOS] and concurrently on the counter-clockwise SPME with a label stack [PA2(B)|LE|BOS].

Assume that the LSP "LI" has egress points at LSR-C & LSR-E. When the packet arrives at LSR-B, LSR-D, and LSR-F, the LSR will forward the data packet to continue along the SPME, e.g. at LSR-D the packet will be forwarded with label stack [PD1(F)|LE|BOS]. But in addition LSR-D will retain a copy of the packet, pop the SPME label and examine the underlying LSP label. Since LSR-D is not an egress point for LSP-LI, the packet will be dropped. At LSR-C the data packet will be forwarded along the SPME (with label stack [PC1(F)|LE|BOS], but when the retained copy is examined (after popping the SPME label) it will determine that the packet is intended for this LSR as an egress point and switch the LSP label forwarding this packet with the label stack [LE|BOS].

If a fault condition is detected, then some of the nodes will cease to receive the packets from the clockwise (working) SPME. These LSR should then begin to switch their selector bridge to accept the data packets from the counter-clockwise SPME (i.e. A-F-E-D-C-B), using a similar logic to that presented in the previous paragraph.

This architecture has the added advantages that there is no need for the ingress node to identify the existence of the misconnectivity, and there is no need for a return path from the egress points to the ingress.

4.  Coordination protocol

The Survivability Framework [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.) indicates that there is a need to coordinate protection switching between the end-points of a protected bidirectional domain. The coordination is necessary for particular cases, in order to maintain the co-routed nature of the bidirectional transport path. The particular cases where this becomes necessary include cases of unidirectional fault detection and use of operator commands.

By using the same mechanisms defined in [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.), for linear protection, to apply for ring protection we are able to gain a consistent solution for this coordination between the end-points of the protection domain. The Protection State Coordination Protocol that is specified in [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.) provides coverage for all the coordination cases, including support for operator commands, e.g. Forced-Switch.

5.  Interconnected rings

The Requirements document [TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) states that the ring protection must support a single ring that may be interconnected to other rings. In addition, traffic that traverses a number of rings within a network of interconnected rings must be protected even if the interconnection nodes and links fail.

When interconnecting rings in a network there are two common interconnection schemes:

• Dual-node interconnect – when the interconnected rings are interconnected by two nodes from each ring (see Figure 8 (Dual-node interconnected rings))
• Single-node interconnect – when the connection between the interconnected rings are through a single node (see Figure 9 (Single-node interconnected rings))

The protection schemes presented in Section 2 (P2P Ring Protection) are capable of protecting each interconnected ring as a separate entity independent of the other rings in the network. This protects the traffic that traverses the entire network, as each ring will continue to transfer the traffic to the interconnection points, and from there to the next ring.

When the interconnection nodes or links fail, there is the need to protect these connection points. Therefore, it should be noted that in the case of single-node interconnect the interconnection node (LSR-A in Figure 9 (Single-node interconnected rings)) is a single-point of failure and such an interconnection scheme should be avoided. In the case of the dual-node interconnect scheme in Figure 8 (Dual-node interconnected rings), the connection point over LSR-A<—>LSR-6 and LSR-F<—>LSR-5 could use basic linear protection as defined in [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.) and [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.) .

                   ____                     ___
                  / LSR\                   /LSR\
                * \__B_/ *                *\_1_/*
               *          *              *       *
              *            *            *         *
          ___*              *___      _*_          * ___
         /LSR\              /LSR\****/LSR\          /LSR\
         \_C_/              \_A_/    \_6_/          \_2_/
           *     Ring #1      *        *   Ring #2    *
           *                  *        *              *
          _*_                _*_      _*_            _*_
         /LSR\              /LSR\    /LSR\          /LSR\
         \_D_/              \_F_/****\_5_/          \_3_/
             *              *           *            *
              *            *             *          *
                *   ____  *               *  ____  *
                  */ LSR\*                 */LSR \*
                   \__E_/                   \__4_/


                       *** physical link

                        ____                ___
                       / LSR\              /LSR\
                     * \__B_/ *           *\_1_/*
                    *          *         *       *
                   *            *       *         *
               ___*              *___  *           * ___
              /LSR\              /LSR\*             /LSR\
              \_C_/              \_A_/              \_2_/
                *     Ring #1      * *    Ring #2     *
                *                  *  *               *
               _*_                _*_  *  ___        _*_
              /LSR\              /LSR\  */LSR\      /LSR\
              \_D_/              \_F_/   \_5_/      \_3_/
                 *              *          *        *
                  *            *           *      *
                    *   ____  *            *___  *
                      */ LSR\*             /LSR\*
                       \__E_/              \_4_/


                            *** physical link

6.  Conclusions and Recommendations

Based on the use of the Path Segment Tunnel construct, defined in [TPFwk] (Bocci, M., Bryant, S., Frost, D., and L. Levrau, “MPLS-TP Framework,” May 2010.) and [OAMFwk] (Niven-Jenkins, B., Allan, D., and I. Busi, “MPLS-TP OAM Framework,” May 2010.), it is possible to define a protection mechanism for MPLS-TP rings that is based on linear protection [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.). This mechanism would be based on 1:1 linear protection for bidirectional or unidirectional p2p data paths, and 1+1 linear protection for unidirectional p2mp paths. It has been shown that this protection architecture and mechanism fulfills the criteria defined in [TPReqs] (Niven-Jenkins, B., Nadeau, T., and C. Pignataro, “Requirements for the Transport Profile of MPLS,” April 2009.) for justification of designing a specific protection mechanism for a ring topology.

It has also been shown that basing the ring protection on the existing linear protection mechanisms defined in [SurvivFwk] (Sprecher, N. and A. Farrel, “MPLS-TP Survivability Framework,” June 2010.) and [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.), the operator has a choice of using either the wrapping or steering methodology for protection of both p2p and p2mp data traffic. In addition, there is no need to define any new coordination protocol to complete this protection, instead depending upon the OAM functionality [outlined in [OAMFwk] (Niven-Jenkins, B., Allan, D., and I. Busi, “MPLS-TP OAM Framework,” May 2010.) and specified in various documents] and the coordination protocol specified for linear protection in [LinProtect] (Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., and Y. Weingarten, “MPLS-TP Linear Protection,” October 2009.).

7.  IANA Considerations

This document makes no request of IANA.

Note to RFC Editor: this section may be removed on publication as an RFC.

8.  Security Considerations

To be added in future version.

9.  Acknowledgements

The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF and the T-MPLS Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS Transport Profile.

10. Informative References

Authors' Addresses