MPLS Working Group G. Liu Internet-Draft ZTE Corporation Intended status: Informational March 13, 2013 Expires: September 14, 2013 Applicability of MPLS-TP Linear protection for p2mp draft-liu-mpls-tp-p2mp-linear-protection-01 Abstract In MPLS-TP requirement document(rfc5654), there is a requirement to support 1+1 and 1:n protection for p2mp connectivity. The requirement was described in MPLS-TP Survivability Framework document(RFC 6372) and draft-ietf-mpls-tp-p2mp-framework. The basic protocol for linear protection was specified in the MPLS-TP Linear Protection document [RFC 6378] but is limited to 1+1 and 1:1 protection for p2p connectivity. in addtion, The 1:N protection in which all of working transport paths and the protection path have the same end points was specified in MPLS-TP 1:N protection document (draft-ietf-mpls-tp-1toN-protection).This document applies the existing PSC(RFC 6378) and extensive PSC protocol(draft-ietf-mpls-tp- 1toN-protection) to support scenarios of protecting the p2mp path by extending the existing p2p linear protection mechanism. . 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. 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 Expires September 14, 2013 [Page 1] Internet-Draft MPLS-TP P2MP Linear protection March 2013 This Internet-Draft will expire on September 14, 2013. Copyright Notice Copyright (c) 2013 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. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 1+1 p2mp protection . . . . . . . . . . . . . . . . . . . 3 1.2. 1:1 p2mp per-tree protection . . . . . . . . . . . . . . 4 1.3. 1:1 p2mp per-leaf protection . . . . . . . . . . . . . . 5 1.4. 1:1 p2mp branch path protection . . . . . . . . . . . . . 5 1.5. 1:n p2mp shared protection . . . . . . . . . . . . . . . 6 2. Conventions used in this document . . . . . . . . . . . . . . 7 3. Coordination protocol . . . . . . . . . . . . . . . . . . . . 8 4. Switch Procedure . . . . . . . . . . . . . . . . . . . . . . 8 4.1. 1+1 protection operation . . . . . . . . . . . . . . . . 9 4.2. 1:1 p2mp per-tree protection operation . . . . . . . . . 9 4.3. 1:1 p2mp per-leaf protection operation . . . . . . . . . 9 4.4. 1:1 p2mp branch path protection operation . . . . . . . . 10 4.5. 1:n p2mp shared protection operation . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.3. URL References . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Liu Expires September 14, 2013 [Page 2] Internet-Draft MPLS-TP P2MP Linear protection March 2013 The MPLS Transport Profile(MPLS-TP) Requirement document(RFC5654) and MPLS-TP P2MP Framework document both describe the requirement that unidirectional 1+1 and 1:n protection for p2mp connectivity must be supported. while the MPLS-TP Survivability Framework(RFC6372) is only a framework for survivability in MPLS-TP network. MPLS-TP Linear protection document(RFC6378) defines a Protection State Coordination(PSC) protocol that supports 1+1 and 1:1 protection architectures descirbed in MPLS-TP Survivability Framework. The PSC protocol is a single-phase protocol that allows the two endpoints of the protection domain to coordinate the protection switching operation when a change of state is detected on the transport path of the protection domain. MPLS-TP 1:N protection document(draft-ietf-mpls-tp-1toN-protection) uses a two-phase extensive PSC protocol to protect multiple working paths by a single protection path. As for the p2mp path, It has multiple leaf nodes and is still undirectional, so it is not good for p2mp path to use the protection mechanism in RFC6378 and draft-ietf-mpls-tp-1toN-protection. The document is an applicability of the existing PSC protocol and the extensive PSC protocol to support protection of p2mp path by extending the existing linear protection mechanism. 1.1. 1+1 p2mp protection This protection is a specific protection that use one designated protection path to protect one working path. It is fully pre- allocated in the sense that the route and bandwidth resource of the protection path is reserved for the working path, The source root node will bridge both the working path and the protection path at the same time. while the sink leaf nodes will select one of the two paths to receive the traffic . As it is unnecessary to coordinate the switch state between the root node and the leaf nodes , the PSC protocol is not needed in the 1+1 protection mechanism. +---+ +| L1| + +---+ + @ + @ + @ +---+ +-------------+ @ | r |+ + + + +->| woking path | @ Liu Expires September 14, 2013 [Page 3] Internet-Draft MPLS-TP P2MP Linear protection March 2013 +---+ | | @ @ +-------------+ @ @ + @ @ + @ +------------+ + +---+ @ | protection | @ @ @ @ | L2| @ | path | +---+ +------------+ NOTE: @@@@@@: p2mp protection path +++++: p2mp working path Figure 1: 1+1 p2mp protection Figure 1 shows a protection domain with one working path and its corresponding protection path.For 1+1 protection mechanism, the p2mp traffic must be transported on both working path and protection path at any time. So the source root node always bridges the p2mp traffic into both working path and protection path. While the sink leaf node L1 and L2 will select one of the two paths to receive the traffic based on the performance of the two paths. It isn't necessary to coordinate the switch state between the source root node and the sink leaf nodes. So it can't use the PSC protocol for the protection mechanism; 1.2. 1:1 p2mp per-tree protection The protection mechanism will still use one designated p2mp protection path to protect one p2mp working path.While the source root node only bridges one of the two paths at any time. All sink leaf nodes select the same p2mp path to receive the traffic. In addition, As the root node and leaf nodes need to coordinate to select the same p2mp path to send and receive the p2mp traffic. it Must use the existing PSC protocol to coordinate the switch state between the root node and the leaf nodes. Just as the above figure 1, Under normal condition, The p2mp traffic will be transported by only the working path from node r to node L1 and L2. When a defect is detected on the working path. the source Liu Expires September 14, 2013 [Page 4] Internet-Draft MPLS-TP P2MP Linear protection March 2013 node r will bridge the traffic into its corresponding protection path. Then it should send PSC packet to all leaf nodes L1 and L2 to notify them to select the protection path to receive the p2mp traffic. 1.3. 1:1 p2mp per-leaf protection This protection is similar to the above protection mechanism.It still needs to pre-configure one p2mp protection path to protect a p2mp working path. When a defect is detected on the working path. the source root node firstly bridge both the working path and the protection path to send the traffic on both paths. While the leaf nodes will select one of the two paths to receive the traffic based on whether the working path has defect. Here it is unnecessary to use PSC protocol to coordinate the switch state between the root node and the leaf nodes. Just as the above figure 1,When a defect is detected on one branch path of the p2mp working path, For example, Path(r-L1) or path(r-L2) has a defect, The source root node r will firstly send the traffic on both the working path and the protection path. L1 or L2 will select one of the two paths to receive the traffic based on whether to have a defect on its branch path(r-L1) or path(r-L2).. 1.4. 1:1 p2mp branch path protection The protection mechanism will pre-configure one p2p protection path for each branch path of a p2mp working path. Each branch path is disjointed from its p2p protection path. The protection mechanism is similar to 1:1 protection mechanism in MPLS-TP linear protection(RFC3678), It needs to use the PSC protocol to coordinate the switch state between the root node and the leaf nodes. +---+ @ @ @ @ @ @ | L1| @ ++---+ @ + @ + @ + +---+ @ +-------------+ | r |+ + + + +->| woking path | +---+ | | @ +-------------+ @ + @ + @ + +---+ Liu Expires September 14, 2013 [Page 5] Internet-Draft MPLS-TP P2MP Linear protection March 2013 @ + | L2| @ @ @ @ +---+ NOTE: @@@@@@: p2p protection path +++++: p2mp working path Figure 2 Just as the above figure 2, It will pre-configure one p2p protection path for each branch path(r-L1) and (r-L2) individually.When a defect is detected on the branch path. the root node r will send PSC packet to its peer leaf node L1 or L2 immediately , Then the protected traffic will be switched into its p2p protection path to be transported. While the leaf node L1 or L2 will select the protection path to receive the traffic 1.5. 1:n p2mp shared protection The protection will pre-configure one p2mp shared protection path to protect multiple p2mp working paths which maybe have differnet end points. So the leaf nodes of the p2mp shared protection path are all leaf nodes of these protected p2mp working paths.When a defect is deteced on a working path, the root node of the protection path will send the existing extensive PSC protocol packet to its leaf nodes to identify which p2mp working path will be selected to be protected. When the leaf node receives the PSC packet and decides how to process the traffic packet from the p2mp shared protection path.Just as figure 3. +---+ +->| L1| + +---+ + @ + @ + @ +---+ +-------------+ @ Liu Expires September 14, 2013 [Page 6] Internet-Draft MPLS-TP P2MP Linear protection March 2013 | r |+ + + + +->| P2MP path 1 | @ +---+ | | @ $ @ +-------------+ @ @ + $ @ @ + @ +------------+ + +---+ $ @ | protection | @ @ @ @-> | L2| @ | path | $+---+ $ +------------+ $ @ $ $ @ +------------+ $ @ +---+ $ | P2MP |$ $ $ @-> | L3| $ | Path 2 | +---+ +------------+ NOTE: @@@@@@: p2mp shared protection path +++++: p2mp working path 1 $$$$$: p2mp working path 2 Figure 3 A single p2mp shared protection path is used to protect p2mp working path 1 and p2mp working path 2. node L1 and L2 are the sink leaf nodes of the p2mp working path 1. While node L2 and L3 are the sink leaf nodes of the p2mp working path 2. The leaf nodes of the p2mp shared protection path are L1 , L2 and L3.When a defect is detected on both the working path 1 and the working path 2 at the same time. The root node r of the p2mp shared protection path will select a higher priority working path to be protected. Then the source root node sends extensive PSC protocol packet to all leaf nodes L1,L2 and L3 by the p2mp shared protection path.The leaf nodes L1,L2 and L3 can judge whether to receive the traffic from the protection path based on the extensive PSC protocol packet. 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. Liu Expires September 14, 2013 [Page 7] Internet-Draft MPLS-TP P2MP Linear protection March 2013 OAM: Operations, Administration, Maintenance LSP: Label Switched Path. TLV: Type Length Value P2MP:Point to Multi-Point P2P:Point to Point PSC:Protection State Coordination SD:Signal Degrade SF:Signal Fail NR No Request MPLS:Multi-Protocol Label Switching MPLS-TP:Multi-Protocol Label Switching Transport Profile 3. Coordination protocol Some protection mechanisms in this document need PSC protocol to coordinate switch state between end points of a protection domain. It will use the existing PSC protocol to be defined in MPLS-TP Linear protection(RFC6378) in the 1:1 p2mp protection scenario including 1:1 p2mp per-tree protection , 1:1 P2MP branch path protection. The PSC protocol in detail maybe reference to the MPLS-TP linear protection(RFC6378). While 1:n shared p2mp protection may use the extensive PSC protocol defined in the MPLS-TP 1:N protection(draft- ietf-mpls-tp-1ton-protection) to implement the protection.So the procedure of extensive PSC protocol maybe reference to the mpls-tp 1:N protection document. But the 1:n shared p2mp protection in this document only uses single-phase protocol which is different from the 1:n protection for p2p path. And it is only non-locking operation and the value of L field can't be set. In addition, It is unnecessary for the protection mechanism to wait for peer node's Acknowledge(WFA), So the parameter of WFA timer isn't necessary in this document. 4. Switch Procedure Liu Expires September 14, 2013 [Page 8] Internet-Draft MPLS-TP P2MP Linear protection March 2013 In all above protection mechanisms, They must firstly pre-configure protection path for one or multiple p2mp working path. Then They detect whether to have a defect on the working path. If a defect is detected, the end point of the p2mp working path will swich the traffic from its working path to its pre-configurated protection path 4.1. 1+1 protection operation The procedure of 1+1 protection operation is the following : 1 Under normal condition, The root node bridges the protected p2mp traffic into its working path and protection path, While its sink leaf nodes will select the working path to receive the traffic. 2 A defect is detected on the working path, some leaf nodes will select its protection path to receive the traffic packet which have defect on their branch path.of the working path 4.2. 1:1 p2mp per-tree protection operation The procedure of this protection switch is the following phase: 1 Under normal condition, The root node and leaf nodes will send or receive the traffic by their working path.And the root node will send NR(0,0) to all leaf nodes by PSC packet. 2 When a defect is already detected on the working path, the root node will bridge from the working path to its corresponding protection path. Then send SF(1,1) to all leaf nodes by PSC packet.. 3 The leaf nodes receive the SF(1,1) PSC packet, All of them will switch to receive the traffic by their protection path. 4.3. 1:1 p2mp per-leaf protection operation The procedure of the protection is the following : 1 The root node will select its working path to send the traffic under normal condition ,And each leaf node still selects the working path to receive the traffic. 2 When a defect is detected on a branch path of the p2mp working path. the root node will bridge both the working path and the protection path . The leaf node will select one of the two paths to receive the traffic based on whether a defect happens on the working path. Liu Expires September 14, 2013 [Page 9] Internet-Draft MPLS-TP P2MP Linear protection March 2013 3 If a leaf node detect a defect on its branch path of the p2mp working path, IT will select its corresponding protection path to receive the p2mp traffic packet. or else, it will continue to receive the p2mp traffic packet from its working path. 4.4. 1:1 p2mp branch path protection operation The procedure of the protection operation is the following : 1 Under normal condition, The root node and all leaf nodes of a p2mp traffic will select their p2mp working path to send and receive the traffic. At the same time, The root node sends NR(0,0) PSC packet to each leaf node by its p2p protection path periodically. 2 When a defect is detected on a branch path of the p2mp working path, The root node will bridge the traffic into its corresponding p2p protection path and send SF(1,1) PSC packet to the leaf node of the failed branch path. 3 The leaf node receives SF(1,1) PSC packet,It will switch from the working path to the p2p protection path to receive the traffic.Other leaf nodes will still receive the traffic from the working path. 4.5. 1:n p2mp shared protection operation the procedure of this protection operation is the following : 1 Under normal condition, The root node and all leaf nodes will select their p2mp working path to send and receive the traffic, The root node sends NR(0,0) PSC packet to all leaf nodes of the p2mp protection path periodically. 2 A defect is detected on one or multiple p2mp working path , The root node will select the highest priority working path to be protected.and send SF(n,n) to all leaf nodes of the shared protection path. Here n indicates the identifier index of the p2mp working path to be protected.At the same time, The root node begin to send the traffic to be selected on the p2mp shared protection path. 3 When all leaf nodes of the p2mp shared protection path receive SF(n,n) PSC packet. they will know whether to receive the traffic from the p2mp shared protection path. If a leaf node is a sink node of the p2mp working path to be protected, it will receive the traffic from the shared protection path. or else, It directly abandon the traffic from the p2mp shared protection path. 5. Security Considerations Liu Expires September 14, 2013 [Page 10] Internet-Draft MPLS-TP P2MP Linear protection March 2013 TBD 6. IANA Considerations TBD 7. Acknowledgments TBD 8. References 8.1. Normative References [RFC5654] IETF, "IETF RFC5654(MPLS-TP requirement) ", September 2009. [RFC5921] IETF, "IETF RFC5654(MPLS-TP framework) ", July 2010. [RFC6372] IETF, "MPLS Transport Profile (MPLS-TP) Survivability Framework ", September 2011. [RFC6378] IETF, "MPLS Transport Profile (MPLS-TP) Linear Protection ", November 2011. 8.2. Informative References [draft-ietf-mpls-tp-1ton-protection-00] E. Osborne, F. Zhang, Y. Weingarten, , "MPLS-TP 1toN Protection ", August 2012. [draft-ietf-mpls-tp-p2mp-framework-00] D. Frost, S. Bryant,M. Bocci, L. Berger, , "A Framework for Point-to-Multipoint MPLS in Transport Networks", January 2013. 8.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, 2008, . Author's Address Liu Expires September 14, 2013 [Page 11] Internet-Draft MPLS-TP P2MP Linear protection March 2013 Guoman Liu ZTE Corporation No.50, Ruanjian Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 88014227 Email: liu.guoman@zte.com.cn Liu Expires September 14, 2013 [Page 12]