MPLS Working Group G. Liu Internet-Draft ZTE Corporation Intended status: Standards Track Y. Ji Expires: March 2, 2012 Beijing University of Posts and Telecommunications J. Yang j. Yu ZTE Corporation Z. Du Beijing University of Posts and Telecommunications August 30, 2011 Multiprotocol Label Switching Transport Profile p2mp Shared Protection draft-liu-mpls-tp-p2mp-shared-protection-02 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 protection 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- Liu, et al. Expires March 2, 2012 [Page 1] Internet-Draft MPLS-TP p2mp shared protection August 2011 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 March 2, 2012. 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 March 2, 2012 [Page 2] Internet-Draft MPLS-TP p2mp shared protection August 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 March 2, 2012 [Page 3] Internet-Draft MPLS-TP p2mp shared protection August 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 one shared protection p2mp path when there may have failures on the protected working p2mp paths. A second solution uses one shared p2p bidirectional protection tunnel to protect many branch paths of the protected p2mp working paths when detecting defects on 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 at the same time, more bandwidth resource will be consumed for the p2mp service . Due to these limitations and defects, it is neccesary to consider using shared protection resources for many p2mp 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 P2MP:Point to Multi-Point P2P:Point to Point PSC:Protection Switching Coordination SD:Signal Degrade SF:Signal Fail RDI:Remote Defect Indication Liu, et al. Expires March 2, 2012 [Page 4] Internet-Draft MPLS-TP p2mp shared protection August 2011 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 many p2mp working paths . When a protected p2mp working path detects a failure, the leaf node of the p2mp working path will notify its own root node of defective message by RDI packet by 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 utilizes one p2p bidirectional protection tunnel to protect defective branch paths of many protected p2mp working paths. When a failure is detected on a protected branch path of one p2mp working path, the leaf node which has already detected the failure will notify peer node of its own p2p protection tunnel of defective message by extensive 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 on 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. 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 Liu, et al. Expires March 2, 2012 [Page 5] Internet-Draft MPLS-TP p2mp shared protection August 2011 path to protect many p2mp working paths. 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. when a leaf node of a protected p2mp working path detect a failure, 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 failures 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 or access node of the protected 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 PSC packet including the selected p2mp defective path identifier in a TLV field of the message packet .The following figure 1 is the format of extensive PSC packet .Then it will send the extensive 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(PSC)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PSC PDU + : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ P2MP LSP ID TLV ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Liu, et al. Expires March 2, 2012 [Page 6] Internet-Draft MPLS-TP p2mp shared protection August 2011 which have defect and 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 the protection path generates notify message control packet including selective protected working path identifier 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 on 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 extensive PSC message by 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 PSC packet. If the leaf node is a 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 March 2, 2012 [Page 7] Internet-Draft MPLS-TP p2mp shared protection August 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 condition. 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 priority of p2mp working path 1 is higher than p2mp working path 2. if there is a Liu, et al. Expires March 2, 2012 [Page 8] Internet-Draft MPLS-TP p2mp shared protection August 2011 failure on 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 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 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 PSC packet from the root node P, They will decide whether to accept and process the service packet from the protection path based on selective protected working path identifer. 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 condition, 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 failure .In order to protect each branch path of the p2mp working path, Firstly one bidirectional protection p2p tunnel 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 a failure on some branch path of the p2mp working path, it would select highest priority p2mp service to be protected and generate extensive PSC packet including selective protected p2mp identifier Just as the above figure 1 and send it to peer node of the protection tunnel . when it received the the extensive PSC packet , Liu, et al. Expires March 2, 2012 [Page 9] Internet-Draft MPLS-TP p2mp shared protection August 2011 it will 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 March 2, 2012 [Page 10] Internet-Draft MPLS-TP p2mp shared protection August 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 a failure at the same time, The leaf node L2 will generate extensive PSC packet including selective protected p2mp LSP identifier and send it to peer node(p) of protection tunnel. while the node(P) received the extensive PSC packet from the Leaf node L2, it will encapsulate the protected service packet by an unique address Liu, et al. Expires March 2, 2012 [Page 11] Internet-Draft MPLS-TP p2mp shared protection August 2011 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 node (P) will encapsulate the service of p2mp working path 1 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 truly process the service packet from the p2p protection tunnel. . 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 March 2, 2012 [Page 12] Internet-Draft MPLS-TP p2mp shared protection August 2011 7.1. Normative References [ITU-T G.8131.1] ITU-T, "ITU-T Recommendation(PTN Linear protection)", Auguest 2011. [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 March 2, 2012 [Page 13] Internet-Draft MPLS-TP p2mp shared protection August 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 Yuefeng Ji Beijing University of Posts and Telecommunications P.O. Box 128, No.10, Xi Tu Cheng Road Beijing 100876 P.R.China Email: jyf@bupt.edu.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 Zongpeng Du Beijing University of Posts and Telecommunications Email: duzongpeng@gmail.com Liu, et al. Expires March 2, 2012 [Page 14]