MPLS Working Group G. Liu Internet-Draft J. Yang Intended status: Informational l. Jiang Expires: October 19, 2010 ZTE Corporation April 17, 2010 Multiprotocol Label Switching Transport Profile P2MP Share Protection draft-liu-mpls-tp-p2mp-share-protection-00 Abstract according to protection Requirements in RFC 5654 and draft-ietf-mpls-tp-survive-fwk WG draft, there are the following requirements : requirement 70 : The restored and protected paths must be able to share resources.another requirment 67B : MPLS-TP must support unidirectional 1:n protection for P2MP ,so this document will describle and provide two share protection solutions to protect and recovery P2MP services. and satisfied and provided unidirectional 1:n and (1:1)^n protection requirement for unidirectional P2MP serivce 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." This Internet-Draft will expire on October 19, 2010. Liu, et al. Expires October 19, 2010 [Page 1] Internet-Draft MPLS-TP P2MP share protection April 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 . . . . . . . . . . . . . . 3 3. proposed P2MP Share protection solution . . . . . . . . . . . 4 3.1. Scheme 1: 1:n protection . . . . . . . . . . . . . . . . . 5 3.2. Scheme 2: (1:1)^n protection . . . . . . . . . . . . . . . 8 3.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Liu, et al. Expires October 19, 2010 [Page 2] Internet-Draft MPLS-TP P2MP share protection April 2010 1. Introduction this document mainly introduces and describles individually 1:n and (1:1)^n protection solution for P2MP service, one scheme is based on extending 1:1 protection solution to implement 1:n protection by sharing protection resource when there are a few faults or detects in a working p2mp path.another scheme is using share P2P protection Tunnel can protect and recovery one or more one branch paths 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 70 and 67B in RFC 5654; while there only have 1+1 and 1:1 protection solution for P2MP service in draft-ietf-mpls-tp-survive-fwk and draft-ietf-mpls-tp-linear-protection-01. if 1+1 protection is only used for P2MP service, it must set up a disjoint protection path for each working path, so it will be hard and diffcult to maintenance and monitor each path. at the same time, since the p2mp service may 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 many working paths. 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. 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 Liu, et al. Expires October 19, 2010 [Page 3] Internet-Draft MPLS-TP P2MP share protection April 2010 APS:Automatic Protection Switch PSC:Protection Switching Coordination SD:Signal Degrade SF:Signal Fail 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. proposed P2MP Share protection solution this section mainly clarify two kinds of implementing P2MP share protection schemes, the first scheme will apply one P2MP protection path to protect n P2MP working paths which may have different source and sink nodes .when a working P2MP path has defect , the end nodes of P2MP will notify and coordinate the switch state by state control packet include PSC or APS. if there is no other higher priority P2MP service or control command to need to be protected and recoveryed, the defect p2mp service packet will switch into P2MP protect path to be sent. and all sink nodes of the defect P2MP path will select protection and recovery path to receive P2MP service packets. The second scheme will use P2P protect tunnel to protect defect branch path of many P2MP working paths, when a failure or defect can happened in a branch path of P2MP path . the node which can detect the defect or failure will notify and request root node of working path or peer node of 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 leaf node of the defect branch path will select protection P2P tunnel to receive the P2MP service packet. the two schemes of P2MP protection will implement 1;N and (1:1)^n protection, and the following section will describe the course of protection switching in detail. Liu, et al. Expires October 19, 2010 [Page 4] Internet-Draft MPLS-TP P2MP share protection April 2010 3.1. Scheme 1: 1:n protection This solution should be similar to 1:1 protection solution to use one protection path to protect many working paths. 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 configuration or dynamically configuration. and root node of each working P2MP path will send detection packet to all its own leaf nodes periodly. when a leaf node of branch path can't receive the detection packet in a fixed time. the leaf 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. when the root node of protection path received protection switch requirement control packet from all other root nodes of defect P2MP working path or leaf 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 Liu, et al. Expires October 19, 2010 [Page 5] Internet-Draft MPLS-TP P2MP share protection April 2010 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 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 service, 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 leaf 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 in the future.if the leaf node can't be sink node of the p2mp service 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 still received p2mp service directly from client node. the implement in detail as the following figure is 1:2(n=2) protection instance. Liu, et al. Expires October 19, 2010 [Page 6] Internet-Draft MPLS-TP P2MP share protection April 2010 +---+ +->| L1| + +---+ X @ + @ + @ +---+ +-------------+ @ +---+ | r1|+ + + + +->| P2MP Path 1 |+ + + +-> | L2 | +---+ | | @ @+---+ | +-------------+ @ @ | + @ | @ + +---+ +------------+ @ + +---+ | p |@ @ @ @ @-> | protection | @ @ @ @-> | L3| +---+ | path | $+---+ | +------------+ X | @ $ | $ @ +---+ +------------+ @ +---+ | r2|$ $ $ $-> | P2MP |$ $ $ @-> | L4| +---+ | Path 2 | +---+ +------------+ NOTE: @@@@@@: p2mp protection path +++++: p2mp service 1 working path $$$$$: p2mp service 2 working path X: failure Figure 3 For above p2mp topology structure, 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 leaf node L1,L2,L3, and another p2mp service will be sent and transported to leaf node 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, leaf node L1 and leaf node L3 Liu, et al. Expires October 19, 2010 [Page 7] Internet-Draft MPLS-TP P2MP share protection April 2010 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 leaf node L1 and L3 and processed it. and the information of failure path 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 leaf nodes(L1,L2,L3,L4). when all leaf nodes(L1,L2,L3,L4) received and processed the state control packet, As Leaf nodes(L1,L2,L3) is the leaf nodes of p2mp working path 1, then they will be ready to receive and process the service packet from protection path. but leaf node L4 is not the leaf node of p2mp working path 1. then it will not be ready to receive and process the service packet from 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 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. Scheme 2: (1:1)^n protection This protection solution can use p2p protection tunnel to protect branch path of many p2mp working paths.and these branch paths have the same leaf node . Under normal state, The root node of each p2mp working path will send p2mp service packet to its own all leaf 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 leaf 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 leaf nodes didn'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 leaf 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 from client node or the root node of p2mp working path by a unique Liu, et al. Expires October 19, 2010 [Page 8] Internet-Draft MPLS-TP P2MP share protection April 2010 identifier value, then further be encapsulated into p2p protection tunnel to send the service packet to the leaf node of failure branch path. when branch path of another p2mp working path has the failure in the same leaf node at the same time, another p2mp service packet will be carried by the same p2p protection LSP to the leaf node too. it can implement to share the protection resource of P2P protection tunnel; and the max bandwidth resource is equal to sum 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,for protecting and recoverying service when the failure happened in the P2MP working path, a P2P protection tunnel will be pre-configured between each leaf node(L1,L2,L3,L4) and source protection node(P). Liu, et al. Expires October 19, 2010 [Page 9] Internet-Draft MPLS-TP P2MP share protection April 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 leaf 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 leaf node L2, they would send failure state packet to client node or duplicate the p2mp service packet and tranport to source protection node(P). while the source protection node(P) received the failure notify packet from the Liu, et al. Expires October 19, 2010 [Page 10] Internet-Draft MPLS-TP P2MP share protection April 2010 leaf 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 leaf 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 by P2P protection tunnel is , so that the leaf node L2 can process the service packet right when the failure is clear , the leaf 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 through 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 October 19, 2010 [Page 11] Internet-Draft MPLS-TP P2MP share protection April 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. 7.2. Informative References [MPLS-TP Framework] M. Bocci, S. Bryant, L. Levrau,D. Frost, L. Berger , "A Framework for MPLS in Transport Networks", February 2010. [MPLS-TP Linear protection] S. Bryant, N. Sprecher, H. van Helvoort,A. Fulignoli Y. Weingarten, "MPLS transport profile Linear Protection", March 2010. [MPLS-TP Survivability Framework] N. Sprecher, A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", March 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 October 19, 2010 [Page 12] Internet-Draft MPLS-TP P2MP share protection April 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 Liu, et al. Expires October 19, 2010 [Page 13]