--- 1/draft-ietf-mpls-tp-ring-protection-03.txt 2013-02-25 21:35:46.583708741 +0100 +++ 2/draft-ietf-mpls-tp-ring-protection-04.txt 2013-02-25 21:35:46.635708246 +0100 @@ -1,45 +1,46 @@ Network Working Group Y. Weingarten Internet-Draft Intended status: Informational S. Bryant -Expires: May 9, 2013 Cisco +Expires: August 29, 2013 Cisco D. Ceccarelli D. Caviglia F. Fondelli Ericsson M. Corsi Altran B. Wu X. Dai ZTE Corporation - November 5, 2012 + February 25, 2013 Applicability of MPLS-TP Linear Protection for Ring Topologies - draft-ietf-mpls-tp-ring-protection-03.txt + draft-ietf-mpls-tp-ring-protection-04.txt Abstract - This document presents an applicability of linear protection - mechanisms for 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 limitations of the topology. + 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 + limitations of the topology. - Requirements for MPLS-TP protection and specifically for protection - in ring topologies are discussed in "Requirements of an MPLS - Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) + 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 ring - topologies, discusses how most of the requirements are met, and + 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 requirements. 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. @@ -51,25 +52,25 @@ 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 May 9, 2013. + This Internet-Draft will expire on August 29, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + 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 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 @@ -78,90 +79,91 @@ 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.4. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 2. P2P Ring Protection . . . . . . . . . . . . . . . . . . . . . 7 2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.3. SPME for p2p protection of ring topologies . . . . . . . . 10 + 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.3. Wrapping node protection . . . . . . . . . . . . . . . 14 2.3.4. Wrapping for link and node protection . . . . . . . . 14 2.4. Analysis of p2p protection . . . . . . . . . . . . . . . . 15 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.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 20 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. Informative References . . . . . . . . . . . . . . . . . . . . 26 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 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 requirements [RFC5654] includes a requirement to support - a network that may include sub-networks that constitute a MPLS-TP - ring as defined in the requirements. The requirements document does + The MPLS-TP requirement document [RFC5654] includes a requirement to + support a network that may include sub-networks that constitute an + MPLS-TP ring as defined in the document. However, the document does not identify any protection requirements specific to a ring topology. However, the requirements state that specific protection mechanisms - aimed at ring topologies may be developed if these allow the network - to minimize: + applying to ring topologies may be developed if these allow the + network to minimize: o Number of OAM entities needed to trigger the protection 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 a MPLS-TP ring. + 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. We show that these mechanisms provide protection for all - switching triggers within a reasonable time frame and optimize the + 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. 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 due to their ability to easily support both p2p and p2mp - transport paths. When designing a protection mechanism for a ring + 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 a MPLS-TP capable + 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. 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. In either of these two situations, there is a need to address the following different cases - @@ -174,21 +176,21 @@ 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. The protection domain addressed in this document is limited to the - traffic that is traversing the ring. Traffic on the transport path + 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 the linear protection as defined in [RFC6378]. Requirement R93 regarding the support of interconnected rings and protection of faults in the interconnection nodes and links are for further study. @@ -203,25 +205,25 @@ defined in the MPLS-TP framework documents: o MPLS-TP Framework[RFC5921] o MPLS-TP OAM Framework[RFC6371] o MPLS-TP Survivability Framework[RFC6372] The MPLS-TP Framework document [RFC5921] defines a Sub-Path Maintenance Entity (SPME) construct that can be defined between any - two LSRs of a MPLS-TP LSP. This SPME may be configured as a co- + two LSRs of an MPLS-TP LSP. This SPME may be configured as a co- routed bidirectional path. The SPME is defined to allow management and monitoring of any segment of a transport path. This concept will be used extensively throughout the document to support protection of - the traffic that traverses a MPLS-TP ring. + the traffic that traverses an MPLS-TP ring. 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. It should be noted that the label stack may contain additional @@ -405,68 +407,68 @@ Defect Indication, Alarm reporting. o The process of notifying the ingress node adds to the latency of the protection switching process, after the detection of the fault condition. o 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. SPME for p2p protection of ring topologies +2.3. SPME for p2p protection of a ring topology The SPME concept was introduced by [RFC5921] to support management and monitoring an arbitrary segment of a transport. However, an SPME is essentially a valid LSP that may be used to aggregate all LSP traffic that traverses the sub-path delineated by the SPME. An SPME may be monitored using the OAM mechanisms as described in the MPLS-TP OAM Framework document [RFC6371]. - When defining a MPLS-TP ring as a protection domain, there is a need + When defining an 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 SPMEs is dependent on the type of transport path and protection that is being implemented and will be detailed in the following sub-sections. Based on this architectural configuration for protection of ring topologies, it is possible to limit the number of alternate paths needed to protect the data traversing the ring. In addition, since we will perform all of the OAM functionality on the SPME configured for the traffic, we can minimize the number of OAM sessions needed to monitor the data traffic of the ring - rather than monitoring each individual LSP. - The following figure shows a MPLS-TP ring that is part of a larger + The following figure shows an 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\********/LSR\********/LSR\======> \_B_/########\_A_/########\_F_/ *@ @* *@ @* *@ @* _*@ ___ @*_ /LSR\********/LSR\********/LSR\ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ ===> connected LSP *** physical link ### primary SPME @@@ secondary SPME - Figure 2: A MPLS-TP ring + Figure 2: 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 @@ -882,21 +884,21 @@ 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 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 a MPLS-TP ring as its + 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 the ring at multiple nodes, we can employ a steering mechanism based on 1+1 linear protection [RFC6372]. 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. In order to be able to properly direct the LSP traffic to the proper egress point for that particular LSP, we need to employ context labeling as defined in [RFC5331]. The method for using these labels is expanded upon in section 3.2.1. @@ -1098,32 +1100,32 @@ The Survivability Framework [RFC6372] 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 [RFC6378], for linear - protection, to apply for protection of ring topologies 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 [RFC6378] provides coverage for all the - coordination cases, including support for operator commands, e.g. - Forced-Switch. + protection, to apply for protection of a single ring topology 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 [RFC6378] provides + coverage for all the coordination cases, including support for + operator commands, e.g. Forced-Switch. 5. Conclusions and Recommendations Ring topologies are prevalent in traditional transport networks and will continue to be used for various reasons. Protection for - transport paths that traverse a ring within a MPLS network can be + transport paths that traverse a ring within an MPLS network can be provided by applying an appropriate instance of linear protection, as defined in [RFC6372]. This document has shown that for each of the traditional ring protection architectures there is an application of linear protection that provides efficient coverage, based on the use of the Sub-Path Maintenance Entity (SPME), defined in [RFC5921] and [RFC6371]. For example, o p2p Steering - Configuration of two SPME, from ring ingress to ring egress, and 1:1 linear protection @@ -1176,21 +1178,29 @@ applicability to the information contained in this document follow naturally from the applicability of the mechanism defined in that document. 8. Acknowledgements The authors would like to acknowledge the strong contributions from all the people commenting on this draft and making suggestions for improvements. -9. Informative References +9. References + +9.1. Normative References + + [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and + A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378, + October 2011. + +9.2. Informative References [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, Aug 2008. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., @@ -1199,24 +1209,20 @@ [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "MPLS-TP Framework", RFC 5921, July 2010. [RFC6371] Busi, I. and D. Allan, "MPLS-TP OAM Framework", RFC 6371, Sept 2011. [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability Framework", RFC 6372, Sept 2011. - [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and - A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378, - October 2011. - [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) - Functional Specifications", RFC 2205, September 1997. [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for GMPLS", RFC 4427, March 2006. [G.841] ITU, "Types and characteristics of SDH network protection architectures", ITU-T G.841, October 1998.