MPLS Working Group Tae-sik Cheung Internet Draft Jeong-dong Ryoo Intended status: Standards Track ETRI Created: October 25, 2010 Expires: April 25, 2011 MPLS-TP Shared Mesh Protection draft-cheung-mpls-tp-mesh-protection-02.txt Abstract This document describes a mechanism to address the requirement for protection of Label Switched Paths (LSPs) in an MPLS Transport Profile (MPLS-TP) mesh topology. The shared mesh protection mechanism enables multiple protection paths within a shared mesh protection domain to share protection resources for the protection of working paths by coordinating protection switching operations according to the priority assigned to each end-to-end linear protection domain. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 25, 2011. Cheung, et al. Expires April 25 2011 [Page 1] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction.................................................. 3 2. Conventions used in this document............................. 4 2.1. Acronyms................................................. 4 2.2. Definitions and Terminology.............................. 5 3. Shared Mesh Protection........................................ 5 3.1. Protection Switching Priority............................ 6 3.2. Shared Start and End Nodes............................... 6 3.3. Bridge and Selector Models............................... 8 3.4. Shared Mesh Protection Planning.......................... 9 3.5. Shared Mesh Protection Switching......................... 9 3.5.1. Protection Switching Event.............................10 3.5.2. Protection Locking.....................................11 4. Protocol......................................................11 4.1. PDU Format...............................................11 4.1.1. Protection Switching Event Message.....................12 4.1.2. Protection Locking Message.............................12 4.2. Message Transmission.....................................13 5. Operation of Shared Mesh Protection...........................13 6. Manageability Considerations..................................16 7. Security Considerations.......................................16 8. IANA Considerations...........................................16 9. References....................................................16 9.1. Normative References.....................................16 9.2. Informative References...................................16 Cheung, et al. Expires April 25 2011 [Page 2] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 1. Introduction The MPLS Transport Profile (MPLS-TP) is a packet transport technology based on a profile of the MPLS and Pseudowires (PW) [RFC3031], [RFC3985], and [RFC5085]. MPLS-TP is the application of MPLS to the construction of packet-switched paths that are analogous to traditional circuit-switched technologies. Requirements for MPLS- TP are specified in [RFC5654]. An important feature of a transport network is its survivability function and the ability to maintain or recover traffic following a network failure or attack. According to Requirement 56 of [RFC5654], MPLS-TP must provide protection and restoration mechanisms, and it must also be possible to require protection of 100% of the traffic on the protected path (Requirement 58). 1+1 and 1:1 protection can meet these requirements by reserving the equivalent amount of network resources for the protection paths as is used by the normal traffic to be protected. While those dedicated protection mechanisms provide very good protection capabilities, they are resource inefficient and will increase overall network resource consumption. Deploying 1+1 and 1:1 protection mechanisms for all services that require resiliency, dramatically increases network costs. [RFC5654] also establishes that MPLS-TP should support shared protection (Requirement 68). 1:n end-to-end protection uses one protection path to protect n working paths. This improves overall network utilization, but the resource (bandwidth) allocated to a protection path is typically not sufficient to protect multiple and simultaneous failures on different working paths. If multiple working paths are required to be switched to a protection path concurrently, the path with the highest priority should be protected first as described in [I-D.ietf-mpls-tp-survive-fwk]. In 1+1 and 1:1 protection, the end nodes of the working path must be the same as those of the protection path. The same applies in 1:n protection where all pairs of end nodes of the n working paths are the same, and the protection path must also have the same end nodes. In the event that the MPLS-TP network scales up, the number of Label Switched Paths (LSPs) having different end nodes will also increase. The network utilization benefit for sharing protection resources among multiple protected domains for such LSPs will increase accordingly. Requirement 68 of [RFC5654] specifies that MPLS-TP should support 1:n shared mesh recovery, and Requirement 69 states that MPLS-TP must support sharing of protection resources. It may be possible that some working paths are sufficiently disjoint and would be unlikely to be simultaneously affected by a single network failure. Typically, such a scenario is hard to track in real network environments where new services are often added and removed. Cheung, et al. Expires April 25 2011 [Page 3] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 In mesh protection, network resources may be shared to provide protection for working paths that do not share the same end nodes at the edge of a protection domain. This form of protection can make very efficient use of network resources, but requires careful synchronization to ensure that only one set of traffic is switched to the protection resources at any one time. [RFC4428] defines two shared mesh recovery schemes named (1:1)^n and (M:N)^n. (1:1)^n recovery scheme is a simple case of (M:N)^n recovery scheme. In (1:1)^n protection, n working paths are protected by n dedicated protection paths while sharing the same protection bandwidth. The protection bandwidth can be optimized to allow only one of the n working paths to be protected at the same time. In this case, it achieves same amount of network utilization with 1:n protection. (1:1)^n protection defined in [RFC4428] differs with that defined in [G.808.1] in that the former allows each n pairs of working and protection paths to have different end nodes while the latter applies to the case where all pairs have same end nodes. This document defines a shared mesh protection mechanism based on the concept of (1:1)^n recovery scheme defined in [RFC4428] and a coordination to share protection resource based on the protection switching priority assigned to each pair of working and protection paths. Each working path is protected by its own end-to-end linear protection protocol. 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2.1. Acronyms This document uses the following acronyms: LoP Lockout of Protection LSP Label Switched Path MIP Maintenance Entity Group Intermediate Point MPLS-TP MPLS Transport Profile P2MP Point-to-multipoint P2P Point-to-point PW Pseudowire SEN Shared End Node SSN Shared Start Node Cheung, et al. Expires April 25 2011 [Page 4] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 2.2. Definitions and Terminology This document defines two protection domains as follows: o End-to-end linear protection domain: A protection domain as defined in [I-D.ietf-mpls-tp-survive-fwk] for protecting a P2P or P2MP LSP. It consists of two or more end nodes at the boundary of the domain and a working path and a number of protection paths between the end nodes. An end-to-end linear protection switching protocol runs within the domain. o Shared mesh protection domain: A protection domain for protecting a number of P2P or P2MP LSPs. It consists of a number of end-to- end linear protection domains. Each end-to-end linear protection domain shares protection resources with other domains. The shared protection resource may be a node, link, transport path segment or concatenated transport path segment. A shared mesh protection switching protocol runs within the domain. 3. Shared Mesh Protection Figure 1 shows a simple case of shared mesh protection. Consider two paths ABCDE and VWXYZ. These paths do not share end points so they cannot make use of 1:n protection even though they also do not share any common points of failure. ABCDE may be protected by the path APQRE, and VWXYZ can be protected by the path VPQRZ. For both cases, 1:1 protection may be used. If there are no failures affecting either of the two working paths, the network segment PQR carries no traffic. In the event of only one failure, the segment PQR carries traffic from the working path that experiences the failure. Thus, it is possible for the network resources on the segment PQR to be shared by the two protection paths. In this way, shared mesh protection can substantially reduce the amount of network resources that have to be reserved to provide protection of a 1:n nature. A----B----C----D----E \ / \ / \ / P-----Q-----R / \ / \ / \ V----W----X----Y----Z Figure 1 : A Shared Mesh Protection Topology Cheung, et al. Expires April 25 2011 [Page 5] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 The shared mesh protection domain shown in Figure 1 has two end-to- end linear protection domains. One consists of two end nodes A and E and one working path ABCDE and one dedicated protection path APQRE. And the other consists of end nodes V and Z and one working path VWXYZ and one dedicated protection path VPQRZ. Those two domains share a protection segment PQR. 3.1. Protection Switching Priority A ?Protection Switching Priority? needs to be defined for each end- to-end linear protection domain that has a protection path sharing the same protection resource. According to the Protection Switching Priority, a protection path can displace the other protection path already using the shared protection resources and protect its own working path. The Protection Switching Priority may be provisioned by the network management system. By default, equal priority is assumed resulting in first-come first-served recovery. If multiple end-to-end linear protection domains request protection switching simultaneously, a pre-defined identifier MUST be used to give priority among them. The definition of the identifier is for further study. 3.2. Shared Start and End Nodes A Shared Start Node (SSN) is the first node of a unidirectional shared protection segment. For example, in Figure 1, node P is a SSN on unidirectional protection paths A->P->Q->R->E and V->P->Q->R->Z. In this version of document, SSN does not involve in the shared mesh protection operation. SSN may act as a Maintenance Intermediate Point (MIP) for each protection path sharing the same protection resources. Similarly, a Shared End Node (SEN) is defined as the last node of a unidirectional shared protection segment (for example, node R on unidirectional protection paths A->P->Q->R->E and V->P->Q->R->Z in Figure 1). SEN involves in the shared mesh protection operation for coordinating the use of the unidirectional shared protection segment. A SEN acts as a MIP on each protection path that shares the protection resource. Table 1 summarizes the relationship between SSN and SEN of the shared protection segment and protection paths sharing it. Cheung, et al. Expires April 25 2011 [Page 6] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 Table 1: SSN/SEN in Figure 1 +------------------+-------------------+-----+-----+ | Protection | Shared protection | SSN | SEN | | paths | segment | | | +------------------+-------------------+-----+-----+ | A->P->Q->R->E, | P->Q->R | P | R | | V->P->Q->R->Z | | | | +------------------+-------------------+-----+-----+ | E->R->Q->P->A, | R->Q->P | R | P | | Z->R->Q->P->V | | | | +------------------+-------------------+-----+-----+ Figure 2 shows a more complex example of the shared mesh protection domain. Three working paths ABC, DEF, and GHJ are protected by the protection paths APQC, DRSF, and GPQRSJ, respectively. A------B------C D------E------F \ / \ / \ / \ / \ / \ / P-----Q----------R-----S / \ / \ / \ G--------------H---------------J Figure 2: A More Complex Mesh Protection Example In this example, the unidirectional protection path G->P->Q->R->S->J shares resources with two other protection paths, and both P and R are SSNs, while Q and S are SENs. (See Table 2.) Table 2: SSN/SEN in Figure 2 +-------------------+-------------------+-----+-----+ | Protection | Shared protection | SSN | SEN | | paths | segment | | | +-------------------+-------------------+-----+-----+ | A->P->Q->C, | P->Q | P | Q | | G->P->Q->R->S->J | | | | +-------------------+-------------------+-----+-----+ | C->Q->P->A, | Q->P | Q | P | | J->S->R->Q->P->G | | | | +-------------------+-------------------+-----+-----+ | D->R->S->F, | R->S | R | S | | G->P->Q->R->S->J | | | | +-------------------+-------------------+-----+-----+ | F->S->R->D, | S->R | S | R | | J->S->R->Q->P->G | | | | +-------------------+-------------------+-----+-----+ Cheung, et al. Expires April 25 2011 [Page 7] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 3.3. Bridge and Selector Models Figure 3 shows bridge and selector model for nodes in the shared mesh protection topology shown in Figure 1. For simplicity, only end nodes and shared nodes are modelled. Figure 1 illustrates that node A and E send and receive normal traffic (1) through protection path (1) and node V and Z send and receive normal traffic (2)through working path (2). +-------------------------+ +-------------------------+ |Node A | | Node E| | bridge | | selector | | >=============o o----------->--------------------o o===> | | Normal \ | Working | / Normal| | (1) o=+ | Path (1) | bridge +=o (1) | | <===o o-----------|---------<----------o o=====|=======< | | selector\ | | | / | | | o=+ | | | +=o | | +------------|---------|--+ +--|---------|------------+ | | | | +------------|---------|--+ Protection +--|---------|------------+ |Node P | | | Path (1) | | | Node R| | | +=========>========|=========+ | | +===================<========+ | | | | | | +--------->------------------+ | | +-------------------<--------+ | | | | | | Protection | | | | +------------|---------|--+ Path (2) +--|---------|------------+ | | | | +------------|---------|--+ +--|---------|------------+ |Node V | | | | | | Node Z| | | bridge | | | | | selector | | >=======|=====o-o=|=========>========|=========|=o-o===> | | Normal | | | Working | | | Normal| | (2) | o-+ | Path (2) | | bridge +-o (2) | | <===o-o=|===================<========|=o-o=============< | | selector | | | | | | o-+ | | +-o | +-------------------------+ +-------------------------+ ===: Normal traffics Figure 3: Bridge and selector model of the example mesh protection topology shown in Figure 1 Cheung, et al. Expires April 25 2011 [Page 8] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 Each end node has a bridge and selector to send and receive normal traffic through its working or protection path. Shared nodes have no bridge or selector and all the protection paths are pre-provisioned and monitored. The bandwidth occupied by each working path is B_Wi = B_Ni+B_OAM_Wi; i.e., the bandwidth for the normal traffic signal #i, plus the bandwidth for the OAM used to monitor the working path #i. The bandwidth of the shared protection segment required to protect at least one normal traffic signal among those flowing through n working paths is calculated as: B_P = MAX(B_N1,B_N2,...,B_Nn) + (B_OAM_P1+B_OAM_P2+...+B_OAM_Pn). The bridge and selector model of shared mesh protection is similar to that for (1:1)^n protection type defined in [G.808.1], but it differs in that each working path connects different pair of end nodes, and each protection path shares a same protection segment. 3.4. Shared Mesh Protection Planning Shared mesh protection will typically be subject to careful network planning. This will include: o Determining which working paths are disjoint and so will not be subject to common failures. o Assigning Protection Switching Priority to each end-to-end linear protection domain so that the protection paths can be activated correctly. o Ensuring that working paths of high Protection Switching Priority do not share resources on their protection paths in such a way that would mean that one of them could not be protected. o Enabling the necessary MIP functions at SSN or SEN. Note that some control plane features of GMPLS may be used to dynamically install shared mesh protection. These features are out of scope for this document which focuses on the operation of shared mesh protection switching once it has been installed. 3.5. Shared Mesh Protection Switching The shared mesh protection mechanism is designed to fully utilize the existing end-to-end linear protection switching without any changes except the following two additional functionalities: Cheung, et al. Expires April 25 2011 [Page 9] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 o Function to generate a protection switching event message to the SEN when a switching action occurs at the end-to-end linear protection domain. o Function to take a protection locking message from the SEN, and incorporate it as the Lockout of Protection (LoP) command. 3.5.1. Protection Switching Event If an end node of a working path detects a failure condition, it triggers the protection switching and exchanges linear protection switching protocol messages with its peer end node at the other end of the working/protection path according to the operation defined in its own linear protection switching, which is independent of the mesh protection switching mechanism specified in this document. At the same time, for the shared mesh protection, the end node notifies its protection switching event to SENs by sending a protection switching event message. The protection switching event message MUST be transmitted immediately when an end node changes its selector position either from working to protection or vice versa. If an end-to-end linear protection domain operates in a bidirectional protection switching, both end nodes will change their bridge and selector positions even when a unidirectional failure is detected on one end node, and therefore, both end nodes will transmit the messages to their corresponding SENs. If an end-to-end linear protection domain operates in a unidirectional protection switching and a unidirectional failure is detected, the end node that detects the failure will change its selector position and the messages to its corresponding SEN. There are two possible ways that the protection switching event message could be delivered to SENs. o Option 1 (Default): Use a P2P message The end node of the protection path that is becoming active sends messages directly to each SEN along the protection path (each SEN acts as a MIP). This is done by properly setting the TTL values of the messages for each SEN. This requires N messages to be sent if N SENs exist on the protection path. Furthermore, it requires that the end nodes of the protection path know about all SENs - this is perfectly possible in simple configurations or through the use of a dynamic control plane. Cheung, et al. Expires April 25 2011 [Page 10] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 o Option 2: Use a P2MP message The end node sends a message similar to a route trace to the peer end node. It will be passed to all SENs. When a SEN receives the message, it will simultaneously take a copy of the message for local use, and forward a copy to the next hop. An on-demand OAM message like route trace may contain the required information or the message itself may be transferred using a pre- provisioned P2MP LSP. In this option, the end node becomes a root node and all SENs and the peer end node become leaf nodes. 3.5.2. Protection Locking If a SEN receives the protection switching event notifying that a protection switching has begun in an end-to-end linear protection domain, it compares the Protection Switching Priority of the protection domain notifying the event with those of other protection domains sharing the same protection segment. The SEN does not take an action to the protection domains having higher priorities, but for those having equal or lower priorities, it sends protection locking messages to those end nodes to prevent any protection switching to be occurred. When an end node receives protection switching event message notifying the use of protection path from SEN, it will take the message as an input to the end-to-end linear protection switching, and follows the linear protection switching procedure to process end- to-end LoP command. Since the LoP command has the highest priority in the linear protection switching protocol, it will prohibit any further protection switching in the protection domain. If a protection domain having lower priority currently uses the shared protection segment, it will occupying the protection bandwidth by the command. When a SEN receives a protection switching event message notifying the clearance of protection state from an end node, it sends a protection locking message to the end node to clear the LoP command. 4. Protocol 4.1. PDU Format The shared mesh protection protocol messages MUST be sent over a G-ACh as defined in [RFC5586]. The shared mesh protection protocol messages are as follows: o Protection switching event message and o Protection locking message. Cheung, et al. Expires April 25 2011 [Page 11] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 The channel type in ACH is used to indicate shared mesh protection protocol. The shared mesh protection protocol does not use ACH TLVs, therefore the protocol message MUST follow the ACH. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type = Shared Mesh P. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Mesh Protection Protocol Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Shared mesh protection protocol message header 4.1.1. Protection Switching Event Message The protection switching event message format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protection switching event message (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Protection switching event message format In the message, following field will be provided: o Version o End-to-end linear protection domain identifier o Request/State identifying: - protection path is occupied by normal traffic, or - protection path is not occupied. 4.1.2. Protection Locking Message The protection locking message format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protection locking message (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Protection locking message format Cheung, et al. Expires April 25 2011 [Page 12] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 In the message, following field will be provided: o Version o End-to-end linear protection domain identifier o Request/State identifying: - protection lock requested or - protection unlock requested. 4.2. Message Transmission A new message must be transmitted immediately. The first three messages should be transmitted as fast as possible so that fast protection switching is possible even if one or two messages are lost or corrupted. The interval of the first three messages should be less than 3.3ms. Messages after the first three should be transmitted with the interval of 5 seconds. If no valid message is received, the last valid received information remains applicable. 5. Operation of Shared Mesh Protection This section illustrates the operation of the shared mesh protection protocol for the exemplary topology shown in Figure 2 with following assumptions: o The shared mesh protection domain consists of following end-to-end linear protection domains (LPDs): - LPD1: Working path ABC (W1) / Protection path APQC (P1) - LPD2: Working path GHJ (W2) / Protection path GPQRSJ (P2) - LPD3: Working path DEF (W3) / Protection path DRSF (P3) o Protection Switching Priority is LPD1 > LPD2 > LPD3. (LPD1 has the highest priority.) o All working paths are protected by 1:1 bidirectional protection switching. If a unidirectional failure occurs on the W2 in the direction from node H to node G as shown in Figure 7, the shared mesh protection will operate as follows: a. Node G detects the failure, and initiates the linear protection switching for the failed W2. Cheung, et al. Expires April 25 2011 [Page 13] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 b. At the same time, node G generates the protection switching event message saying that a protection switching event happened to node P and R, which are SENs for J->H->G. c. The SEN P compares the protection switching priority of LPD2 with that of LPD1. In this example, as the priority of LPD1 is higher than LPD2, SEN P does not take an action to node A. The SEN R compares the protection switching priority of LPD2 with that of LPD3. In this example, as the priority of LPD3 is lower than LPD2, SEN R sends the protection locking message requesting LoP to node D. d. Node D takes the protection locking message as an input to the linear protection switching, and follows the linear protection switching procedure to process the end-to-end LoP command. As LPD2 operates in a 1:1 bidirectional protection switching, node J also changes its bridge and selector state to synchronize with node G, thus it will generate the protection switching event message to node S and Q, which are SENs for G->H->J. By the same procedure described above, the SEN S sends the protection locking message to node F while the SEN Q does not take an action to node C. W1 W3 ==A======B======C== ==D======E======F== \ / \ / \ LPD1 / \ LPD3 / \ / \ / == : Normal traffic P=====Q================R=====S // \\ // LPD2 \\ // \\ ==G------xx---------H------------------J== SF on G<-H W2 Figure 7 : Shared Mesh Protection Example 1 Figure 8 shows a progression from Figure 7. While LPD2 is in protecting state with its traffic following the protection path P2 (GPQRSJ), another unidirectional failure occurs on the W1 in the direction from node B to node A. In this case, the shared mesh protection will operate as follows: a. Node A detects the failure, and initiates the linear protection switching for the failed W1. b. At the same time, node A generates the protection switching event message saying that a protection switching event happened to node P, which is SEN for C->B->A. Cheung, et al. Expires April 25 2011 [Page 14] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 c. The SEN P compares the protection switching priority of LPD1 with that of LPD2. In this example, as the priority of LPD2 is lower than LPD1, SEN P sends the protection locking message requesting LoP to node G. d. Node G takes the protection locking message as an input to the linear protection switching, and follows the linear protection switching procedure to process the end-to-end LoP command. When LPD2 is forced to lock its protection path P2, it may try to find another available path. m:n protection or other recovery mechanism can be used for this, but this discussion is out of scope of this document. e. As the node G changes its bridge and selector states from protection to working, it will generate the protection switching event message saying that a protection switching event has been cleared to node P and R, which are SENs for J->H->G. f. The SEN P compares the protection switching priority of LPD2 with that of LPD1 and does not take an action to node A, but the SEN R sends the protection locking message requesting clearance of LoP to node D. g. Node D takes the message as an input to the linear protection switching, and follows the linear protection switching procedure to clear the end-to-end LoP command. SF on A<-B W1 W3 ==A-xx---B------C== ==D======E======F== \\ // \ / \\ LPD1 // \ LPD3 / \\ // \ / == : Normal traffic P=====Q---------------R-----S / \ / LPD2 \ / \ ==G------xx---------H-----------------J== SF on G<-H W2 Figure 8 : Share Mesh Protection Example 2 Cheung, et al. Expires April 25 2011 [Page 15] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 6. Manageability Considerations To be added in future version. 7. Security Considerations To be added in future version. 8. IANA Considerations To be added in future version. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC5654] Brungard, D., Betts, M., Sprecher, N. and Ueno, S., "Requirements of an MPLS Transport Profile", RFC5654, September 2009. 9.2. Informative References [RFC3031] Rosen, E., Viswanathan, A. and Callon, R., "Multiprotocol Label Switching Architecture", RFC3031, January 2001. [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC3985, March 2005. [RFC5085] Nadeau, T. and Pignataro, C., "Pseudo Wire (PW) Virtual Circuit Connectivity Verification ((VCCV): A Control Channel for Pseudowires", RFC5085, December 2007. [I-D.ietf-mpls-tp-survive-fwk] Sprecher, N. and Farrel A., "Multiprotocol Label Switching Transport Profile Survivability Framework", draft-ietf-mpls-tp-survive-fwk, work on progress. [G.808.1] ITU-T, "Generic Protection Switching - Linear trail and subnetwork protection", Recommendation G.808.1, February 2010. Cheung, et al. Expires April 25 2011 [Page 16] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 [RFC4428] Papadimitriou, D. and E. Mannie, "Analysis of Generalized Multi-Protocol Label Switching (GMPLS) ? based Recovery Mechanisms (including Protection and Restoration) Recovery (Protection and Restoration)", RFC 4428, March 2006. ???[I-D.ietf-mpls-tp-oam-framework] Busi, S., Niven-Jenkins, B. and Allan, D., "MPLS-TP OAM Framework", draft-ietf-mpls-tp-oam-framework, work on progress. Cheung, et al. Expires April 25 2011 [Page 17] Internet-Draft MPLS-TP Shared Mesh Protection October 2010 Authors' Addresses Tae-sik Cheung ETRI 161 Gajeong, Yuseong, Daejeon, 305-700, South Korea Phone: +82 42 860 5646 Email: cts@etri.re.kr Jeong-dong Ryoo ETRI 161 Gajeong, Yuseong, Daejeon, 305-700, South Korea Phone: +82 42 860 5384 Email: ryoo@etri.re.kr Cheung, et al. Expires April 25 2011 [Page 18]