MPLS Working Group X. Dai Internet-Draft B. Wu Intended status: Standards Track J. Yang Expires: January 2, 2010 G. Liu ZTE Corpoporation July 1, 2009 Protection for P2MP Ring in MPLS-TP Networks draft-dai-mpls-tp-p2mp-ring-protection-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document provides two possible solutions for protecting point to Dai, et al. Expires January 2, 2010 [Page 1] Internet-Draft Protection P2MP Ring July 2009 multipoint (P2MP) traffic distribution over a ring topology in MPLS-TP networks. These two methods can protect any link or node(except the root node)failure once a failure is detected through MPLS-TP OAM mechanism. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Definitions and terminologies . . . . . . . . . . . . . . . 3 3. Proposed protection schemes for P2MP ring . . . . . . . . . . . 4 3.1. scheme 1 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. scheme 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative references . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Dai, et al. Expires January 2, 2010 [Page 2] Internet-Draft Protection P2MP Ring July 2009 1. Introduction MPLS-TP is a joint ITU-T/IETF effort[RFC5317] to include an MPLS Transport Profile within the IETF MPLS architecture to support the capabilities and functionalities of a packet transport network as defined by ITU-T. In the MPLS-TP requirements draft[MPLS-TP Requirements], it is highlighted that the MPLS-TP architecture must allow a smooth migration from traditional transport networks (e.g.SONET/SDH) to packet transport networks, as well as support the accelerating growth of packet-based services (such as VoIP, L2/L3 VPN, IPTV, RAN backhauling, etc.). That migration must be accomplished preserving carriers investments in both Capital Expenditure (CAPEX) and Operational Expenditure (OPEX) as much as possible. On the one hand, most of today's deployed SDH/SONET networks all over the world are based on ring topology; on the other hand, applications of P2MP services become more and more important, so it has great significance to investigate protection for P2MP traffic in ring topology. The solutions proposed in this document are data plane driven and are thought to be able to work in absence of 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. 2.1. Abbreviations MPLS-TP: Transport Profile for Multi-protocal Label Switching OAM: Operations, Administration and Maintenance P2MP: Point to multi-point CC: Continuity Check FLN: Farthest Leaf Node 2.2. Definitions and terminologies Working path: A transport path that is used to transport normal user traffic, under normal conditions. Recovery path: A transport path that is dedicated to protect normal user traffic in case of a failure of the Working path. Dai, et al. Expires January 2, 2010 [Page 3] Internet-Draft Protection P2MP Ring July 2009 Farthest Leaf Node: A leaf node on a working path that is farthest from the root node. 3. Proposed protection schemes for P2MP ring This section proposes two protection schemes for a P2MP ring. These two schemes are homogeneous in most aspects, but have little differences. In both schemes, MPLS-TP OAM[MPLS-TP OAM Requirements] SHOULD be used on a MPLS-TP transport path to perform Continuity Check (CC) operations. 3.1. scheme 1 In order to protect a P2MP working path of a ring topology, we establish another P2MP transport path (we call it recovery path )to protect a P2MP working path in case of a failure on the working path. These two transport paths have the same root node and leaves, but in opposite directions. In this scheme, MPLS-TP OAM SHOULD be used on each MPLS-TP transport path to perform Continuity Check (CC) operations. Once the farthest leaf node on the working path can't receive MPLS-TP OAM CC packets from the working path in a prescriptive time, a failure is detected on that path. Furthermore, there should be a return path from the FLN to the root node, which is used to inform the root node that a failure is detected on the working path. As for the working path, When a failure is detected by the FLN,FLN will initiate a failure message and transmits it to the root node through the return path. As soon as the root node receives this failure message, it activates the recovery path, and then P2MP traffic will be transported through the working path and recovery path at the same time. At this situation, each leaf will receive user traffic either from the working path or recovery path based a local policy. In figure 1, an example of this scheme to a P2MP ring topology is depicted. The source of a P2MP traffic flow is connected to node A and two P2MP LSPs are created with A as ingress node and B, D and F as egress nodes in order to deliver traffic to different leaves. The working path is A-[B]-C-[D]-E-[F], and the protection path is A-[F]- E-[D]-C-[B]. square brackets indicate a leaf node. Dai, et al. Expires January 2, 2010 [Page 4] Internet-Draft Protection P2MP Ring July 2009 Root Node | +---+ +---+ Leaf 3<-| F |-------------| A | +---+ +---+ / \ / \ / \ +---+ +---+ | E | | B |-->Leaf 1 +---+ +---+ \ / \ / \ / +---+ +---+ | D |-------------| C | +---+ +---+ | V Leaf 2 Figure 1: P2MP ring topology example Under normal situations, user traffic is transmitted through the working path to different leaves. In case of a failure, let's say on link B-C(see figure 2), the FLN (node F in this case)can't receive MPLS-TP OAM CC packets from the working path. As soon as detecting this failure, node F initiates a failure message and transports it to node A through the return path which is configured in advance. When node A receives this failure message, it will activate the recovery path at once. Thus, user traffic will be transported both through the working path and the recovery path, while each leaf node will receive user traffic either from the working path or the recovery path. In this example, leaf node B will receive traffic from the working path, while leaf node D and E will receive traffic from the recovery path. Dai, et al. Expires January 2, 2010 [Page 5] Internet-Draft Protection P2MP Ring July 2009 Root Node | +---+ +---+ Leaf 3<**| F | | A | +---+ * * * * * * +---+ * & * & * & +---+ +---+ | E | | B |&&>Leaf 1 +---+ +---+ * * XXXX * +---+ * * * * * +---+ | D | | C | +---+ +---+ * * V Leaf 2 Figure 2: a failure of link B-C in scheme 1 Such scheme can also protect a node failure, except a failure of the root node, and protection procedures are the same as a link failure described above. 3.2. scheme 2 The second scheme has many similarities with the first scheme described above, with the difference that a transport path is a closed ring. That is to say, the P2MP traffic is sent to all leaves from the root's transmiting port, while will be returned to the root node through the root's receiving port. This scheme also preserved a P2MP recovery path for a working path, which is in opposite directions with respect to the working path. MPLS-TP OAM SHOULD be used on the working path to perform Continuity Check (CC) operations. Once the root's receiving port can't receive MPLS-TP CC packets from the working path, a failure is detected on that path. Thus, the root node activates the recovery path, and user traffic will be transported through both the working path and the recovery path, and each leaf node will receive traffic either from the working path or the recovery path, which is based on a local policy. Dai, et al. Expires January 2, 2010 [Page 6] Internet-Draft Protection P2MP Ring July 2009 With respect to packets arrived at the root node through it's receiving port, only MPLS-TP OAM CC packets will be accepted, all the other packets MAY be disposed. In picture 1, an example of this scheme to a P2MP ring topology is depicted. In this scheme, the working path and recovery path are both chosed rings. Concretely, The working path is A-[B]-C-[D]-E-[F]-A, and the recovery path is A-[F]-E-[D]-C-[B]-A. square brackets indicate a leaf node. Under normal situations, user traffic is transmitted through the working path. In case of a failure, let's say on link B-C, root node A can't receive MPLS-TP CC packets through it's receiving port, which means a failure has occurred on the working path. As soon as detecting this failure, node A will activate the recovery path at once. Thus, the user traffic will be transported both through the working path and the recovery path, while each leaf node will receive user traffic either from the working path or the recovery path. Let's see an example in figure 3: Root Node | +---+ +---+ Leaf 3<@@| F | @ @ @ @ @ @ | A | +---+ +---+ @ # @ # @ # +---+ +---+ | E | | B |##>Leaf 1 +---+ +---+ @ @ XXXX @ +---+ +---+ | D | @ @ @ @ @ @ | C | +---+ +---+ @ @ V Leaf 2 Figure 3: a failure of link B-C in scheme 2 This scheme can also protect a node failure, except a failure of the Dai, et al. Expires January 2, 2010 [Page 7] Internet-Draft Protection P2MP Ring July 2009 root node, and protection procedures are the same as a link failure described above. Besides, this scheme is especially applicable to scenes that most of nodes on a ring are leaves. 4. Comparison Both schemes proposed in this document can protect the working path from a link failure or a node failure, with little differences in the mechanisms. Scheme 2 is better than scheme 1 in two aspects. First, scheme 2 doesn't need a return path that prereserved to transport failure messages, since the root node itself can detect the failure and activates the recovery path. Secondly, in scheme 2, fault detection point and protection implemented point are at the same point, so it is simpler than scheme 1. But it also has some disadvantages, one of which is on bandwidth utilization, to be more specific, it wastes bandwidth between the FLN and the root node on the working path. 5. IANA Considerations TBD. 6. Security Considerations This section will be added in a future version. 7. Acknowledgement TBD. 8. References 8.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009. Dai, et al. Expires January 2, 2010 [Page 8] Internet-Draft Protection P2MP Ring July 2009 8.2. Informative References [MPLS-TP OAM Requirements] Vigoureux, M., "Requirements for OAM in MPLS Transport Networks", March 2009. [MPLS-TP Requirements] Niven-Jenkins, B., "MPLS-TP Requirements", May 2009. Authors' Addresses Xuehui Dai ZTE Corpoporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877612 Email: dai.xuehui@zte.com.cn Bo Wu ZTE Corpoporation 4F,RD Building 2,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52877276 Email: wu.bo@zte.com.cn Jian Yang ZTE Corpoporation 5F,R&D 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 Dai, et al. Expires January 2, 2010 [Page 9] Internet-Draft Protection P2MP Ring July 2009 Guoman Liu ZTE Corpoporation 4F,RD Building 1,Zijinghua Road Yuhuatai District,Nanjing 210012 P.R.China Phone: +86 025 52871606 Email: liu.guoman@zte.com.cn Dai, et al. Expires January 2, 2010 [Page 10]