MPLS Working Group G. Liu Internet-Draft J. Yang Intended status: Standards Track j. Yu Expires: September 6, 2011 Z. Fu ZTE Corporation March 5, 2011 Multiprotocol Label Switching Transport Profile p2mp Shared Protection draft-liu-mpls-tp-p2mp-shared-protection-01 Abstract This document will describle two protection solutions to support protection of failures in p2mp path in MPLS-TP. According to the protection Requirements in RFC 5654, there are requirements for MPLS-TP to support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources. In addition, there is a requirement for MPLS-TP to support unidirectional 1:n protection for p2mp paths. These requirements are further addressed in draft-ietf-mpls-tp-survive-fwk . so this draft will present proposed solutions . 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. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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." Liu, et al. Expires September 6, 2011 [Page 1] Internet-Draft MPLS-TP p2mp shared protection March 2011 This Internet-Draft will expire on September 6, 2011. Copyright Notice Copyright (c) 2011 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. Liu, et al. Expires September 6, 2011 [Page 2] Internet-Draft MPLS-TP p2mp shared protection March 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. p2mp shared protection solution . . . . . . . . . . . . . . . 5 3.1. 1:n protection . . . . . . . . . . . . . . . . . . . . . . 6 3.2. (1:1)^n protection . . . . . . . . . . . . . . . . . . . . 9 3.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Liu, et al. Expires September 6, 2011 [Page 3] Internet-Draft MPLS-TP p2mp shared protection March 2011 1. Introduction This document describes protection solutions for MPLS-TP p2mp paths. The first solution is based on extending 1:1 protection solution to implement 1:n protection by using a shared protection p2mp path when there may have defect in the working p2mp path. A second solution uses a shared p2p bidirectional protection tunnel to protect the branch path of a p2mp working path when detecting defects in a branch path of some p2mp working paths to implement (1:1)^n protection. Both protection solutions satisfy and fulfill requirement 69 and 67B in [RFC 5654]. These solutions can't exclude 1+1 and 1:1 protection solutions for p2mp path in draft-ietf-mpls-tp-survive-fwk and draft-ietf-mpls-tp-linear-protection. it will be used to perfect the requirement of recovery for p2mp path. If only 1+1 protection is used for p2mp path, there need to set up a disjoint protection path for each working path, This will increase the cost of maintaining and monitoring each of these paths (i.e. both the working and protection paths). In addition, since the p2mp service must be transported on both the working and protection paths, more bandwidth resource will be consumed for the p2mp service . Due to these limitations, it is neccesary to consider using shared protection resources for many working paths. 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. OAM: Operations, Administration, Maintenance LSP: Label Switched Path. TLV: Type Length Value LSR:Label Switching Router P2MP:Point to Multi-Point P2P:Point to Point APS:Automatic Protection Switch PSC:Protection Switching Coordination SD:Signal Degrade Liu, et al. Expires September 6, 2011 [Page 4] Internet-Draft MPLS-TP p2mp shared protection March 2011 SF:Signal Fail RDI:Remote Defect Indication MPLS:Multi-Protocol Label Switching MPLS-TP:Multi-Protocol Label Switching Transport Profile ME: Maintenance Entity MEP:MEG End Point ACH: Associated Channel Header CC-V: Contunuity Check-Verification; 3. p2mp shared protection solution This section describes two types of p2mp shared protection solutions. The first proposed solution utilizes one p2mp protection path to protect n p2mp working paths . When a protected p2mp working path detects a defect, the leaf node of the p2mp working path will notify its own root node of defective message by RDI packet through out-of- band return path. If there is no other higher priority protected p2mp working path or control command that requires the use of the protection path, then the defective p2mp service packet will switch to p2mp protection path to be transported. All leaf nodes of the defective p2mp path will select protection path to receive p2mp service packets. The second proposed solution uses a p2p bidirectional protection tunnel to protect defective branch paths of many protected p2mp working paths. When a defect is detected on a protected branch path of one p2mp working path, the leaf node which has already detected the defect will notify peer node of its own p2p protection path of defective message by extensive APS or PSC packet as the following figure 1. As a result, the service will switch to the protection path to be transported ,so it will bridge both working path and protection path to be transported. But the leaf node of the defective branch path in the p2mp working path will select the protection p2p path to receive the service packet. But other leaf nodes will still receive the service packet from original p2mp working path. The two p2mp shared protection solutions separately implement 1:n and (1:1)^n protection for p2mp path, The following sub-section describes the protection switching methods in detail. Liu, et al. Expires September 6, 2011 [Page 5] Internet-Draft MPLS-TP p2mp shared protection March 2011 3.1. 1:n protection The 1:n protection solution should be similar to 1:1 protection solution described in [survivability-framework] to use one protection path to protect many p2mp service traffics. However, in this mechanism since the protected traffics are transported by different working path. Its implication regarding the p2mp protection path will be configured between the protection domain root node and all leaf nodes of protected p2mp working paths. The operation of this solution is based on the root node of each working p2mp path SHOULD send CC-V OAM packet to all its own leaf nodes periodically. When a leaf node of a p2mp working path fails to receive the CC-V OAM packet for a fixed period, The leaf node should generate RDI packet to notify its own root node of the defective message . When the root node of the p2mp working path receives the RDI packet and knows some failure in one or more one branch path of the p2mp working path, it may send protection switch requirement control packet to the root node of its own protection path and access node of the p2mp service. When the root node of the protection path receives the protection switch requirement control packet from any root node of the protected defective p2mp working path The root node of the protection path MUST choose one defective path to be protected based on the priority of these protected defective p2mp working paths. Then the root node of protection path SHALL generate extensive APS or PSC packet that includes the selected p2mp defective path identifier in a TLV field of the message packet .The following figure 1 is the format of extensive APS or PSC packet .Then it will send the extensive APS or PSC message to all leaf nodes of the p2mp protection path . 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Channel type(APS OR PSC)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + APS or PSC PDU + : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ P2MP LSP ID TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Liu, et al. Expires September 6, 2011 [Page 6] Internet-Draft MPLS-TP p2mp shared protection March 2011 Figure 1 NOTE: P2MP LSP ID TLV: a standard TLV frame structure. including Type , Length,and Value, and the value field may be identifier of p2mp LSP which have defect and should need to be protected. this p2mp LSP ID TLV format is as the following figure 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | Length | P2MP Path Identifier value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 At the same time, the root node of protection path generates notify message control packet and send it to the root node of each defective p2mp working path by control channel ,so the root node of each defective p2mp working path can know whether it may be selected to be protected based on the notify message control packet. If it has already been selected to be protected, it will stop sending service packet in the p2mp working path Then the protected service will switch to the p2mp protection path to be transported. On the other hand, all leaf nodes of the protection path receive the extension APS or PSC message from the protection path. Then they will know whether to accept and process the service packet from the protection path based on p2mp LSP ID TLV field in the extensive APS or PSC packet. If the leaf node is one sink node of the protected service, it will accept and process the service packet from the protection path. Or else, it will drop the service packet. the implement in detail as the following figure is 1:2(n=2) protection instance. Liu, et al. Expires September 6, 2011 [Page 7] Internet-Draft MPLS-TP p2mp shared protection March 2011 +---+ +->| L1| + +---+ X @ + @ + @ +---+ +-------------+ @ | r1|+ + + + +->| P2MP path 1 | @ +---+ | | @ | +-------------+ @ | + | @ + +---+ +------------+ + +---+ | p |@ @ @ @ @-> | protection | @ @ @ @-> | L2| +---+ | path | $+---+ | +------------+ X | @ $ | $ @ +---+ +------------+ @ +---+ | r2|$ $ $ $-> | P2MP |$ $ $ @-> | L3| +---+ | Path 2 | +---+ +------------+ NOTE: @@@@@@: p2mp protection path +++++: p2mp working path 1 $$$$$: p2mp working path 2 X: failure Figure 3 For the above p2mp network topology , there are two different p2mp services which need to be transported separately by p2mp working path 1( r1-p2mp path 1-L1,L2) identified by (+) and p2mp working path 2(r2- p2mp path 2-L2,L3)identified by ($) . under normal situation. the p2mp service from root node r1 will be sent and transported to leaf nodes L1,L2 by p2mp working path 1, and another p2mp service from the root node r2 will be sent and transported to leaf nodes L2,L3. in addition, only one p2mp protection path ( P-protection path-L1,L2,L3)identified by (@) is used to protect the p2mp working path 1 and the p2mp working path 2. supposing the protection priority of p2mp working path 1 is higher than p2mp working path 2. if there Liu, et al. Expires September 6, 2011 [Page 8] Internet-Draft MPLS-TP p2mp shared protection March 2011 is a defect in separately branch path(r1-p2mp path 1-L1) of p2mp working path 1 and branch path(r2-p2mp path 2-L2) of p2mp working path 2, Leaf node L1 and leaf node L3 will separately send RDI packet to root node r1 and root node r2 by out-of-band return path. when root node r1 and r2 received the RDI packet and processed it. then the control packet of protection switch requirement will be sent to the root node P of protection path by control channel . Then the root node P will choose one working path to be protected. As the priority of p2mp working path 1 is higher than p2mp working path 2. so the root node P of protection path will select p2mp working path 1 to be protected, and send extensive APS or PSC packet including p2mp LSP ID TLV to all Leaf nodes(L1,L2,L3) of the protection path. At the same time, It will generate response control packet for the protection switch requirement of the root node r1 and r2. the service of the working path 1 will be selected to be protected. So the root node r1 of working path 1 will stop sending its p2mp service in the working path 1, Then the service of the working path 1 will switch to the protection path to be transported. on the other hand, for leaf nodes( L1,L2,L3), when they received the extensive APS or PSC packet from the root node P, They will decide whether to accept and process the service packet from the protection path. As leaf nodes(L1,L2) are the leaf nodes of p2mp working path 1, they will both accept and process the service packet from the p2mp protection path. but for leaf node L3, as it is not the leaf node of p2mp working path 1. it will drop the service packet from the p2mp protection path. While the service of p2mp working path 2 can't be selected to be protected, so the root node r2 will continue to send their own service packet by p2mp working path 2. 3.2. (1:1)^n protection This protection solution can use p2p bidirectional protection tunnel to protect some branch paths of many p2mp working paths which have the same leaf node . Under normal situation, the root node of each p2mp working path will periodically send CC-V OAM packet to its own leaf nodes by the p2mp working path to detect defect .In order to protect each branch path of the p2mp working path, Firstly a bidirectional protection p2p path will be pre-configured between source protection node and the leaf node of the protected p2mp working path . in addtion, using an unique adress identifier including IP multicast address,mpls label etc can identify which service is tranported in the protection p2p tunnel. when some leaf nodes detect defect on some branch path of the p2mp working path, it would generate extensive APS or PSC packet Just as the above figure 1 and send it to source protection node . the source protection node received the the packet , it will compare the priority of these defective working path. Then it selects the highest priority service Liu, et al. Expires September 6, 2011 [Page 9] Internet-Draft MPLS-TP p2mp shared protection March 2011 to be protected and encapsulate the protected service PDU by an unique adress identifier , then it will be sent to the leaf node of the defective branch path. for example, there is a (1:1)^2(n=2) protection instance as the following figure 4: there are two p2mp working paths : p2mp working path 1(r1-p2mp Path 1-L1,L2) identified by ($) and p2mp working path 2(r2-p2mp Path 2-L2,L3) identified by (#).in order to protect the service, a bidirectional p2p protection tunnel will be pre-configured between each leaf node(L1,L2,L3) and its own source protection node(P). so it need to configure three p2p protection tunnels identified by (@) in the figure Liu, et al. Expires September 6, 2011 [Page 10] Internet-Draft MPLS-TP p2mp shared protection March 2011 $ +----+ $ | L1 | +-------------+ $ @ +----+ $ | P2MP Path 1 | @ $ +-------------+ $ @ $ @ $ @ +----+ $ @ X | L2 | $ @ @ $ +----+ +----+ @ @ # | R1 | @ +----+ @ @ X | @ | @ @ # +----+ @ @ | P | @ # +----+ @ | @ @ @ @ @ @ @ @ @ @ +----+ # | L3 | +----+ # # | +-------------+ # # | P2MP Path 2 | # +----+ # +-------------+ | R2 | # +----+ NOTE: @: P2P Protection Tunnel $: P2MP Working Path LSP 1 #: P2MP Working Path LSP 2 X: failure Figure 4 when the branch path(R1-P2MP Path 1-L2) of p2mp working path LSP 1 and the branch path(R2-P2MP Path 2-L2) of p2mp working path LSP 2 have the defect at the same time, The leaf node L2 will generate extensive APS or PSC packet including p2mp LSP identifier and send it to source protection node(P). while the source protection node(P) received the extensive APS or PSC packet from the Leaf node L2, it will select higher priority service to be protected and encapsulate Liu, et al. Expires September 6, 2011 [Page 11] Internet-Draft MPLS-TP p2mp shared protection March 2011 the protected service packet by an unique address identifier(IP Multicast address, mpls label etc) and be trasnported through the p2p protection tunnel(P-L2). As the priority of the p2mp working path 1 is higher than the p2mp working path 2. The source protection node (P) will select the service of the p2mp working path 1 to be protected and encapsulate it by the its own unique address identifier . then the protected service of the p2mp working path 1 will be sent by the p2p protection tunnel. at the same time, the leaf node L2 will select the protection tunnel to receive service packet and be based on the unique address identifier to judge which service is transported by p2p protection tunnel now. so that the leaf node L2 can process truely the service packet . 3.3. Conclusion The two types of p2mp protection solution will individually implement 1:n and (1:1)^n protection for p2mp service. They can fulfill the requirement of unidirectional p2mp protection and sharing protection resource. in addition, the first solution need a special out-of-band return path to send failure message to the root node of p2mp working path. while for the second protection solution, as its protection path is bidirectional , it is unnecessary to set up out-of-band return path for sending failure message. . 4. Security Considerations The security considerations for the authentication TLV need further study. 5. IANA Considerations TBD. 6. Acknowledgments The authors would like to thank yaccov for giving a lot of good comments and revising many syntax for the document. And thank Malcolm Betts and other experts for Providing some good comments and their input to and review of the current document . 7. References Liu, et al. Expires September 6, 2011 [Page 12] Internet-Draft MPLS-TP p2mp shared protection March 2011 7.1. Normative References [ITU-T G.8131] ITU-T, "ITU-T Recommendation(T-MPLS Linear protection)", February 2007. [RFC 5654] IETF, "IETF RFC5654(MPLS-TP requirement)", September 2009. [RFC 5921] IETF, "IETF RFC5654(MPLS-TP framework)", July 2010. 7.2. Informative References [L2VPN ICCP] Luca Martini, Samer Salam, Ali Sajassi, Satoru Matsushima, Matthew Bocci, Thomas D. Nadeau, "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Oct 2010. [MPLS-TP Linear protection] S. Bryant, N. Sprecher, H. van Helvoort,A. Fulignoli Y. Weingarten, "MPLS transport profile Linear Protection", July 2010. [MPLS-TP Survivability Framework] N. Sprecher, A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", June 2010. [MPLS-TP linear protection] Z.Haiyan, I.umansky, L. han,J.Ryoo, D'Alessandro , "Linear Protection Switching in MPLS-TP", July 2010. 7.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, "", 2008, . Liu, et al. Expires September 6, 2011 [Page 13] Internet-Draft MPLS-TP p2mp shared protection March 2011 Authors' Addresses Liu guoman ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871606 Email: liu.guoman@zte.com.cn Yang Jian ZTE Corporation 5F,RD Building 3,ZTE Industrial Park,XiLi LiuXian Road Nanshan District,Shenzhen 518055 P.R.China Phone: +86 755 26773731 Email: yang_jian@zte.com.cn Yu jinghai ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871606 Email: yu.jinghai@zte.com.cn Fu zhentao ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871745 Email: fu.zhentao@zte.com.cn Liu, et al. Expires September 6, 2011 [Page 14]