MPLS Working Group J. Yang Internet-Draft H. Su Intended status: Informational ZTE Corporation Expires: April 30, 2009 October 27, 2008 Multiprotocol Label Switching Transport Profile Ring Protection Analysis draft-yang-mpls-tp-ring-protection-analysis-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 30, 2009. Abstract The three potential solutions to the MPLS-TP ring protection were addressed in the report of the IETF-ITU-T Joint Working Team(JWT). Each solution has different attributes and advantages. This document provides an analysis for MPLS-TP based on the ring protection. Yang & Su Expires April 30, 2009 [Page 1] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Facility bypass . . . . . . . . . . . . . . . . . . . . . . . 4 4. Detours . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. ITU-T G.8132 . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Solutions analysis . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Capability analysis . . . . . . . . . . . . . . . . . . . 6 6.2. Requirements analysis . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.3. URL References . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Yang & Su Expires April 30, 2009 [Page 2] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 1. Introduction Network survivability reflects the ability of a network to continue to function during failures and recovery. The three potential solutions to the MPLS-TP ring protection were addressed in the report of the IETF - ITU-T Joint Working Team (JWT). Each solution has different attributes and advantages. This document provides an analysis for MPLS-TP-based ring protection. These three potential solutions are: - Facility bypass: A single facility bypass LSP protects all LSPs over a specific link by wrapping traffic. - Detours: A detour LSP can be used for optimal traffic delivery to the egress point (without wrapping). - ITU-T G.8132: It defines a ring protection that includes additional capabilities to the MPLS protection schemes, by supporting coordinated protection in case of multiple failures (using single protection mechanism for all cases). 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. The following terminologies were defined in [RFC4090]. LSR: Label-Switch Router. LSP: An MPLS Label-Switched Path. In this document, an LSP will always be explicitly routed. PLR: Point of Local Repair. The head-end LSR of a backup tunnel or a detour LSP. One-to-One Backup: A local repair method in which a backup LSP is separately created for each protected LSP at a PLR. Protected LSP: An LSP is said to be protected at a given hop if it has one or multiple associated backup tunnels originating at that hop. Detour LSP: The LSP that is used to re-route traffic around a failure in one-to-one backup. Yang & Su Expires April 30, 2009 [Page 3] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 Bypass Tunnel: An LSP that is used to protect a set of LSPs passing over a common facility. Backup Path: The LSP that is responsible for backing up one protected LSP. A backup path refers to either a detour LSP or a backup tunnel. MP: Merge Point. The LSR where one or more backup tunnels rejoin the path of the protected LSP downstream of the potential failure. The same LSR may be both an MP and a PLR simultaneously. The following terminologies were defined in [ITU-T G.8132 draft]. APS channel: Automatic Protection Switch (APS) Channel is used to carry information between the two ends of a linear protection group to coordinate the head-end bridge with the tail-end selector for 1:n protection, and to coordinate the selectors in both directions in the case of bidirectional protection. Bridge: The function that connects the normal and extra traffic signals to the working and protection transport entities. OAM: Operation, Administration and Maintenance. SF: Signal Fail. 3. Facility bypass The facility bypass is one of the backup methods defined in [RFC4090]. It created a single LSP(bypass LSP tunnel) that serves to back up a set of LSPs. The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the PLR. The PLR built a bypass tunnel that protects against the failure of a link or a node. When a failure occurs along a protected LSP, the PLR redirects traffic into the appropriate bypass tunnel. If protected link fails, the PLR will switch traffic received from upstream LSR on the protected LSP onto the bypass tunnel. The label will be switched for one which was assigned by MP to indicate the protected LSP, and the bypass tunnel's label will then be pushed onto the label-stack of the redirected packets. So there will be two levels of labels used in the bypass tunnel. When MP receives the redirected packets, it pops the label that it assigned for bypass tunnel and uses the label that it assigned for protected LSP to forward the packet. The Facility bypass technique provides that using the same bypass tunnel protects many LSPs which traverse the same links or nodes. Yang & Su Expires April 30, 2009 [Page 4] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 Link protection: The PLR and MP are connected through a direct link and the primary LSP traverses this link.When the link fails, traffic is switched to the backup LSP. Node protection: The PLR and MP are connected through a device and the primary LSP traverses this device. When the device fails, traffic is switched to the backup LSP. 4. Detours The detours one to one backup is the other method defined in [RFC4090]. In the one-to-one backup method, a label-switched path is established that intersects the original LSP somewhere downstream of the point of link or node failure. A PLR computes a separate backup LSP, called a detour LSP, for each LSP that the PLR protects. When a failure occurs along the protected LSP, the PLR redirects traffic onto the local detour, using the label received when PLR created the detour. When MP receives traffic with the label provided for PLR's detour, it will switch that traffic onto the original LSP, using the label received from the node of MP's next hop. In the detour mode, the depth of label stack will not increase. It provides an optimized detour methord in [MPLS-TP JWT REPORT] to protect an LSP that traverses N nodes only using one detour tunnel without wrapping. 5. ITU-T G.8132 The T-MPLS Shared Protection Ring (TM-SPRing) protection switching mechanisms are specified in [ITU-T G.8132 draft]. It provides the protection connection as a ring topology to protect the working LSP. Each section (span) in the ring is monitored by sending CV OAM with periodicity of 3.3ms and Span failures are detected as absence of 3 consecutive CV frames. Each node has an APS controller that sends and receives APS messages. These messages inform the states of the ring. When failure occurs, the nodes adjacent to the failure enter the switching state and sends APS SF message to neighbor nodes. The traffic is switching to the protection connection. When the other nodes in the ring receive the SF message, they enter pass-through state (i.e. allow forwarding on the protection LSP) and forward the APS messages without modification. The APS protocol and associated OAM functions shall accommodate the Yang & Su Expires April 30, 2009 [Page 5] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 capability to upgrade the ring (node insertion /removal), limiting the possible impact on existing traffic on the ring. The same mechanism with a single protection connection restores all traffic possible: p2p, p2mp connections, fiber or node failure, single or multiple failures. There are two solutions, the wrapping and the steering techniques in TM-SPRing protection. - The Wrapping technique: It implies that the node that detects a failure sends a request through the APS protocol to the node adjacent to the failure. When the node detects a failure or receives a bridge request through APS protocol addressed to this node, normal traffic transmitted towards the failed span is switched to the opposite direction (away from the failure). This traffic travels the long way around the ring to the other switching node where it is switched back onto the working direction. The switching nodes restore normal traffic flow when the failure or APS protocol request is cleared. - The Steering technique: It implies that the node that detects a failure sends a request through the APS protocol to the node adjacent to the failure and all nodes in the ring process this APS information. In case of p2p connections, for each affected connection the source node (that adds traffic to the ring) and the sink node (that drops the traffic from the ring) perform switching from working to the protection direction, and restore normal traffic flow when the failure or APS protocol request is cleared. 6. Solutions analysis As described in the sections above, the each solution has different attributes and advantages. This section will provide an analysis for MPLS-TP based ring protection. 6.1. Capability analysis The table1 shows the capability analysis of the different solutions. - Amounts of the backup LSP: The both Detour and G.8132 solutions require the same amounts of the backup LSPs to the original LSPs. However, the Bypass method can use the one backup LSP to protect many original LSPs. Yang & Su Expires April 30, 2009 [Page 6] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 - Bandwith utilization ratio: When protection occurs, the G.8132 steering method can bridge and switch directly at the nodes with traffic ingress and egress. In the other sloutions including the bypass, detour and G.8132 wrapping, the traffic in case of protection travels the long way around the ring to the other switching node where it is switched back onto the working direction. So the G.8132 steering is the highest one of the bandwidth utilization ratio. - The complexity of configuration and APS: G.8132 needs the APS protocol to implement the switch and the bridge. - Packets disorder: There is a MP in the bypass and detour solution. The merge operation may cause packets disorder. +-----------------+----------+------------+------------+------------+ | Items | Bypass | Detour | G.8132 | G.8132 | | | | | wrapping | steering | +-----------------+----------+------------+------------+------------+ | Amounts of the | Less | As many as | As many as | As many as | | backup LSP | | the | the | the | | | | protected | protected | protected | | | | LSP | LSP | LSP | +-----------------+----------+------------+------------+------------+ | Bandwidth | The | The second | The third | The | | utilization | third | one | one | highest | | ratio | one | | | | +-----------------+----------+------------+------------+------------+ | Bandwidth share | Support | Support | Support | Support | +-----------------+----------+------------+------------+------------+ | Complexity | Simple | Simple | complex | The most | | (configuration, | | | | complex | | APS) | | | | | +-----------------+----------+------------+------------+------------+ | Packets | Yes | Yes | No | No | | disorder | | | | | +-----------------+----------+------------+------------+------------+ | APS protocol | No need | No need | Need | Need | +-----------------+----------+------------+------------+------------+ | Lable stack | Increase | Changeless | Changeless | Changeless | | | one more | | | | | | layer | | | | +-----------------+----------+------------+------------+------------+ Table 1: solutions analysis Yang & Su Expires April 30, 2009 [Page 7] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 6.2. Requirements analysis The table2 shows the requirements analysis of the different solutions. These requirements are based on the [MPLS-TP JWT REPORT] and the [MPLS-TP Survivability Framework]. - Node failure: The all solutions support the node failure. But the bypass method must establish as many as N bypass tunnels to protect the N nodes in the protected LSP. And the other LSP should be established in order to protect the link between the protected node and its upstream node. - Mutiple failures: One bypass tunnel can only protect single failure of the protected LSP, a node or a link failure. It can't provide the protection of multiple failures. - External commands: External commands in the bypass and the detour solution are not sufficient,should be extended to meet the requirements. - Bidirectional LSPs: The issue to force both ends pick same merge point for each direction in detour methord is to be studied. - Application to P2MP LSPs: P2MP LSP protection based on FRR is covered in [RFC 4875], but if it could be used or not in ring topology are to be studied. - Operator's Qos objectives on protection path: In the bypass solution, the many protected LSPs share one bypass tunnel. When protection occurs, all the protected the traffic redirect onto the bypass tunnel. EIR services from different protected LSPs can't be distinguished. The Qos of these EIR services can't be guaranteed. +-----------------------+---------+---------+-----------+-----------+ | Items | Bypass | Detour | G.8132 | G.8132 | | | | | wrapping | steering | +-----------------------+---------+---------+-----------+-----------+ | Node failure | Support | Support | Support | Support | +-----------------------+---------+---------+-----------+-----------+ | Multiple failures | Not | Support | Support | Support | | | support | | | | +-----------------------+---------+---------+-----------+-----------+ | External commands | Partial | Partial | Complete | Complete | +-----------------------+---------+---------+-----------+-----------+ | Bidirectional LSPs | Support | TBD | Support | Support | +-----------------------+---------+---------+-----------+-----------+ Yang & Su Expires April 30, 2009 [Page 8] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 +-----------------------+---------+---------+-----------+-----------+ | Application to P2MP | TBD | TBD | Support | TBD | | LSPs | | | | | +-----------------------+---------+---------+-----------+-----------+ | Protection ration of | Support | Support | Support | Support | | 100% | | | | | +-----------------------+---------+---------+-----------+-----------+ | Operator's QoS | Partial | Support | Support | Support | | objectives on | | | | | | protection path | | | | | +-----------------------+---------+---------+-----------+-----------+ Table 2: solutions analysis 7. Security Considerations TBD. 8. IANA Considerations TBD. 9. Acknowledgments TBD. 10. References 10.1. Normative References [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. 10.2. Informative References [ITUT-G.8132 Draft] ITU-T, "Draft ITU-T Recommendation G.8132 (T-MPLS shared protection ring)", November 2007. [MPLS-TP JWT REPORT] S.Bryant, L.Andersson, "JWT Report on MPLS Architectural Considerations for a Transport Profile", July 2008. Yang & Su Expires April 30, 2009 [Page 9] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 [MPLS-TP Survivability Framework] N. Sprecher, A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", July 2008. 10.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, "", 2008, . Authors' Addresses Jian Yang ZTE Corporation 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 Hui Su ZTE Corporation 5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road Nanshan District,Shenzhen 518055 P.R.China Phone: +86 755 26773673 Email: su.hui@zte.com.cn Yang & Su Expires April 30, 2009 [Page 10] Internet-Draft MPLS-TP Ring Protection Analysis October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Yang & Su Expires April 30, 2009 [Page 11]