MPLS Working Group Tae-sik Cheung Internet Draft Jeong-dong Ryoo Intended status: Standards Track ETRI Created: March 1, 2010 Expires: September 1, 2010 MPLS-TP Mesh Protection draft-cheung-mpls-tp-mesh-protection-00.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 mesh protection mechanism enables multiple recovery paths to share protection resources for the protection of working paths by coordinating protection switching operations according to the priority assigned to each 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 September 1, 2010. Cheung, et al. Expires September 1, 2010 [Page 1] Internet-Draft MPLS-TP Mesh Protection March 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 3. Mesh Protection............................................... 4 3.1. Protection Switching Priority............................ 5 3.2. Shared Start and End Nodes............................... 5 3.3. Bridge and Selector in Mesh Protection................... 6 3.4. Shared Mesh Protection Planning.......................... 7 3.5. Mesh Protection Switching................................ 7 3.5.1. Protection State Change Notification................... 7 3.5.2. Protection Locking..................................... 9 4. Operation of Mesh Protection..................................10 5. Manageability Considerations..................................12 6. Security Considerations.......................................12 7. IANA Considerations...........................................12 8. References....................................................12 8.1. Normative References.....................................12 8.2. Informative References...................................12 Cheung, et al. Expires September 1, 2010 [Page 2] Internet-Draft MPLS-TP Mesh Protection March 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 recovery 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 recovery path to protect n working paths. This improves overall network utilization, but the resource (bandwidth) allocated to a recovery 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 recovery 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 points of the working path must be shared with the recovery path. The same applies in 1:n protection where all pairs of end nodes of the n working paths are the same, and the recovery path must also share the same end points. 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 protection domains 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 September 1, 2010 [Page 3] Internet-Draft MPLS-TP Mesh Protection March 2010 In mesh protection, network resources may be shared to provide protection for working paths that do not share end points 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. This document defines a mesh protection mechanism which coordinates the use of shared protection resource based on the protection switching priority assigned to each protection domain. The mechanism builds on the Protection State Coordination (PSC) messages introduced in [I-D.ietf-mpls-tp-linear-protection]. 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]. 3. Mesh Protection Figure 1 shows a simple case of 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. In both cases, 1:1 or 1+1 protection may be used. However, it can be seen that, if 1:1 protection is used for both paths, the network segment PQR carries no traffic if there are no failures affecting either of the two working paths. Furthermore, in the event of only one failure, the segment PQR carries traffic from only one of the working paths. Thus, it is possible for the network resources on the segment PQR to be shared by the two recovery paths. In this way, mesh protection can substantially reduce the amount of network resources that have to be reserved to provide protection of a 1:n nature. Cheung, et al. Expires September 1, 2010 [Page 4] Internet-Draft MPLS-TP Mesh Protection March 2010 A----B----C----D----E \ / \ / \ / P-----Q-----R / \ / \ / \ V----W----X----Y----Z Figure 1 : A Mesh Protection Topology The remainder of this document sets out some of the challenges introduced by mesh protection, and describes solutions built on the Protection State Coordination (PSC) messages introduced for 1:1 linear protection in [I-D.ietf-mpls-tp-linear-protection]. 3.1. Protection Switching Priority A Protection Switching Priority needs to be defined for each protection domain that has a recovery path sharing the same protection resource. According to the priority, a recovery path can displace the other recovery path already using the shared protection resources and protect its own working path. The Protection Switching Priority should be provisioned by the network management system. By default, equal priority is assumed resulting in first-come first-served recovery. 3.2. Shared Start and End Nodes A Shared Start Node is the first node of a shared protection segment. For example, in Figure 1, node P is a Shared Start Node on recovery paths APQRE and VPQRZ. A Shared Start Node acts as a Maintenance Intermediate Point (MIP) node for each recovery path sharing the same protection resources. Similarly, a Shared End Node is the last node of a shared protection segment (for example, node R in Figure 1). Shared End Nodes are also MIPs on the recovery paths that share the protection resources. Cheung, et al. Expires September 1, 2010 [Page 5] Internet-Draft MPLS-TP Mesh Protection March 2010 A------B------C D------E------F \ / \ / \ / \ / \ / \ / P-----Q----------R-----S / \ / \ / \ G--------------H---------------J Figure 2: A More Complex Mesh Protection Example Figure 2 shows a more complex example of mesh protection. Three working paths ABC, DEF, and GHJ are protected by the recovery paths APQC, DRSF, and GPQRSJ, respectively. In this example, the recovery path GPQRSJ shares resources with two other recovery paths, and both P and R are Shared Start Nodes, while Q and S are Shared End Nodes. 3.3. Bridge and Selector in Mesh Protection Figure 3 shows some example bridges and selectors for nodes in the mesh protection topology shown in Figure 2. At the top of the figure we see the bridge and selector at node A. Traffic is normally sent and received to/from node B, but in the event of a protection switch, the traffic is sent and received to/from node P. Further down the figure we see the bridge and selector at Node P. Node P is a Shared Start Node of the protection segment PQ. Normally it sees no traffic and the settings of the selector and bridge are not important. However, depending on the protection actions, the selector can be set to send the traffic from node A or G to node Q, and the bridge can also be set to send the traffic from node Q to node A or G. --<---- | To/From B Bridge -----+------> --->------o---> | -----+--- | | Bridge and Selector | | at Node A <---- | <---------o---- | Selector <--------+--- | To/From P --> Cheung, et al. Expires September 1, 2010 [Page 6] Internet-Draft MPLS-TP Mesh Protection March 2010 ---->-- To/From A | <------+----- Bridge | <---o------ ---+----- | | To/From Q Bridge and Switch | | at Node P | ----> | ----o-----> ---+--------> Selector To/From G | <-- Figure 3 : Examples of Bridges and Selectors for Mesh Protection 3.4. Mesh Protection Planning Mesh protection will typically be subject to careful network planning. This will include: - Determining which working paths are disjoint and so will not be subject to common failures. - Assigning priorities to the working paths so that the recovery paths can be activated correctly. - Ensuring that working paths of high protection priority do not share resources on their recovery paths in such a way that would mean that one of them could not be protected. - Enabling the necessary MIP functions at the Shared Start and End Nodes. In many networks, it may provide a considerable simplification of mesh protection to divide the network into distinct protection domains, however, more effective operation of mesh networks examines the working paths separately and does not impose a protection domain model. Note also that some control plane features of GMPLS may be used to dynamically install mesh protection. These features are out of scope for this document which focuses on the operation of mesh protection switching once it has been installed. 3.5. Mesh Protection Switching 3.5.1. Protection State Change Notification Cheung, et al. Expires September 1, 2010 [Page 7] Internet-Draft MPLS-TP Mesh Protection March 2010 If an end node of a working path detects a failure condition, it triggers the protection switching by exchanging PSC messages with its peer end node at the other end of the working/recovery path. Coordination must also be achieved with all of the Shared Nodes (Shared Start Nodes and Shared End Nodes) along the recovery path to ensure that: - the resources allocated to the recovery path are available, and - any lower priority traffic is displaced from the shared protection resources before they are allocated to the new recovery path. Similarly, when protection switching has completed, all Shared Nodes along the path must be notified. Protection state change is notified using the PSC messages defined in [I-D.ietf-mpls-tp-linear-protection]. These messages are sent from one end of a recovery path to the other, and are intercepted by the Shared Nodes. The PSC messages are carried as OAM messages in the GACh. Such messages are usually targeted specifically at MIPs or MEPs. This means there are two possible ways that the PSC message could be delivered to the Shared Nodes. o Option 1: Use a P2P message The end node of the recovery path that is becoming active sends messages directly to each Shared Node along the recovery path (each Shared Node acts as a MIP). This is done by properly setting the TTL values of the messages for each MIP. This requires N messages to be sent if N Shared Nodes exist on the recovery path. Furthermore, it requires that the end nodes of the recovery path know about all of the Shared Nodes - this is perfectly possible in simple configurations or through the use of a dynamic control plane. 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 MIPs in the Shared Nodes. When a Shared Node 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 a PSC message itself may be transferred using a pre- provisioned P2MP LSP. In this option, the end node becomes a root node and all Shared Nodes and the peer end node become leaf nodes. Cheung, et al. Expires September 1, 2010 [Page 8] Internet-Draft MPLS-TP Mesh Protection March 2010 An additional, optional stage in the coordination of protection state involves notifying the end points of recovery paths that could use the shared resources that the resources are now in use at a particular priority and that the working paths may no longer be protected. This feature is for future study. 3.5.2. Protection Locking If a Shared Node receives a message notifying that a recovery path needs to use the shared protection resources, it compares the priority of the recovery path with the priority of the recovery path (if any) currently using the resources. If the current use of the shared protection resources has an equal or higher priority, the Shared Node does nothing. If it has a lower priority or there is no current use of the shared protection resources, then the Shared Node locks the protection resources to disable the current recovery path from accessing the shared protection resources or prohibit any further protection switching by a lower priority recovery path. When the Shared Node receives a message notifying the clearance of protection state, it unlocks the protection resources. There are two options on how to lock the protection resources. o Option 1: Use a PSC Lockout message A Lockout message defined in [I-D.ietf-mpls-tp-linear-protection] can be used as a lock message for mesh protection. When two end nodes of a protection domain receive a Lockout message, it will be the highest priority request and the protection switching is locked. This option will also need to consider how to deal with the messages generated by each end node. In the current version of [I-D.ietf-mpls- tp-linear-protection], it will not affect the mesh protection operation because each end node will generate the same messages when it receives a Lockout from the far-end node (actually from the Shared Nodes). For other protection types, further considerations will be discussed in future versions of this document. o Option 2: Use an OAM Lock message A Lock instruction message defined in [I-D.ietf-mpls-tp-oam- framework] may be used as a lock message for mesh protection. When two end nodes of a protection domain receive a Lock message, they will consider that the recovery path is unavailable. In this option, the OAM Lock message may be sent periodically to maintain the lock state. Cheung, et al. Expires September 1, 2010 [Page 9] Internet-Draft MPLS-TP Mesh Protection March 2010 Mesh protection should support both unidirectional and bidirectional protection. A shared protection resource may be available to provide bidirectional protection for some working paths, and unidirectional protection for other working paths. Further considerations for these requirements will be included in future versions of this document. 4. Operation of Mesh Protection In Figure 4, the following assumptions are made: a. There are three working paths WA (ABC), WD (DEF), and WG (GHJ) with protection priorities PA, PD, and PG, respectively. b. Protection switching priority is PA > PG > PD. (PA is the highest protection priority.) c. All working paths are protected by 1:1 bidirectional protection switching which utilizes the PSC protocol as described in [I-D.ietf-mpls-tp-linear-protection]. Since it uses a 1-phase PSC protocol, no confirmation from the peer node is required. WA(PA) WD(PD) A------B------C D------E------F \ / \ / \ / \ / \ / \ / P-----Q----------R-----S / \ / \ / WG(PG) \ G------xx------H---------------J SF on G<-H Figure 4 : Mesh Protection Example 1 If a failure occurs between nodes G and H as shown in Figure 4, mesh protection will operate as follows: a. G detects a failure on the working path WG. b. G sends a message notifying the protecting state to the Shared Nodes P, Q, R, and S. c. Shared Nodes P and Q compare the priority PA with PG and do nothing (PA > PG), but Shared Nodes R and S compare the priority PD with PG and send lock messages to end nodes D and F (PD < PG). Cheung, et al. Expires September 1, 2010 [Page 10] Internet-Draft MPLS-TP Mesh Protection March 2010 d. WD (i.e., nodes D and F) locks its recovery path and changes its state from normal to unavailable (i.e., unprotected). (Protection switching for WD is then prohibited.) SF on A<-B WA(PA) WD(PD) A--xx--B------C D------E------F \ / \ / \ / \ / \ / \ / P-----Q----------R-----S / \ / \ / WG(PG) \ G------xx------H---------------J SF on G<-H Figure 5 : Mesh Protection Example 2 Figure 5 shows a progression from Figure 4. While WG is in protecting state with its traffic following the recovery path GPQRSJ, another failure occurs on the link AB affecting WA. Mesh protection will operate as follows: a. Node A detects a failure on the working path WA. b. A sends a message notifying the protecting state to P and Q. c. P and Q compare the priority of PG (currently using the shared protection resources) with PA, and sends a lock message to G and J. d. WG locks its recovery path and changes its state from protecting to unavailable. (The previous protection state is now overruled.) e. G and J send messages notifying the clearance of protecting state to Shared Nodes P, Q, R, and S. f. R and S send unlock messages to D and F. g. WD unlocks its recovery path and changes its state from unavailable to normal. When WG is forced to lock its recovery path, 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. Cheung, et al. Expires September 1, 2010 [Page 11] Internet-Draft MPLS-TP Mesh Protection March 2010 5. Manageability Considerations To be added in future version. 6. Security Considerations To be added in future version. 7. IANA Considerations To be added in future version. 8. References 8.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. 8.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. [I-D.ietf-mpls-tp-linear-protection] Bryant, S., Sprecher, N., Van Helvoort, H., Fulignoli, A. and Weingarten, Y., "MPLS-TP Linear Protection", draft-ietf-mpls-tp-linear-protection, work on progress. Cheung, et al. Expires September 1, 2010 [Page 12] Internet-Draft MPLS-TP Mesh Protection March 2010 [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 September 1, 2010 [Page 13] Internet-Draft MPLS-TP Mesh Protection March 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 September 1, 2010 [Page 14]