MPLS Working Group G. Liu Internet-Draft J. Yang Intended status: Standards Track l. Jiang Expires: April 18, 2011 Z. Fu ZTE Corporation October 15, 2010 Multiprotocol Label Switching Transport Profile P2MP Shared Protection draft-liu-mpls-tp-p2mp-shared-protection-00 Abstract this document is used to update the former version 00 of draft-liu-mpls-tp-p2mp-share-protection-00. according to protection Requirements in RFC 5654 and draft-ietf-mpls-tp-survive-fwk WG draft. there are the following requirements : requirement 69 : MPLS-TP MUST support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources.another requirment 67B : MPLS-TP must support unidirectional 1:n protection for P2MP ,so this document will describle and provide two protection solutions to protect P2MP path when there is a failure in the p2mp path. 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 April 18, 2011 [Page 1] Internet-Draft MPLS-TP P2MP shared protection October 2010 This Internet-Draft will expire on April 18, 2011. 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. Liu, et al. Expires April 18, 2011 [Page 2] Internet-Draft MPLS-TP P2MP shared protection October 2010 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 April 18, 2011 [Page 3] Internet-Draft MPLS-TP P2MP shared protection October 2010 1. Introduction this document mainly introduces and describles individually 1:n and (1:1)^n protection solution for P2MP path, one scheme is based on extending 1:1 protection solution to implement 1:n protection by shared protection p2mp path when there may be a fault or detect in a working p2mp path.another scheme is using shared P2P protection Tunnel to protect and recovery one branch path of P2MP working path when there are some defects and failures in some branch paths of p2mp working path to implement (1:1)^n protection. and both scheme of protection and recovery can be satisfied and suitable for requirement 69 and 67B in RFC 5654; while there only have 1+1 and 1:1 protection solution for P2MP path in draft-ietf-mpls-tp-survive-fwk and draft-ietf-mpls-tp-linear-protection-01. if 1+1 protection is only used for P2MP path, it must set up a disjoint protection path for each working path, so it will add the cost of maintenancing and monitoring each path. at the same time, since the p2mp service must be transported in both working and protection path, doule bandwidth resource will be consumed for a p2mp service . so it is very necessary to consider sharing protection resource among some 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 SF:Signal Fail Liu, et al. Expires April 18, 2011 [Page 4] Internet-Draft MPLS-TP P2MP shared protection October 2010 BFD:Bidirectional Forward Detection MPLS:Multi-Protocol Label Switching MPLS-TP:Multi-Protocol Label Switching Transport Profile ME: Maintenance Entity MEP:MEG End Point ACH: Associated Channel Header 3. P2MP Shared protection solution this section mainly describles two kinds of P2MP shared protection solutions, the first solution will apply one P2MP protection path to protect n P2MP working paths which may have different root node and branch nodes or have the same root node and differenet branch nodes .when a protected P2MP path has defect , the branch node of the P2MP path will notify and coordinate the switch state by state control packet include PSC or APS etc between root node and all branch nodes. if there is no other higher priority protected P2MP path or control command to need to be protected,the defective p2mp service packet will switch into P2MP protection path to be transported. and all branch nodes of the defective P2MP path will select protection path to receive P2MP service packets. The second scheme will use P2P protection tunnel to protect defective branch path of many protected P2MP paths, when a failure or defect can happen in a branch path of P2MP working path . the branch node which has already detected the defect or failure will notify and request root node of working path or protection path about the failure message and state through in-band or out-of-band return path .so the service will switch into protection path or bridge both working path and protection path to be carried and transported.and the branch node of the defective p2mp path will select protection P2P tunnel to receive the P2MP service packet. the two p2mp shared protection solutions will implement 1;N and (1:1)^n protection, and the following section will describe the course of protection switching in detail. 3.1. 1:n protection This solution should be similar to 1:1 protection solution to use one protection path to protect more one working path. firstly the P2MP protection path will be configured and set up between the protection root node and all leaf nodes of protected P2MP paths by static Liu, et al. Expires April 18, 2011 [Page 5] Internet-Draft MPLS-TP P2MP shared protection October 2010 configuration or dynamically configuration. and root node of each working P2MP path will send detection packet to all its own branch nodes periodly. when a branch node of the p2mp path can't receive the detection packet in a fixed time. the branch node would generate failure notify message packet to notify the root node of the P2MP working path or the P2MP protection path by state control packet including PSC or APS through in-band or out-of-band return path, when the root node of P2MP working path received the failure notify message and knew some failure in one or more one branch paths of the P2MP path. so it may send protection switch requirement control packet to root node of protection path or client node. when the root node of protection path received protection switch requirement control packet from all other root nodes of defect P2MP working path or branch nodes of defect branch paths. it should be based on the priority of all protected P2MP paths and select a P2MP service which is the highest priotity among these failure paths to be protected . then the root node of protection path will generate a notify message include selected P2MP path identifier in state control packet by TLV format .the state control packet of the notify message format is as the following: . 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| MPLS-TP Channel type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + P2MP Path ID TLV + : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ State Control Packet ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 NOTE: P2MP Path ID TLV: a standard TLV frame structure. including Type , Length,and Value, and the value field may be identifier value of P2MP Liu, et al. Expires April 18, 2011 [Page 6] Internet-Draft MPLS-TP P2MP shared protection October 2010 path which must have failure and should need to be protected. this P2MP Paht ID TLV format is as the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | Length | P2MP Path Identifier value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 After the root node of protection path generates the notify message packet. it will send the State control packet to the root node of each failure p2mp working path and all leaf nodes of the P2MP protection path. the root node of each failure p2mp working path maybe receive and processe the state control packet. if the p2mp path which to be selected to be protected is local node's p2mp path, the root node will firstly send the p2mp service packet to the root node of protection path. or else, The root node won't do this. For all branch nodes of protection path, when they received and processed the state control packet. they will be based on P2MP Path Identifier value to decide whether to receive and process the service packet from p2mp protection path later.if the branch node can't be branch node of the p2mp path which to be protected , it will not process the service packet and abandon the packet. or else, it will receive and process the packet.in addtion,the root node of protection path maybe receive p2mp service directly from client node and transport them to all branch nodes of all p2mp working path which can be protected by the p2mp protection path. the implement in detail as the following figure is 1:2(n=2) protection instance. Liu, et al. Expires April 18, 2011 [Page 7] Internet-Draft MPLS-TP P2MP shared protection October 2010 +---+ +->| L1| + +---+ X @ + @ + @ +---+ +-------------+ @ +---+ | r1|+ + + + +->| P2MP Path 1 |+ + + +-> | L2 | +---+ | | @ @+---+ | +-------------+ @ @ | + @ | @ + +---+ +------------+ @ + +---+ | p |@ @ @ @ @-> | protection | @ @ @ @-> | L3| +---+ | path | $+---+ | +------------+ X | @ $ | $ @ +---+ +------------+ @ +---+ | r2|$ $ $ $-> | P2MP |$ $ $ @-> | L4| +---+ | Path 2 | +---+ +------------+ NOTE: @@@@@@: p2mp protection path +++++: p2mp working path 1 $$$$$: p2mp working path 2 X: failure Figure 3 For above p2mp network topology , there are two different p2mp services which need to be carried and transported separately by p2mp working path 1( r1-p2mp path 1-L1,L2,L3)and p2mp working path 2(r2- p2mp path 2-L3,L4) under normal state. one p2mp service will be sent and transported to branch nodes L1,L2,L3, and another p2mp service will be sent and transported to branch nodes L3,L4. and a p2mp protection path ( P-protection path-L1,L2,L3,L4) is used to protect p2mp working path 1 and p2mp working path 2 by static configuration or dynamically configuation. and the priority of p2mp working path 1 is higher than p2mp working path 2. if there is a failure in separately branch path(r1-p2mp path 1-L1) of p2mp working path 1 and branch path(r2-p2mp path 2-L3) of p2mp working path 2, branch node L1 Liu, et al. Expires April 18, 2011 [Page 8] Internet-Draft MPLS-TP P2MP shared protection October 2010 and branch node L3 will separately send control Packet of switch requirement to root node r1 and root node r2 through return path or control channel. when root node r1 and r2 received the packet from branch node L1 and L3 and processed it. and the control packet of switch requirement will be notified to the root node P of protection path . The root node P received the notify packet and processed it. 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 state control packet include path ID TLV to all branch nodes(L1,L2,L3,L4). when all branch nodes(L1,L2,L3,L4) received and processed the state control packet, As branch nodes(L1,L2,L3) is the branch nodes of p2mp working path 1, then they will be ready to receive and process the service packet from p2mp shared protection path. but branch node L4 is not the branch node of p2mp working path 1. then it will not be ready to receive and process the service packet from the p2mp protection path. and the root node r2 will continue to send their own service packets in p2mp working path 2. while the root node r1 will stop to send service packet in formerly p2mp working path 1. if the 1:n protection mechanism is revertive mode. when the failure is clear in p2mp working path 1. the root node r1 will restore back to p2mp working path 1 to transport P2MP service packet. or else, the root node r1 will not do this. 3.2. (1:1)^n protection This protection solution can use p2p protection tunnel to protect branch path of many p2mp working paths which have the same branch node . Under normal state, The root node of each p2mp working path will send p2mp service packet to its own all branch nodes by p2mp working path .in order to protect each branch path of the p2mp working path, A protection p2p LSP tunnel will be set up between source protection node and each branch node of all P2MP working path which will be protected by the P2P protection tunnel by staic configuration or dynamically configuration .and using only unique identifier value include IP multicast address,PW label etc can identify which p2mp service is tranported by protection P2P tunnel. when some branch nodes can't receive the failure detection packet from the root node of p2mp wroking path in a fixed time, it would generate failure notify packet and send it to the root node of p2mp working path and source protection node by return path or control channel. when the root node of p2mp working path received the failure notfiy packet from its own branch nodes, it will continue to send p2mp service packet in the p2mp working path. if it is necessary , it should duplicate p2mp service packet and send to source protection node. at the same time. while the source protection node received the failure notify packet, it will encapsulate the p2mp service packet Liu, et al. Expires April 18, 2011 [Page 9] Internet-Draft MPLS-TP P2MP shared protection October 2010 from client node or the root node of p2mp working path by a unique identifier value, then further be encapsulated into p2p protection tunnel to send the service packet to the branch node of failure branch path. when branch path of another p2mp working path has the failure in the same branch node at the same time, if the p2mp service packet has more priority than the former p2mp service. the former p2mp service will be stopped to be protected and the later p2mp service will be carried by the same p2p protection LSP to the branch node . it can implement to share the protection resource of P2P protection tunnel; and its max bandwidth resource is equal to max value of bandwidth resource of all protected p2mp services. the implement in detail as the following figure : there are two P2MP working path : P2MP working path LSP 1(R1-P2MP Path 1-L1,L2) and P2MP working path LSP 2(R2-P2MP Path 2-L2,L3,L4).in addtion,in order to protecting service when the failure happened in the P2MP working path, a P2P protection tunnel will be pre-configured between each branch node(L1,L2,L3,L4) and source protection node(P). and the source protection node(P) may be another p2mp service's root node, for example, in the following figure, the root node R2 of P2MP path 2 may be protection source node(P) of P2MP path 1. Liu, et al. Expires April 18, 2011 [Page 10] Internet-Draft MPLS-TP P2MP shared protection October 2010 $ +----+ $ | L1 | +-------------+ $ @ +----+ $ | P2MP Path 1 | @ $ +-------------+ $ @ $ @ $ @ +----+ $ @ $ @ | L2 | $ @ @ X +----+ +----+ @ @ # | R1 | @ +----+ @ @ X | @ | @ @ # +----+ @ @ | P | @ # +----+ @ | @ @ @ @ @ @ @ @ # @ @ +----+ # # | L3 | | @ # +----+ @ # | +-------------+ # | P2MP Path 2 |@ +----+ # +-------------+ @ | R2 | # # @ +----+ +----+ # | L4 | # +----+ 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 both have the faiure, the branch node L2 will generate failure notify packet and send to the root node (R1,R2) of P2MP working path lSP 1 and LSP 2 and source protection node(P). the root node(R1,R2) received the failure notify packet from the branch node L2, they would send failure state packet to client node or duplicate the p2mp service packet and be tranported to source protection node(P). while the source protection node(P) received the failure notify packet from Liu, et al. Expires April 18, 2011 [Page 11] Internet-Draft MPLS-TP P2MP shared protection October 2010 the branch node L2,The P2MP service packet from client node or the root node(R1,R2) of P2MP working path LSP 1 and LSP 2 will be encapsulated by two different unique identifier(IP Multicast address, pw label etc) and be trasnported through P2P protection tunnel(P-L2). The branch node L2 will select the protection path to receive service packet. and basis on the unique identifier to judge which p2mp service the service packet to be transported by P2P protection tunnel is , so that the branch node L2 can process the service packet right. when the failure is clear , the branch node L2 will stop to send failure notify packet to root node(R1,R2_and source protection node_P. and select working path to receive service packet. when the source protection node(P) have not received the failure notify packet for a fixed time. it would stop to transport service by P2P protection tunnel. 3.3. Conclusion The two kinds of p2mp protection solution will individually implement 1:n and (1:1)^n protection for P2MP service. and fulfil the requirement of unidirectional p2mp protection and sharing protection resource. but there maybe a few questions for the two protection solutions. We hope other experts provide some comments about the two protection solutions for p2mp service. 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 Malcolm Betts and other experts for provider some good comments and their input to and review of the current document. 7. References Liu, et al. Expires April 18, 2011 [Page 12] Internet-Draft MPLS-TP P2MP shared protection October 2010 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 [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, . 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 Liu, et al. Expires April 18, 2011 [Page 13] Internet-Draft MPLS-TP P2MP shared protection October 2010 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 Jiang lili ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871745 Email: jiang.lili@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 April 18, 2011 [Page 14]