--- 1/draft-ietf-mpls-tp-ring-protection-04.txt 2013-04-05 01:53:57.728041791 +0200 +++ 2/draft-ietf-mpls-tp-ring-protection-05.txt 2013-04-05 01:53:57.788040859 +0200 @@ -1,38 +1,39 @@ Network Working Group Y. Weingarten Internet-Draft Intended status: Informational S. Bryant -Expires: August 29, 2013 Cisco +Expires: October 6, 2013 Cisco D. Ceccarelli D. Caviglia F. Fondelli Ericsson M. Corsi Altran B. Wu X. Dai ZTE Corporation - February 25, 2013 + April 4, 2013 Applicability of MPLS-TP Linear Protection for Ring Topologies - draft-ietf-mpls-tp-ring-protection-04.txt + draft-ietf-mpls-tp-ring-protection-05.txt Abstract This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to Multi-Protocol Label - Switching Transport Profile (MPLS-TP) in ring topologies. Protection - on rings offers a number of opportunities for optimization as the - protection choices are starkly limited (all traffic traveling one way - around a ring can only be switched to travel the other way on the - ring), but also suffers from some complications caused by the + Switching Transport Profile (MPLS-TP) in ring topologies. This + document does not propose any new mechanisms or protocols. + Protection on rings offers a number of opportunities for optimization + as the protection choices are starkly limited (all traffic traveling + one way around a ring can only be switched to travel the other way on + the ring), but also suffers from some complications caused by the limitations of the topology. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document shows how MPLS-TP linear protection as defined in RFC 6378 can be applied to single ring topologies, discusses how most of the requirements are met, and describes scenarios in which the function provided by applying linear protection in a ring topology falls short of some of the @@ -52,21 +54,21 @@ 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 August 29, 2013. + This Internet-Draft will expire on October 6, 2013. Copyright Notice Copyright (c) 2013 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 @@ -74,49 +76,49 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope of the document . . . . . . . . . . . . . . . . . . 5 - 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5 + 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 6 1.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3. SPME for p2p protection of a ring topology . . . . . . . . 10 - 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11 - 2.3.2. Wrapping link protection with segment based SPME . . . 12 + 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 12 + 2.3.2. Wrapping link protection with segment based SPME . . . 13 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 14 - 2.3.4. Wrapping for link and node protection . . . . . . . . 14 - 2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15 + 2.3.4. Wrapping for link and node protection . . . . . . . . 15 + 2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 16 2.4.1. Recommendations for protection of p2p paths traversing a ring . . . . . . . . . . . . . . . . . . 16 - 3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 16 - 3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 16 - 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 18 + 3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 17 + 3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 17 + 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20 - 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 20 + 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 21 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 21 3.2.2. Walkthrough using context labels . . . . . . . . . . . 23 - 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 24 - 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 25 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 + 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 25 + 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 1. Introduction Multi-Protocol Label Switching Transport Profile (MPLS-TP) has been 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 MPLS-TP requirement document [RFC5654] includes a requirement to @@ -132,62 +134,67 @@ o Number of elements of recovery needed o Number of labels required o Number of control and management plane transactions during a maintenance operation o Impact of signaling and routing information exchanged during protection, in presence of control plane - This document proposes a set of basic mechanisms that could be used - for the protection of the data flows that traverse an MPLS-TP ring. - These mechanisms are based on existing MPLS and MPLS-TP protection - mechanisms. These mechanisms provide data flow protection due to any - switching trigger within a reasonable time frame and optimize the - criteria set out in [RFC5654], as summarized above. + This document describes how applying a set of basic MPLS-TP linear + protection mechanisms defined in [RFC6378] can be used to provide + protection of the data flows that traverse an MPLS-TP ring. These + mechanisms provide data flow protection due to any switching trigger + within a reasonable time frame and optimize the criteria set out in + [RFC5654], as summarized above. This doxument does not define any + new protocol mechanisms or procedures. A related topic in [RFC5654] addresses the required support for interconnected rings. This topic involves various scenarios that require further study and will be addressed in a separate document, based on the principles outlined in this document. 1.1. Problem statement Ring topologies, as defined in [RFC5654], are used in transport networks. When designing a protection mechanism for a single ring topology, there is a need to address both - - 1. A point-to-point transport path that enters an MPLS-TP capable - ring at one node, the ingress node, and exits the ring at a - single egress node possibly continuing beyond the ring. + 1. A point-to-point transport path that either originates at or + enters an 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. Where the ring is being used as a branching point for a point-to- - multipoint transport path, 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. + multipoint transport path, i.e. the transport path originates at + or enters the MPLS-TP capable ring at the ingress node and exits + through a number of egress nodes, possibly continuing beyond the + ring. In either of these two situations, there is a 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. A - description of the different operator commands is found in - Section 4.13 of [RFC4427]. Examples of these commands include - Manual Switch, Forced Switch, or Clear operations. + 3. An operator command that changes the operational state of a node + or a link, or specifically triggers a protection actionis issued + to a specific ring node. A description of the different operator + commands is found in Section 4.13 of [RFC4427]. 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 traverses on 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. Scope of the document This document addresses the requirements that appear in Section 2.5.6.1 of [RFC5654] on Ring Protection based on the application of @@ -267,20 +274,22 @@ The authors would like to acknowledge the following individuals that contributed their insights and advice to this work: Nurit Sprecher (NSN) Akira Sakurai (NEC) Rolf Winter (NEC) + Eric Osborne (Cisco) + 2. P2P Ring Protection There are two protection architecture mechanisms, that have historically been applied to ring topologies, based on SDH specifications [G.841], and have been proposed in various forums to perform recovery of a topological ring network - "Wrapping" and "Steering". The following sub-sections examine these two mechanisms, as applied to an MPLS transport network. 2.1. Wrapping @@ -316,24 +325,24 @@ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ ===> connected LSP *** physical link ### working path @@@ wrapped data path Figure 1: Wrapping protection for p2p path Consider the LSP that is shown in Figure 1 that enters the ring of LSRs at LSR-B and exits at LSR-E. The normal working path LSP follows through LSRs B-A-F-E. If a fault is detected on the link - A<-->F, then the wrapping mechanism decides that LSR-A would wrap the + 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 + 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 of the switchover to the protection path would be needed to maintain the traffic on a co-routed bidirectional LSP even in cases of a unidirectional fault condition. @@ -349,22 +358,22 @@ dependent upon this decision. o 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. o 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 + 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 bandwidth needed for this protection. o 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 encountered on the working path. 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. o The resource pre-allocation for all of the alternate-paths could @@ -385,20 +394,35 @@ point (to the ring) to the egress point going in opposite directions around the ring. This is illustrated in Figure 2, where if we assume that the traffic needs to enter the ring from node B and exit through node F, we could define a primary path through nodes B-A-F, and an alternate path through the nodes B-C-D-E-F. In steering the switching is always performed by the ingress node (node B in Figure 2). If a fault condition is detected anywhere 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). + ___ ___ ___ + ======>/LSR\********/LSR\********/LSR\======> + \_B_/########\_A_/########\_F_/ + *@ @* + *@ @* + *@ @* + _*@ ___ @*_ + /LSR\********/LSR\********/LSR\ + \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ + + ===> connected LSP *** physical link + ### working path @@@ protection path + + Figure 2: Steering protection in an MPLS-TP ring + This mechanism bears similarities to linear 1:1 protection [RFC6372]. The two paths around the ring act as the working and protection paths. There is need to communicate to the ingress node the need to switch over to the protection 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: o Steering relies on a failure detection method that is able to @@ -454,21 +478,21 @@ *@ @* *@ @* *@ @* _*@ ___ @*_ /LSR\********/LSR\********/LSR\ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ ===> connected LSP *** physical link ### primary SPME @@@ secondary SPME - Figure 2: An MPLS-TP ring + Figure 3: An MPLS-TP ring In all of the following subsections, we use 1:1 linear protection [RFC6372] [RFC6378] 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 applying OAM functionality over both the primary and the secondary SPME to detect signal fault conditions on either path. If a signal fault is detected on the @@ -512,47 +536,48 @@ all LSP data packets. The protection SPME will continue to transmit the data packets until the stable recovery of the fault condition. Upon recovery, i.e. the fault condition has cleared and the network is stabilized, 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 + [RFC6378]. 2.3.2. Wrapping link protection 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 we + entire ring (except the link that connects the LSRs). In Figure 4 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\********/LSR\********/LSR\ \_B_/@@@@@@@@\_A_/########\_F_/ *@ *@ *@ *@ *@ *@ _*@ ___ _*@ /LSR\********/LSR\********/LSR\ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ *** physical link ### primary SPME @@@ secondary SPME - Figure 3: Segment SPMEs + Figure 4: Segment SPMEs 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. @@ -581,78 +606,92 @@ 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), and the secondary SPME would be + and LSR-E through LSR-F in Figure 5), and the secondary SPME would be configured between these same nodes, going around the ring (see - secondary SPME in Figure 4). + secondary SPME in Figure 5). ___ ___ ___ /LSR\********/LSR\********/LSR\ \_B_/@@@@@@@@\_A_/########\_F_/ *@ *# *@ *# *@ *# _*@ ___ _*# /LSR\********/LSR\********/LSR\ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ *** physical link ### primary SPME @@@ secondary SPME - Figure 4: Node-protection SPMEs + Figure 5: Node-protection SPMEs The protection mechanism would work similarly - based on 1:1 linear protection [RFC6372], 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 Section 2.3.2 and Section 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 would be possible to configure extra SPME to protect both for link and node failures, arriving at a configuration of the ring that is - shown in Figure 5. Choosing the SPME to use for the wrapping would, - however, then involve considerable effort and could result in the - protected traffic not sharing the same protection path in both - directions. + shown in Figure 6. Here there are three protection SPME configured: + + o Secondary node#1 would be used to divert traffic as a result of an + indication that LSR-F is not available, it redirects traffic to be + transmitted between LSR-A and LSR-E. + + o Secondary node#2 would be used to divert traffic as a result of an + indication that LSR-A is not available, it redirects traffic to be + transmitted between LSR-F and LSR-B. + + o Secondary segment would be used to divert traffic as a result of + an indication that the segment between LSR-A and LSR-F is not + available, it redirects traffic to be transmitted between LSR-A + and LSR-F on the long circuit of the ring. + + Choosing the SPME to use for the wrapping would, however, then + involve considerable effort and could result in the protected traffic + not sharing the same protection path in both directions. ___ ++++++++ ___ ___ /LSR\********/LSR\********/LSR\ \_B_/@@@@@@@@\_A_/########\_F_/ $+*@ +*$ $+*@ +*$ $+*@ +*$ $+*@ ++++++++ ___ ++++++++ +*$ /LSR\********/LSR\********/LSR\ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ $$$$$$$$ $$$$$$$$ *** physical link ### primary SPME @@@ secondary node#1 SPME $$$ secondary node#2 SPME +++ secondary segment SPME - Figure 5: Segment & Node protection SPMEs + Figure 6: Segment & Node protection SPMEs 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, assumed to be not more than 16): o Number of SPME that need to be configured - for steering SPME protection (Section 2.3.1) = O(2N^2) [two SPME from each ingress LSR to each other node in the ring], for wrapping based on SPME @@ -723,31 +762,30 @@ 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 Multipoint Wrapping (ROM-Wrapping), behaves much the same as classical wrapping. - There is one difference - rather than configuring the protection 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 protection p2mp LSP from the - upstream (with respect to the failure) node and all egress nodes (for - the particular LSP) downstream from the failure. + However, ROM-Wrapping configures protection p2mp LSP, relative to + each node that is considered a failure risk, from the upstream node + and all egress nodes (for the particular LSP) downstream from the + failure risk. - Referring to Figure 6, 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 + Referring to Figure 7, it is possible to identify the protected + (working) LSP (A-B-{C}-{D}-E-{F}) and one possible backup + (protection) LSP (note:the egress nodes are indicated by the curly + braces). 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_/ @@ -757,37 +795,37 @@ @ * * @_* ___ __* /LSR\*************/LSR\**************/LSR\ \_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/ @ @ @ @ V V *** working LSP @@@ protection LSP - Figure 6: P2MP ROM Wrapping + Figure 7: P2MP ROM Wrapping 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] + Protected LSP: A->B->{C}->{D}->E->{F} - ---- LINK/NODE PROTECTION---- + -- LINK/NODE PROTECTION -- - A's Backup: A->[F]->E->[D]->[C] - B's Backup: B->A->[F]->E->[D]->[C] - C's Backup: C->B->A->[F]->E->[D] - D's Backup: D->C->B->A->[F] - E's Backup: E->D->C->B->A->[F] + A's Backup: A->{F}->E->{D}->{C} + B's Backup: B->A->{F}->E->{D}->{C} + C's Backup: C->B->A->{F}->E->{D} + D's Backup: D->C->B->A->{F} + E's Backup: E->D->C->B->A->{F} 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 @@ -805,34 +843,34 @@ 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 up-to 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, where a failure + traffic. Referring to the example shown in Figure 7, 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: - A-B B-A-F-E-D-C [C]-[D]-E-[F] + A-B B-A-F-E-D-C {C}-{D}-E-{F} "Upstream" segment backup path "Downstream" segment with respect to the with respect to the failure failure ROM Wrapping: - A-B B-A-[F]-E-[D]-[C] .. + A-B B-A-{F}-E-{D}-{C} .. "Upstream" segment backup path with respect to the failure 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 @@ -852,21 +890,21 @@ 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. The following table lists the bandwidth utilization on + Figure 7. 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). +----------+----------+--------------+ | | Wrapping | ROM-Wrapping | +----------+----------+--------------+ | Link A-B | CW+CCW | CW+CCW | | Link A-F | CCW | CCW | | Link F-E | CW+CCW | CCW | | Link E-D | CW+CCW | CCW | @@ -875,21 +913,21 @@ 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. The Wrapping mechanism is not able to recover + C-D shown in Figure 7. 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 When protecting p2mp traffic that uses an MPLS-TP ring as its branching point, i.e. it enters the ring at a head-end node and exits @@ -910,81 +948,81 @@ select the traffic from whichever of the two SPME whose traffic arrives at that node, i.e. since one of the two (presumably the working SPME) will be blocked by the failure. In this way, all egress nodes are able to receive the data traffic. While each node detects that there is connectivity from the ingress point, it continues to select the data that is coming from the working SPME. If a particular node stops receiving the connectivity messages from the working SPME, it identifies that it must select to read the data packets from the protection SPME. +3.2.1. Context labels + + Figure 8 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 protection SPME. + ^ ^ ^ _|_ _|_ _|_ ----->/LSR\********/LSR\********/LSR\ \_A_/========\_B_/========\_C_/ +* <+++++++++*|| +* +*|| +* +*|| +* +*|| +*_ ++++++++ ___ +++++++++*|| /LSR\********/LSR\********/LSR\ \_F_/<=======\_E_/========\_D_/ | | | V V V ---> connected LSP *** physical link === working SPME +++ protection SPME - Figure 7: P2MP SPMEs - -3.2.1. Context labels - - Figure 7 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 protection SPME. + Figure 8: P2MP SPMEs [RFC5331] defines the concept of context labels. A context- identifying label defines a context label space that is used to interpret the context-specific labels (found directly below the context- identifying label) for a specific tunnel. The SPME label is a context- identifying label. This means that at each hop the node that receives the SPME label uses it to point not directly to a - forwarding table, but to a LIB. As a node receives an SPME label it - examines it, discovers that it is a context label, pops off the SPME - label, and looks up the next label down in the stack in the LIB - indicated by the context label. + forwarding table, but to a Label Information Base (LIB). As a node + receives an SPME label it examines it, discovers that it is a context + label, pops off the SPME label, and looks up the next label down in + the stack in the LIB indicated by the context label. The label below this context-identifying label should be used by the forwarding function of the node to decide the actions taken for this packet. In MPLS-TP protection of ring topologies there are two context LIBs. One is the context LIB for the working SPME and the other is the context LIB for the P-SPME. All context LIBs have a behavior defined for the e2e LSP label but the behavior at each node may be different in the context of each SPME. - For example, using the ring that is shown in Figure 7, if the working + For example, using the ring that is shown in Figure 8, if the working SPME is configured to have a context-identifying label of CW at each node on the ring and the protection SPME is configured to have a context-identifying label of CP at each node. For the specific LSP we will designate the context-specific label used on the working SPME as WL(x-y) to be the label used as node-x to forward the packet to node-y. Similarly, for the context-specific labels on the protection SPME would be designated PL(x-y). An explicit example of label values appears in the next sub-section. Applying 1+1 linear protection, as outlined above, for a p2mp LSP that enters the ring at LSR-A and has egress points from the ring at - LSR-C and LSR-E using the two SPME shown in Figure 7 then a packet + LSR-C and LSR-E using the two SPME shown in Figure 8 then a packet that arrives at LSR-A with a label stack [LI+S] will be forwarded on the working SPME with a label stack [CW | WL(A-B)]. The packet should then be forwarded to LSR-C arriving with a label [CW | WL(B-C)], where WL(B-C) should instruct the forwarding function to egress the packet with [LE(C)] and forward a copy to LSR-D with label stack [CW | WL(C-D)]. If a fault condition is detected, for example on the link C-D, then the nodes that are beyond the fault point, in this example nodes LSR-D, LSR-E, and LSR-F, will cease to receive the data packets from @@ -1005,21 +1043,21 @@ This architecture has the added advantages that there is no need for the ingress node to identify the existence of the mis-connectivity, and there is no need for a return path from the egress points to the ingress. 3.2.2. Walkthrough using context labels In order to better demonstrate the use of the context labels we present a walkthrough of an example application of the p2mp - protection presented in this section. Referring to Figure 8, there + protection presented in this section. Referring to Figure 9, there is a p2mp LSP that traverses the ring, entering the ring at LSR-B and branching off at LSR-D, LSR-E, and LSR-H and does not continue beyond LSR-H. For purposes of protection two p2mp unidirectional SPME are configured on the ring starting from LSR-B. One of the SPME, the working SPME, is configured with egress points at each of the LSR - C, D, E, F, G, H, J, K, A. The second SPME, the protection SPME, is configured with egress points at each of the LSR - A, K, J, H, G, F, E, D, C. ^ ^ ^ ^ @@ -1035,21 +1073,21 @@ /LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ \_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/ + + + +Xxxxxxxxxx + v v v v v v v v v v xxx p2mp LSP (X LSP egress) *** physical link === working SPME +++ protection SPME +>> protection SPME egress - Figure 8: P2MP SPMEs + Figure 9: P2MP SPMEs For this example we suppose that the LSP traffic enters the ring at LSR-B with the label stack [99], leaves the ring at LSR-D with stack [199], at LSR-E with stack [299], and LSR-H with stack [399]. While it is possible for the context-identifying label for the SPME be configured as a different value at each LSR, for the sake of this example we will suppose a configuration of 200 as the context- identifying label for the working SPME at each of the LSR in the ring, and 400 as the context-identifying label for the protection