MPLS Working Group G. Liu Internet-Draft J. Yu Intended status: Informational X. Tu Expires: July 2, 2012 X. Xu ZTE Corporation December 30, 2011 p2mp pw protection for mpls-tp network draft-liu-pwe3-mpls-tp-p2mp-pw-protection-00 Abstract According to one protection Requirement in RFC 5654, Requirement 63 :It MUST be possible to provide protection for the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. and it requires mpls-tp date plane should be independent of its control plane. so it is necessary for the 1:1 protection of p2mp pw to have a return path to coordinate the switch state between root node and each leaf node. for the above problem statement, the document provides a solution to protect p2mp pw by using one leaf node as protector for another leaf node. so it may avoid setting up a return path for each leaf node. This document is a product of a joint Internet 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 July 2, 2012 [Page 1] Internet-Draft p2mp pw protection for mpls-tp network December 2011 This Internet-Draft will expire on July 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 July 2, 2012 [Page 2] Internet-Draft p2mp pw protection for mpls-tp network December 2011 Table of Contents 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . . 4 3. protection solution . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Liu, et al. Expires July 2, 2012 [Page 3] Internet-Draft p2mp pw protection for mpls-tp network December 2011 1. Problem statement according to mpls-tp requirement(RFC 5654), it requires mpls-tp data plane is independent of control plane. it means that mpls-tp data plane can still work without control plane or under the condition of failure on the control plane. at the same time, mpls-tp data plane can forward traffic packet without any IP forwarding capability.so it must be essential for uni-directional path including p2p or p2mp pw to set up a return path between two end nodes in order to communicate and associate between the two end nodes. so it needs to set up more return paths for p2mp pw, it will need more configuration and maintenece cost. so the document provide one protection solution for p2mp pw under the condition without return path,IP forwarding capability and control plane. 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. PW: Pseudowire P2MP:Point to Multi-Point P2P:Point to Point PSC:Protection Switching Coordination CE:Customer Equipment LER:Label Edge Router LSR:Label Switch Router PSN:Packet Switch Network MPLS-TP:Multi-Protocol Label Switching Transport Profile ME: Maintenance Entity MEP:MEG End Point Liu, et al. Expires July 2, 2012 [Page 4] Internet-Draft p2mp pw protection for mpls-tp network December 2011 ACH: Associated Channel Header CC-V: Contunuity Check-Verification; 3. protection solution This section will describle the protection solution for p2mp pw in detail,which use one leaf node as protector node of another leaf node. and the two leaf nodes is backup for each other.in addtion, in order to be easy to access to CE node, it should set up backup node to directly access to CE node. if backup node is still a leaf node of the p2mp pw, protector node and backup node are the same node. at the same time, it should set up a bidirectional p2p pw between protected node, backup node and protector node .just as the following figure 1: ___ ___ ___ */LSR\ ********* /LER\********** /CE1\ * \ A / \_1_/ + \___/ __ * - - + + /LER\* . _+_ + /LER\+ \_O_/* . \_2_/+ * . + + * ___ _+_ + ___ * /LSR\ /LER\ + /CE3\ * \ B / ********** \_3_/*********** \___/ - - ***** working pw +++++ protection pw Figure 1 LER 0 is the root node of the p2mp pw, LER 1 and LER 3 are leaf nodes of the p2mp pw. LER 2 is backup node for LER 1 and LER 3. when protected node LER 1 or LER 3 has the failure, backup node LER 2 will replace of protected node LER 1 or LER 3 to transmit traffic packet to CE1 or CE3. for CE1 or CE3 node, if it detect a failure on its working access link(*), it will select protection access link(+) to receive the traffic.for example, just as the following figure 2: Liu, et al. Expires July 2, 2012 [Page 5] Internet-Draft p2mp pw protection for mpls-tp network December 2011 ___ ___ ___ */LSR\ ********* /LER\****X***** /CE1\ * \ A / \_1_/ + \___/ __ * - - X + /LER\* . _+_ + /LER\+ \_O_/* . \_2_/+ * . + + * ___ _+_ + ___ * /LSR\ /LER\ + /CE3\ * \ B / ********** \_3_/*********** \___/ - - ***** working pw +++++ protection pw X failure Figure 2 if the LER 1 has the failure, CE1 and LER 2 MUST detect the failure by OAM or other function. then LER 2 will notify protector node LER 3 of the failure by pw status message[1]. then LER 3 will begin to duplicate the service packet of the p2mp pw to transmit to LER 2 by pre-configured p2p protection pw. then the LER 2 send the service packet of the p2mp pw to CE1 by protection access link(LER2-CE1).and CE1 detects the failure on its working access link(LER1-CE1), it must switch to protection access link(LER2-CE1) to receive the service. at the same time, if another protected node LER3 has the failure, it may use the same method to protect the failure of LER3. when there is only the failure on the working access link just as the following figure 3: Liu, et al. Expires July 2, 2012 [Page 6] Internet-Draft p2mp pw protection for mpls-tp network December 2011 ___ ___ ___ */LSR\ ********* /LER\****X***** /CE1\ * \ A / \_1_/ + \___/ __ * - - + + /LER\* . _+_ + /LER\+ \_O_/* . \_2_/+ * . + + * ___ _+_ + ___ * /LSR\ /LER\ + /CE3\ * \ B / ********** \_3_/*********** \___/ - - ***** working pw +++++ protection pw X failure Figure 3 when CE1 and LER1 detect a failure on the working access link(LER1- CE1), LER1 firstly notify backup node LER2 of the egress AC failure by pw status message. then LER1 will send the service packet of the p2mp pw to LER2 by protection pw between LER1 and LER2. and LER2 will transmit the service packet of the p2mp pw to CE1 by protection access link(LER2-CE1). at the same time, CE1 will switch to protection access link(LER2-CE1) to receive the service packet. when the protected node detects a failure on its working pw , it will notify the failure of its backup node or protector node. so that the backup node will transmit the service packet of the p2mp pw to the protected node.it is just as the following figure 4: Liu, et al. Expires July 2, 2012 [Page 7] Internet-Draft p2mp pw protection for mpls-tp network December 2011 ___ ___ ___ */LSR\ *****X**** /LER\********* /CE1\ * \ A / \_1_/ + \___/ __ * - - + + /LER\* . _+_ + /LER\+ \_O_/* . \_2_/+ * . + + * ___ _+_ + ___ * /LSR\ /LER\ + /CE3\ * \ B / ********** \_3_/*********** \___/ - - ***** working pw +++++ protection pw X failure Figure 4 when the failure happens on the branch working path(LER0-LSR A-LER 1), the protector node LER1 will notify the failure message of the backup node LER2 or protector node LER3. and then LER2 or LER3 receives the failure message from LER1 ,LER3 will duplicate the service packet of the p2mp pw to transmit it to backup node LER2 firstly. then LER2 continue to transmit the service packet of the p2mp pw to the protector node LER1. at last LER1 will transmit it to CE1 by its working access link(LER1-CE1). 4. Security Considerations TBD 5. IANA Considerations TBD. 6. Acknowledgments TBD . 7. References Liu, et al. Expires July 2, 2012 [Page 8] Internet-Draft p2mp pw protection for mpls-tp network December 2011 7.1. Normative References [RFC 5654] IETF, "IETF RFC5654(MPLS-TP requirement)", September 2009. [RFC 5921] IETF, "IETF RFC5654(MPLS-TP framework)", July 2010. 7.2. Informative References [draft-ietf-pwe3-redundancy-05] Praveen Muley, Mustapha Aissaoui,Matthew Bocci, "Pseudowire Redundancy", September 2011. [draft-ietf-pwe3-redundancy-bit-05] Praveen Muley, Mustapha Aissaoui, "Pseudowire Preferential Forwarding Status Bit", September 2011. [draft-ietf-pwe3-static-pw-status-10] Luca Martini,George Swallow,Giles Heron,Matthew Bocci, "Pseudowire Status for Static Pseudowires", November 2011. 7.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, "", 2008, . Authors' Addresses Liu guoman ZTE Corporation No.50, Ruanjian Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 88014227 Email: liu.guoman@zte.com.cn Liu, et al. Expires July 2, 2012 [Page 9] Internet-Draft p2mp pw protection for mpls-tp network December 2011 Yu jinghai ZTE Corporation No.50, Ruanjian Road, Yuhuatai District Nanjing 45241 P.R China Phone: +86 025 88014226 Email: yu.jinghai@zte.com.cn Tu xiaoping ZTE Corporation No.50, Ruanjian Road, Yuhuatai District Nanjing 45241 P.R China Phone: +86 025 88014226 Email: Tu.xiaoping@zte.com.cn xu xueqiong ZTE Corporation No.50, Ruanjian Road, Yuhuatai District Nanjing 45241 P.R China Phone: +86 025 88014226 Email: Xu.xueqiong@zte.com.cn Liu, et al. Expires July 2, 2012 [Page 10]