--- 1/draft-ietf-mpls-tp-ring-protection-02.txt 2012-11-05 10:14:58.913343198 +0100 +++ 2/draft-ietf-mpls-tp-ring-protection-03.txt 2012-11-05 10:14:58.969342217 +0100 @@ -1,56 +1,57 @@ Network Working Group Y. Weingarten Internet-Draft Intended status: Informational S. Bryant -Expires: October 31, 2012 Cisco - N. Sprecher - Nokia Siemens Networks +Expires: May 9, 2013 Cisco D. Ceccarelli D. Caviglia F. Fondelli Ericsson M. Corsi Altran B. Wu X. Dai ZTE Corporation - April 29, 2012 + November 5, 2012 Applicability of MPLS-TP Linear Protection for Ring Topologies - draft-ietf-mpls-tp-ring-protection-02.txt + draft-ietf-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 - 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, minimizing 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, - specifically those defined in MPLS-TP Linear Protection, without the - need for specification of new constructs or protocols. + 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. + + 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) + 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 + 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. 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 @@ -50,111 +51,113 @@ 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 October 31, 2012. + This Internet-Draft will expire on May 9, 2013. Copyright Notice Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5 - 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 7 + 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. P2P ring protection using SPME . . . . . . . . . . . . . . 10 + 2.3. SPME for p2p protection of ring topologies . . . . . . . . 10 2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11 - 2.3.2. Wrapping with segment based SPME . . . . . . . . . . . 12 - 2.3.3. Wrapping node protection . . . . . . . . . . . . . . . 13 + 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 . . . . . . . . . . . . . . . . 14 - 3. P2MP protection . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.1. Wrapping for p2mp LSP . . . . . . . . . . . . . . . . . . 15 - 3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 17 - 3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 19 - 3.2. Steering for p2mp paths . . . . . . . . . . . . . . . . . 19 - 3.2.1. Context labels . . . . . . . . . . . . . . . . . . . . 20 - 3.2.2. Walkthrough using context labels . . . . . . . . . . . 22 - 4. Coordination protocol . . . . . . . . . . . . . . . . . . . . 23 - 5. Conclusions and Recommendations . . . . . . . . . . . . . . . 24 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 - 9. Informative References . . . . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 + 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 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction - Multi-Protocol Label Switching Transport Profile (MPLS-TP) is being + 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 requirements for MPLS-TP [TPReqs] indicates 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 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 optimize: + 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 + 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: 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 - recovery operation + maintenance operation - o Impact of signaling and routing information exchanged, in presence - of control plane + o Impact of signaling and routing information exchanged during + protection, 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] as summarized - above. + 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. + 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 + criteria set out in [RFC5654], as summarized above. - A related topic in [TPReqs] addresses the required support for + 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 [TPReqs], are used in transport + 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 topology, there is a need to address both - 1. A point-to-point 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. 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 @@ -167,46 +170,58 @@ 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.12 of [RFC4427]. Examples of these commands include + 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 prior to the ring ingress node or beyond the egress nodes may be protected by some other mechanism. -1.2. Terminology and Notation +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. + + In addition, requirement R105 requiring the support of lockout of + specific nodes or spans is only supported as well as it is supported + by the linear protection mechanism. + +1.3. Terminology and Notation The terminology used in this document is based on the terminology defined in the MPLS-TP framework documents: - o MPLS-TP Framework[TPFwk] + o MPLS-TP Framework[RFC5921] - o MPLS-TP OAM Framework[OAMFwk] + o MPLS-TP OAM Framework[RFC6371] - o MPLS-TP Survivability Framework[SurvivFwk] + o MPLS-TP Survivability Framework[RFC6372] - The MPLS-TP Framework document [TPFwk] 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-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 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- + 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. 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 @@ -239,84 +254,94 @@ of the protection scenario. o [PB1(G)|LE] denotes a stack whose top-label is the SPME-1 label for LSR-B to transmit the data packet to LSR-G, the second label is the label that would be used by the egress LSR to continue the packet on the original LSP. o If "LE" were the bottom label in the stack, then the label stack would be shown as [PB1(G)|LE+S]. -1.3. Contributing Authors +1.4. Contributing Authors - Akira Sakurai (NEC), Rolf Winter (NEC) + 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) 2. P2P Ring Protection - Classically there are two protection architecture mechanisms for ring - topologies, based on SDH specifications [G.841], 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. + 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 Wrapping is defined as a local protection architecture. This - mechanism is local to the LSRs that are neighbors to the detected + mechanism is local to the nodes 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 + neighboring node 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. Wrapping behavior is similar to - MPLS-TE FRR as defined in [RFC4090] using either bypass or detour - tunnels. It would be possible to wrap each LSP arounf the failed - links via a detour tunnel using a different label for each LSP or to - wrap all the LSPs using a bypass tunnel and a single label. + the ring, on an alternate data path, until arriving at the node that + is on the opposite side of the fault. When this far-side node also + detects that there is a fault condition on the working path, it can + identify that the data traffic that is arriving on the alternate + (protecting) data path is intended for the "broken" data path. + Therefore, again taking a local decision, can wrap the data back onto + the normal working path until the egress from the ring segment. + + Wrapping behavior is similar to MPLS-TE FRR as defined in [RFC4090] + using either bypass or detour tunnels. Applying this methodology to + MPLS, it is possible to wrap the traffic of each LSP around the + failed links via a detour tunnel using a different label for each LSP + or to wrap all LSPs using a bypass tunnel and a single label. ___ ######## ___ ######## ___ ======>/LSR\********/LSR\***XX***/LSR\ \_B_/@@@@@@@@\_A_/ \_F_/ - *@ #* - *@ #* - *@ #* - _*@ ___ #*_ + *@ #*@ + *@ #*@ + *@ #*@ + _*@ ___ #*@ /LSR\********/LSR\********/LSR\======> \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ ===> connected LSP *** physical link ### working path @@@ wrapped data path Figure 1: Wrapping protection for p2p 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 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. + 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 + 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 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. The following considerations should be taken into account when considering use of wrapping protection: o Detection of loss-of-continuity or mis-connectivity, 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. @@ -328,96 +353,98 @@ 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 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. 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 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 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' + o The resource pre-allocation for all of the alternate-paths could + be problematic [causing massive over subscription of the available + resources]. However, since most of these alternate paths will not + be used simultaneously, there is the possibility of allocating '0' resources and depend on the NMS to allocate the proper resources - around the ring. + around the ring, based on actual traffic usage. - o 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. + o Wrapping also involves a small increase in traffic latency in + delivering the packets, as a result of traversing the entire ring, + during protection. 2.2. Steering The second common scheme for ring protection, steering, takes advantage of the ring topology by defining two paths from the ingress 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). - This mechanism bears similarities to linear 1:1 protection - [SurvivFwk]. 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. + 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 notify the ingress node of the fault condition. This may involve - different OAM functionality described in [OAMFwk], e.g. Remote + different OAM functionality described in [RFC6371], e.g. Remote 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. P2P ring protection using SPME +2.3. SPME for p2p protection of ring topologies - The SPME concept was introduced by [TPFwk] 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 [OAMFwk]. + 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 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 ring protection, 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. + 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 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\======> @@ -428,31 +455,30 @@ _*@ ___ @*_ /LSR\********/LSR\********/LSR\ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ ===> connected LSP *** physical link ### primary SPME @@@ secondary SPME Figure 2: A MPLS-TP ring In all of the following subsections, we use 1:1 linear protection - [SurvivFwk] [LinProtect] 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 primary SPME, then the mechanism described in - [LinProtect] shall be used to coordinate a switch-over of data - traffic to the secondary SPME. + [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 + primary SPME, then the mechanism described in [RFC6378] shall be used + to coordinate a switch-over of data traffic to the secondary SPME. Assuming that the SPME is implemented as an hierarchical LSP, packets that arrive at LSR-B with a label stack [LI] will have the SPME label pushed at LSR-B and the LSP label will be swapped for the label that is expected by the egress LSR (i.e. the packet will arrive at LSR-A with a label stack of [PA1(B)|LE], arrive at LSR-F with [PE1(F)|LE]). 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, outside the ring. This scenario is true for all LSP that are aggregated by this primary SPME. @@ -469,37 +495,38 @@ 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 protection 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, protection SPME. This protection mechanism is identical to application of 1:1 linear - protection[SurvivFwk] [LinProtect] 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 + protection[RFC6372] [RFC6378] 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 protection SPME to transmit all LSP data packets. The protection SPME will continue to transmit the data packets until - the stable recovery of the fault condition. Upon recovery, the + 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 - [LinProtect]. + [RFC6378]. -2.3.2. Wrapping with segment based SPME +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 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. @@ -528,29 +555,29 @@ redirected onto the original LSP, quite likely over the neighboring SPME. Following the progression of the label stack through this switching operation (for a LSP that enters the ring at LSR B and exits the ring at LSR E): 1. The data packet arrives at LSR-A with label stack [L1+S] (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)|LSE+S] (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). + 2. In the normal case (no protection switching), LSR-A forwards the + packet with label stack [PA1(F)|LSE+S] (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(B)|LSE+S] (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). This will be transmitted along the + 3. When protection switching is in-effect, LSR-A forwards the packet + with label stack [PA2(B)|LSE+S] (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). This will be transmitted along the secondary SPME until LSR-E forwards it to LSR-F with label stack [PE2(F)|LSE+S]. 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 @@ -572,21 +599,21 @@ _*@ ___ _*# /LSR\********/LSR\********/LSR\ \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/ *** physical link ### primary SPME @@@ secondary SPME Figure 4: Node-protection SPMEs The protection mechanism would work similarly - based on 1:1 linear - protection [SurvivFwk], triggered by OAM functions on both SPMEs, and + 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 @@ -617,21 +644,21 @@ $$$ secondary node#2 SPME +++ secondary segment SPME Figure 5: 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 steeing SPME + 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 either as described in Section 2.3.2 and Section 2.3.3 = O(2N) [however, the operator must decide a priori on whether to protect for link failures or node failures at each point] o Number of OAM sessions at each node - for steering = O(2N), for SPME wrapping = 3 o Bandwidth requirements - for SPME-based steering: single bandwidth @@ -648,43 +675,65 @@ as well as, violating the co-routedness of the protected traffic. Based on this analysis, using steering as described in Section 2.3.1 would be the recommended protection mechanism due to its simplicity, even though it may involve the use of additional resources (i.e. SPME) for monitorng the traffic. It should be pointed out that the number of SPME involved in this protection could be reduced by eliminating SPME between pairs of LSR that are not used as an ingress and egress pair. +2.4.1. Recommendations for protection of p2p paths traversing a ring + + Based on the analysis presented, while applying linear protection to + effect Wrapping protection to a ring topology is possible as + demonstrated, this does have certain limitations in addressing some + of the required behavior. The limitations include: + + o Need to a-priori configure the protection for link or node + protection + + o Increased number of SPME that need to be defined + + o Difficulty in addressing cases of multiple failures in the ring + + Application of linear protection, based on the use of SPME within the + ring, to implement a Steering methodology to protect a ring topology + is rather straight forward, overcomes the limitations listed above, + and scales very well. For this and other reasons listed previously, + the authors recommend the use of Steering to provide protection of a + ring topology when using the mechanisms described in this document + for protection of p2p paths that traverse the ring. + 3. P2MP protection - [TPReqs] requires that ring protection must provide protection for + [RFC5654] 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 + 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. Referring to Figure 6, it is possible to identify the protected (working) LSP (A-B-[C]-[D]-E-[F]) and one possible backup @@ -785,26 +834,26 @@ 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 pre-provisioned counterclockwise, each of them may also have reserved bandwidth M. - These LSPs share the same bandwidth in a SE (Shared Explicit) [RSVP] - style. + These LSPs share the same bandwidth in a SE (Shared Explicit) + [RFC2205] 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]. However, it should be noted that [TPReqs] + extra traffic [RFC4427]. However, it should be noted that [RFC5654] 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 @@ -836,42 +885,42 @@ 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 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 [SurvivFwk]. We can configure two p2mp + 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 in section 3.2.1. + using these labels is expanded upon in section 3.2.1. For every LSP that enters the ring at a given node the traffic will be sent through both of these SPME, each with its own context label and the context-specific label for the particular LSP. The egress nodes should select the traffic that is arriving on the working SPME. - In case there is a failure condition, the egress nodes should select - the traffic from whichever of the SPME that is 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 switch its selector to read the data packets - from the protection SPME. + When a failure condition is identified, the egress nodes should + 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. ^ ^ ^ _|_ _|_ _|_ ----->/LSR\********/LSR\********/LSR\ \_A_/========\_B_/========\_C_/ +* <+++++++++*|| +* +*|| +* +*|| +* +*|| +*_ ++++++++ ___ +++++++++*|| @@ -901,97 +950,102 @@ 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. 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 ring protection 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. + 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 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. - If we apply the 1+1 linear protection scheme outlined above for an - 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 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 | + 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 + 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, 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 protection SPME. At the ingress point the packet - will be transmitted on both the working SPME and the protection SPME. - Continuing the example, if there is a failure on the link between - LSR-C and LSR-D then LSR-A will transmit one copy of the data to - LSR-B with stack [CW | WL(A-B)] and one copy to LSR-F with stack [CP - | PL(A-F)]. The packet will arrive at LSR-C from the working SPME - and egress from the ring. LSR-E will receive the packet from the - protection SPME with stack [CP | PL(F-E)] and the context-sensitive - label PL(F-E) will instruct the forwarding function to send a copy - out of the ring with label LE(E) and a second copy to LSR-D with - stack [CP | PL(E-D)]. In this way each of the egress points receive - the packet from the SPME that is available at that point. + 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 + the clockwise (working) SPME. These LSR should then begin to switch + their "selector bridge" and accept the data packets from the + protection (counter-clockwise) SPME. At the ingress point, LSR-A, + all data packets will have been transmitted on both the working SPME + and the protection SPME. Continuing the example, LSR-A will transmit + one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy + to LSR-F with stack [CP | PL(A-F)]. The packet will arrive at LSR-C + from the working SPME and egress from the ring. LSR-E will receive + the packet from the protection SPME with stack [CP | PL(F-E)] and the + context-sensitive label PL(F-E) will instruct the forwarding function + to send a copy out of the ring with label LE(E) and a second copy to + LSR-D with stack [CP | PL(E-D)]. In this way each of the egress + points receives the packet from the SPME that is available at that + point. 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 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. - ^ ^ ^ ^ ^ - _|_ xxxxxxxxx_|_ xxxxxxxxxX|_xxxxxxxxxX|_ xxxxxxxx_|_ + ^ ^ ^ ^ + ^ ^ ^ ^ + ___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_ xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ \_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/ *+ <+++++++++ +++++++ ++++++++*||x *+ +*||x *+ +*||x *+ +*||x _*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x /LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\ \_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/ - | | | |Xxxxxxxxxx | - V V V V V + + + + +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 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- @@ -1035,47 +1089,47 @@ will be forwarded along both SPME according to the configured behavior in the context tables. However, the egress points at LSR D, E, & H, will all be configured with a selector bridge to only use the input from the working SPME. If any of these egress points identify that there is a connection fault on the working SPME, then the selector bridge will cause the LSR to read the input from the protection SPME. 4. Coordination protocol - The Survivability Framework [SurvivFwk] indicates that there is a - need to coordinate protection switching between the end-points of a + 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 [LinProtect], 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] provides coverage for all the + 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. 5. Conclusions and Recommendations - Ring topologies are prevelant in traditional transport networks and + 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 provided by applying an appropriate instance of linear protection, as - defined in [SurvivFwk]. This document has shown that for each of the + 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 [TPFwk] and - [OAMFwk]. For example, + 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 o p2p Wrapping for link protection - Configuration of two SPME, one for the protected link and the second using the long route between the two neighboring nodes, and 1:1 linear protection. o p2p Wrapping for node protection - Configuration of two SPME, one between the two neighbors of the protected node and the second @@ -1084,86 +1138,86 @@ o p2mp Wrapping - it is possible to optimize the performance of the wrapping by configuring the proper protection path to egress the data at the proper branching nodes. o p2mp Steering - by combining 1+1 linear protection and configuration of the SPME based on context-sensitive labeling of the protection path. It has been shown that this set of protection architecture and - mechanisms are optimized based on the criteria defined in [TPReqs] + mechanisms are optimized based on the criteria defined in [RFC5654] for justification of designing a specific protection mechanism for a - ring topology. This thereby aleviates the necessity to create a new - mechanism or protocol to support the protection of ring topologies. + ring topology. - By basing the simple p2p ring protection on basic 1:1 linear - protection there is a very efficient way of implementing Steering - protection for the sections of a transport path that traverses the - ring. Steering should be the preferred mechanism for ring protection - since it reduces the extra bandwidth required when traffic doubles - through wrapped protection, and the ability to protect both against - link and node failures without complicating the fault detection or - the need to configure multiple protection paths. While this is true, - the possiblity remains to support either mechanism while depending - upon the OAM functionality [outlined in [OAMFwk] and specified in - various documents] and the coordination protocol specified for linear - protection in [LinProtect]. + Protection of traffic over a ring topology based on the Steering + architecture using basic 1:1 linear protection is a very efficient + implementation for sections of a p2p transport path that traverses a + ring. Steering should be the preferred mechanism for p2p protection + in a ring topology since it reduces the extra bandwidth required when + traffic doubles through wrapped protection, and the ability to + protect both against link and node failures without complicating the + fault detection or the need to configure multiple protection paths. + While this is true, the possiblity remains to support either + mechanism while depending upon the OAM functionality [outlined in + [RFC6371] and specified in various documents] and the coordination + protocol specified for linear protection in [RFC6378]. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations - To be added in future version. + This document does not add any security risks to the network. Any + security considerations are defined in [RFC6378] and their + 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 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. + 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 [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. - [TPReqs] Niven-Jenkins, B., Nadeau, T., and C. Pignataro, - "Requirements for the Transport Profile of MPLS", - RFC 5654, April 2009. + [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., + and S. Ueno, "Requirements for the Transport Profile of + MPLS", RFC 5654, Sept 2009. - [TPFwk] Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP - Framework", RFC 5921, May 2010. + [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. + Berger, "MPLS-TP Framework", RFC 5921, July 2010. - [OAMFwk] Niven-Jenkins, B., Allan, D., and I. Busi, "MPLS-TP OAM - Framework", RFC 6371, May 2010. + [RFC6371] Busi, I. and D. Allan, "MPLS-TP OAM Framework", RFC 6371, + Sept 2011. - [SurvivFwk] - Sprecher, N. and A. Farrel, "MPLS-TP Survivability - Framework", RFC 6372, June 2010. + [RFC6372] Sprecher, N. and A. Farrel, "MPLS-TP Survivability + Framework", RFC 6372, Sept 2011. - [LinProtect] - Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A., - and Y. Weingarten, "MPLS-TP Linear Protection", RFC 6378, - October 2009. + [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and + A. Fulignoli, "MPLS-TP Linear Protection", RFC 6378, + October 2011. - [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + [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. Authors' Addresses @@ -1174,28 +1228,20 @@ Israel Phone: Email: wyaacov@gmail.com Stewart Bryant Cisco United Kingdom Email: stbryant@cisco.com - Nurit Sprecher - Nokia Siemens Networks - 3 Hanagar St. Neve Ne'eman B - Hod Hasharon, 45241 - Israel - - Email: nurit.sprecher@nsn.com - Danielle Ceccarelli Ericsson Via A. Negrone 1/A Genova, Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Diego Caviglia Ericsson