MPLS Working Group G. Liu Internet-Draft ZTE Corporation Intended status: Informational September 11, 2012 Expires: March 15, 2013 Applicability of MPLS-TP Linear protection for p2mp draft-liu-mpls-tp-p2mp-linear-protection-00 Abstract In MPLS-TP requirement document(rfc5654), there is a requirement to support 1+1 and 1:n linear protection for p2mp connectivity. The requirement was descirbled in MPLS-TP Survivability Framework document(RFC 6372). 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. 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 Liu Expires March 15, 2013 [Page 1] Internet-Draft MPLS-TP P2MP Linear protection September 2012 material or to cite them other than as "work in progress." This Internet-Draft will expire on March 15, 2013. Copyright Notice Copyright (c) 2012 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 Expires March 15, 2013 [Page 2] Internet-Draft MPLS-TP P2MP Linear protection September 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 1+1 p2mp protection . . . . . . . . . . . . . . . . . . . 4 1.2. 1:1 p2mp per-tree protection . . . . . . . . . . . . . . . 5 1.3. 1:1 p2mp per-leaf protection . . . . . . . . . . . . . . . 6 1.4. 1:1 p2mp branch path protection . . . . . . . . . . . . . 6 1.5. 1:n p2mp shared protection . . . . . . . . . . . . . . . . 7 2. Conventions used in this document . . . . . . . . . . . . . . 9 3. Coordination protocol . . . . . . . . . . . . . . . . . . . . 9 4. switch operation . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. 1+1 protection operation . . . . . . . . . . . . . . . . . 10 4.2. 1:1 p2mp per-tree protection operation . . . . . . . . . . 10 4.3. 1:1 p2mp per-leaf protection operation . . . . . . . . . . 11 4.4. 1:1 p2mp branch path protection operation . . . . . . . . 11 4.5. 1:n p2mp shared protection operation . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.3. URL References . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Liu Expires March 15, 2013 [Page 3] Internet-Draft MPLS-TP P2MP Linear protection September 2012 1. Introduction The MPLS Transport Profile(MPLS-TP) Requirement document(RFC5654) and MPLS-TP P2MP Framework document both describle the requirement that unidirectional 1+1 and 1:n protection for p2mp connectivity must be supported. while the MPLS-TP Survivability Framework(RFC6372) is a framework for survivability in MPLS-TP network. MPLS-TP Linear protection document(RFC6378) defines a Protection State Coordination(PSC) protocol that supports the different 1+1 and 1:1 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 domain to coordinate the protection switching operation when a switching condition is detected on the transport paths 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 mechnism 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 allocated in the sense that the route and bandwidth resource of the protection path is reserved for the working path.under any condition, 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. Liu Expires March 15, 2013 [Page 4] Internet-Draft MPLS-TP P2MP Linear protection September 2012 +---+ +| L1| + +---+ + @ + @ + @ +---+ +-------------+ @ | r |+ + + + +->| woking path | @ +---+ | | @ @ +-------------+ @ @ + @ @ + @ +------------+ + +---+ @ | protection | @ @ @ @ | L2| @ | path | +---+ +------------+ NOTE: @@@@@@: p2mp protection path +++++: p2mp working path Figure 1 Figure 1 shows a protection domain with one working path and its corresponding protection path.for 1+1 protection, the protection path must transport the p2mp traffic at any time. so the source root node always bridges the p2mp traffic into both the working path and the 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.As it is no sense to coordinate the switch state between the source root node and the sink leaf nodes. it can't apply the PSC protocol for the protection mechanism; 1.2. 1:1 p2mp per-tree protection The protection will still use one designated p2mp protection path to protect one p2mp working path.but 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 Liu Expires March 15, 2013 [Page 5] Internet-Draft MPLS-TP P2MP Linear protection September 2012 and leaf nodes need to coordinate to select the same p2mp path to send and receive the p2mp traffic. it may apply 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 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 node r will bridge the traffic into the p2mp protection path. then it should send PSC packet to all leaf nodes L1 and L2 in order to coordinate to select the p2mp protection path to send and receive the p2mp traffic. 1.3. 1:1 p2mp per-leaf protection The protection is similar to the above protection mechanism.it need to pre-configure one p2mp protection path to protect the 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.As the source root node bridge two paths after a defect is detected on the working path, 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 path 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 will pre-configure one p2p protection path to protect each branch path of the p2mp working path. and each branch path is disjointed from its p2p protection path. the protection mechanism is the same as 1:1 protection in MPLS-TP Linear protection(RFC3678), and it needs to use the PSC protocol to coordinate the switch state between the root node and the leaf nodes. Liu Expires March 15, 2013 [Page 6] Internet-Draft MPLS-TP P2MP Linear protection September 2012 +---+ @ @ @ @ @ @ | L1| @ ++---+ @ + @ + @ + +---+ @ +-------------+ | r |+ + + + +->| woking path | +---+ | | @ +-------------+ @ + @ + @ + +---+ @ + | L2| @ @ @ @ +---+ NOTE: @@@@@@: p2p protection path +++++: p2mp working path Figure 2 just as the above figure 2, firstly it pre-configures 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 switch into its p2p protection path to transport the traffic. while the leaf node L1 or L2 will select the protection path to receive the traffic .but for the protection mechnism, the more the leaf nodes are, the more its p2p protection paths are pre- configured. 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 Liu Expires March 15, 2013 [Page 7] Internet-Draft MPLS-TP P2MP Linear protection September 2012 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 all the leaf nodes receive the PSC packet and decide how to process the traffic packet from the p2mp shared protection path.just as figure 3. +---+ +->| L1| + +---+ + @ + @ + @ +---+ +-------------+ @ | 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 the p2mp working path 1 and the p2mp working path 2. node L1 and L2 are the Liu Expires March 15, 2013 [Page 8] Internet-Draft MPLS-TP P2MP Linear protection September 2012 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.so the leaf nodes of the p2mp shared protection path are node 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 the higher priority working path to be protected. then it sends extensive PSC protocol packet to all leaf nodes L1,L2 and L3 by the p2mp shared protection path.Then 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. 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 to PSC protocol to coordinate the switch state between the end-points of a protection domain. in order to gain to consistent solution for this coordination between the end-points of the protection domain. it will apply the existing PSC protocol to be defined in MPLS-TP Linear Liu Expires March 15, 2013 [Page 9] Internet-Draft MPLS-TP P2MP Linear protection September 2012 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. while the 1:n shared p2mp protection only use single-phase protocol which is different from the 1:n protection for p2p path. so it is only non-locking operation and the value of L field can't be set. in addtion, it is unnecessary for the protection to wait for peer node's Acknowledge(WFA), so the parameter of WFA timer isn't necessary in this document. 4. switch operation In all of the above protection mechanism, Firstly it must pre- configure protection path to protect one or multiple p2mp working path. then it detects whether to have a defect on the working path. if a defect is detected, then the end point of the p2mp working path will swich the traffic from the working path to the protection path 4.1. 1+1 protection operation The procedure of 1+1 protection operation is the following in detail: 1 Under normal condition, the root node bridges the p2mp traffic into the working path and the protection path, while its leaf nodes will select the p2mp working path to receive the traffic. 2 a defect is detected on the working path, some leaf nodes will select the protection path to receive the traffic which has defect on the branch 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 and receive the traffic from the working path.the root node will send NR(0,0) to all leaf nodes by the protection path. 2 when a defect is already detected on the working path, the root node will bridge from the working path to the protection path. then send SF(1,1) to all leaf nodes by the protection path. 3 The leaf nodes receive the SF(1,1), All of them will switch into Liu Expires March 15, 2013 [Page 10] Internet-Draft MPLS-TP P2MP Linear protection September 2012 the protection path to receive the traffic. 4.3. 1:1 p2mp per-leaf protection operation The procedure of the protection is the following in detail: 1 under normal condition, the root node will select the working path to send the traffic,and the leaf node select the working path to receive the traffic. 2 when a defect is already detected on the branch path of the p2mp working path. the root node will bridge both the working path and the protection path . the sink node will select one of the two paths to receive the traffic based on whether a defect happens on the working path. 4.4. 1:1 p2mp branch path protection operation The procedure of the protection operation is the following in detail: 1 under normal condition, the root node and all leaf nodes will select the p2mp working path to send and receive the traffic. and the root node sends NR(0,0) to each leaf node by its p2p protection path. 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) to the leaf node of the branch path. 3 The leaf node receives the SF(1,1) packet, then 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 the p2mp working path to send and receive the traffic, the root node sends NR(0,0) to all leaf nodes of the p2mp protection path periodcally. 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 the leaf nodes of the protection path.here n indicates the index of the p2mp working path to be protected.at the same time, the root node begin to send the traffic Liu Expires March 15, 2013 [Page 11] Internet-Draft MPLS-TP P2MP Linear protection September 2012 to be selected on the p2mp shared protection path. 3 when all leaf nodes of the p2mp shared protection path receive the SF(n,n) packet. they will know whether or not to receive the traffic from the p2mp shared protection path based on SF(n,n) packet. if a node is a leaf node of the p2mp working path to be protected, it will receive the traffic , or not, it directly abandon the traffic from the p2mp shared protection path. 5. Security Considerations TBD 6. IANA Considerations TBD 7. Acknowledgments TBD 8. References 8.1. Normative References [RFC 5654] IETF, "IETF RFC5654(MPLS-TP requirement)", September 2009. [RFC 5921] IETF, "IETF RFC5654(MPLS-TP framework)", July 2010. [RFC 6372] IETF, "MPLS Transport Profile (MPLS-TP) Survivability Framework", September 2011. [RFC 6378] 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. Liu Expires March 15, 2013 [Page 12] Internet-Draft MPLS-TP P2MP Linear protection September 2012 8.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, "", 2008, . Author's Address 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 March 15, 2013 [Page 13]