MPLS Working Group G. Liu Internet-Draft ZTE Corporation Intended status: Informational Y. Weigarten Expires: April 22, 2013 M. Daikoku T. Maruyama KDDI Corporation October 19, 2012 MPLS-TP protection for interconnected rings draft-liu-mpls-tp-interconnected-ring-protection-03 Abstract The requirements for MPLS Transport Profile include a requirement (R93) that requires that MPLS-TP must support recovery mechanisms for a network constructed from interconnected rings that protect user data that traverses more than one ring. In particular, this includes protecting against cases of failure at the ring interconnect nodes and links. This document presents different configurations of interconnected rings and special mechanisms to address the recovery of ring-interconnect nodes and links. . 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 material or to cite them other than as "work in progress." Liu, et al. Expires April 22, 2013 [Page 1] Internet-Draft MPLS-TP protection of interconnection October 2012 This Internet-Draft will expire on April 22, 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, et al. Expires April 22, 2013 [Page 2] Internet-Draft MPLS-TP protection of interconnection October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 8 3. recovery mechanism . . . . . . . . . . . . . . . . . . . . . . 9 3.1. recovery mechanism for Dual-node interconnection . . . . . 9 3.2. recovery mechanism for Chained interconnection . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Liu, et al. Expires April 22, 2013 [Page 3] Internet-Draft MPLS-TP protection of interconnection October 2012 1. Introduction This document describes different interconnected ring scenarios and a few special solutions to protect against the failure of the ring- interconnect nodes and links. there are three common interconnection scenarios that we will address in this document: Dual-node interconnection - when the two rings are interconnected by two nodes from each ring (see Figure 1); Single-node interconnection - when the connection between the two rings is through a single node (see Figure 2).As the interconnnection node(LSR-A) is a single-point of failure, This configuration should be avoided in real networks; Chained interconnection - when a series of rings are connected through interconnection nodes that are part of both interconnected rings (see Figure 3) /LSR\******/LSR\******/LSR\xxxx/LSR\*****/LSR\******/LSR\ \_C_/ \_B_/ \_A_/ \_6_/ \_1_/ \_2_/ * * x x * * * Ring #1 * x x * Ring #2 * _*_ ___ _*_ x _*_ ___ _*_ /LSR\ /LSR\ /LSR\x x /LSR\ /LSR\ /LSR\ \_D_/******\_E_/******\_F_/xxxx\_5_/*****\_4_/******\_3_/ *** physical link xxx interconnection link Figure 1 Liu, et al. Expires April 22, 2013 [Page 4] Internet-Draft MPLS-TP protection of interconnection October 2012 ___ ___ ___ ___ /LSR\**********/LSR\ /LSR\*********/LSR\ \_C_/ \_B_/* *\_1_/ \_2_/ * * * * * * * * * * * * _*_ * ___ * _*_ /LSR\ Ring #1 /LSR\ Ring #2 /LSR\ \_D_/ *\_A_/* \_3_/ * * * * * * * * * * * * _*_ ___* *___ _*_ /LSR\ /LSR\ /LSR\ /LSR\ \_E_/***********\_F_/ \_5_/**********\_4_/ *** physical link Figure 2 ___ ___ ___ ___ ___ /LSR\******/LSR\******/LSR\*****/LSR\******/LSR\ \_C_/ \_B_/ \_A_/ \_1_/ \_2_/ * x * * Ring #1 x Ring #2 * _*_ ___ _x_ ___ _*_ /LSR\ /LSR\ /LSR\ /LSR\ /LSR\ \_D_/******\_E_/******\_F_/*****\_4_/******\_3_/ *** physical link xxx shared link Liu, et al. Expires April 22, 2013 [Page 5] Internet-Draft MPLS-TP protection of interconnection October 2012 Figure 3 Regarding traffic that traveres more than two rings. many interconnection scenarios could be existed in the same scenario, they will be mixed interconnection scenario: Dual-node and single-node mixed interconnection- when there exist a multi-ring traffic which traveres more than two ring. two of these rings are dual-node interconnection. while another two are single- node interconnection (see figure 5); Dual-node and chained mixed interconnection-when there exist both dual-node interconnection and chained interconnection in this scenario (see figure 4); single-node and chained mixed interconnection-when there exist both single-node interconnection and chained interconnection in this scenario(see figure 6); Dual-node, single-node and chained mixed interconnection-when there exist all three interconnection scenrios in this scenario including Dual-node interconnnection, single-node interconnection and chained interconnnection( see figure 7); ___ /LSR\******/LSR\xx/LSR\****/LSR\ /LSR\**** /LSR\***/LSR\ \_C_/ \_B_/ \_A_/ \_6_/ \_1_/ \_2_/ \_H_/ * * x x * * * x * x * x * * Ring 1 * x x * Ring 2 * .....*Ring 3 x Ring 4* _*_ *x x_*_ _*_ ___ ___ ___ /LSR\ /LSR\ /LSR\ /LSR\ /LSR\*****/LSR\**/LSR\ \_D_/******\_E_/xx\_5_/*****\_4_/ \_k_/ \_L_/ \_M_/ *** physical link xxx interconnection link Figure 4 Liu, et al. Expires April 22, 2013 [Page 6] Internet-Draft MPLS-TP protection of interconnection October 2012 ___ /LSR\******/LSR\xx/LSR\****/LSR\ /LSR\ /LSR\ \_C_/ \_B_/ \_A_/ \_6_/ \_1_/ *\_H_/ * * x x * * * * * * x * * ___ * * * Ring 1 * x x * Ring 2 * .....*Ring 3/LSR\ Ring 4* _*_ *x x_*_ _*_ ___ * \_L_/* ___ /LSR\ /LSR\ /LSR\ /LSR\ /LSR\* * /LSR\ \_D_/******\_E_/xx\_5_/*****\_4_/ \_k_/ \_M_/ *** physical link xxx interconnection link Figure 5 ___ /LSR\******/LSR\**/LSR\****/LSR\ /LSR\ /LSR\ \_C_/ \_B_/ \_A_/ \_6_/ \_1_/ *\_H_/ * x * * * * * * * ___ * * * Ring 1 x Ring 2 * .....*Ring 3/LSR\ Ring 4* _*_ _ _x_ _*_ ___ * \_L_/* ___ /LSR\ /LSR\ /LSR\ /LSR\ /LSR\* * /LSR\ \_D_/******\_E_/**\_5_/*****\_4_/ \_k_/ *\_M_/ *** physical link xxx interconnection link Figure 6 Liu, et al. Expires April 22, 2013 [Page 7] Internet-Draft MPLS-TP protection of interconnection October 2012 ___ /LSR\******/LSR\xx/LSR\****/LSR\**** /LSR\ /LSR\ \_C_/ \_B_/ \_A_/ \_6_/ \_1_/ *\_H_/ * * x x * x x * * * x x * ___ * * * Ring 1 * x x * Ring 2 xRing 5 xRing 3/LSR\ Ring 4* _*_ *x x_*_ _x_ ___ * \_L_/* ___ /LSR\ /LSR\ /LSR\ /LSR\****/LSR\* * /LSR\ \_D_/******\_E_/xx\_5_/*****\_4_/ \_k_/ *\_M_/ *** physical link xxx interconnection link Figure 7 For a multi-ring traffic, it will be across more than one ring just like above seven scenarios. if a failure happens on a multi-ring path, quick recovery is necessary requirement for multi-ring traffic. 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 PSC:Protection Switching Coordination SD:Signal Degrade SF:Signal Fail MPLS-TP:Multi-Protocol Label Switching Transport Profile Liu, et al. Expires April 22, 2013 [Page 8] Internet-Draft MPLS-TP protection of interconnection October 2012 3. recovery mechanism In the following subsections we propose different mechanisms that may be applied for traffic recovery in the different interconnection scenarios. In general, it is possible to provide protection against the failure of a ring node/link by using the single-ring protection mechanism. These cases are out of scope for this document. It is also possible to configure an end-to-end protection to protect the entire working path across all of the interconnected rings. However, this protection scheme does not scale very well. Therefore, we need to consider special mechanisms to address recovery from failures of the interconnecting nodes and links 3.1. recovery mechanism for Dual-node interconnection Under this scenario , when interconnection link(LSRA-LSR6) has a failure as shown in figure 8. it is possible use 1:1 linear protection mechanism to protect the failure of segment(LSRA-LSR6) by using one of the protection paths (LSRA-LSRF-LSR5-LSR6 or LSRA-LSRF- LSR6 or LSRA-LSR5-LSR6) . /LSR\******/LSR\******/LSR\x||x/LSR\*****/LSR\******/LSR\ \_C_/ \_B_/ \_A_/ \_6_/ \_1_/ \_2_/ * * x x * * * Ring #1 * x x * Ring #2 * _*_ ___ _*_ x _*_ ___ _*_ /LSR\ /LSR\ /LSR\x x /LSR\ /LSR\ /LSR\ \_D_/******\_E_/******\_F_/xxxx\_5_/*****\_4_/******\_3_/ *** physical link xxx interconnection link || failure Figure 8 When the interconnection node(LSRA or LSR6) detects a SF or SD on the interconnection link(LSRA-LSR6), LSRA or LSR6 will send SF or SD failure message to its peer node. Then it switchs the multi-ring traffic from the working path to its corresponding protection path to another end point(LSRA or LSR6) of the segment . when the peer node (LSR6 or LSRA) receives the traffic packet from its protection Liu, et al. Expires April 22, 2013 [Page 9] Internet-Draft MPLS-TP protection of interconnection October 2012 protection path, it will POP the outer label of protection tunnel and return back to the original working tunnel(LSRA-LSRB-LSRC or LSR6- LSR1-LSR2) of another ring(ring 1 or ring 2) to transport the multi- ring traffic. when interconnection node(LSRA or LSR6) has a failure as shown in figure 9. the end node of the segment detects the failure of the interconnection node, it should send failure messge to the backup interconnection node(LSRF or LSR5) to active the protection path that goes to the backup interconnection node(LSRF or LSR5) to trasnport the multi-ring traffic. at the same time, the backup interconnection node should active its corresponding protection path that goes to another primary interconnection node(LSR6 or LSRA).Then the multi- ring traffic should return back to the original working path to be transported in another primary interconnection node.. ## /LSR\******/LSR\******/LSR\xxxx/LSR\*****/LSR\******/LSR\ \_C_/ \_B_/ \_A_/ \_6_/ \_1_/ \_2_/ * * x x * * * Ring #1 * x x * Ring #2 * _*_ ___ _*_ x _*_ ___ _*_ /LSR\ /LSR\ /LSR\x x /LSR\ /LSR\ /LSR\ \_D_/******\_E_/******\_F_/xxxx\_5_/*****\_4_/******\_3_/ *** physical link xxx interconnection link ## node failure Figure 9 for example , LSRC detects a failure on the interconnection node LSRA. it will send the failure message to notify the backup interconnection node LSRF to switch over to the protection path(LSRC- LSRD-LSRE-LSRF) to transport the multi-ring traffic.at the same time, LSRF should active its corresponding protection path that goes to another primary interconnection node LSR6 to transport the multi-ring traffic.The corresponding protection path may be one of the two paths(LSRF-LSR5-LSR6 or LSRF-LSR6). Then the multi-ring traffic will be transported by its original working path(LSR6-LSR1-LSR2) to the exit node LSR2. Liu, et al. Expires April 22, 2013 [Page 10] Internet-Draft MPLS-TP protection of interconnection October 2012 3.2. recovery mechanism for Chained interconnection For this scenario , when only a failure is detected on the interconnection link. Since the failure should not affect the multi- ring traffic. no action is taken. when a failure happens on the segment of the multi-ring path just as shown in figure 10. The end node of the segment detects the failures, it will active the protection path that goes to the backup interconnection node to transport the multi-ring traffic. After the backup interconnection node receives the failure message , it will active its corresponding protection path that goes to the exit node of another ring to trasnport the multi-ring traffic. ___ ___ ___ ___ ___ /LSR\**||**/LSR\******/LSR\*****/LSR\******/LSR\ \_C_/ \_B_/ \_A_/ \_1_/ \_2_/ * x * * Ring #1 || Ring #2 * _*_ ___ _x_ ___ _*_ /LSR\ /LSR\ /LSR\ /LSR\ /LSR\ \_D_/******\_E_/******\_F_/*****\_4_/******\_3_/ *** physical link xxx shared link || failure Figure 10 for example, there are failures on both link(LSRC-LSRB) and (LSRA- LSRF) at the same time as shown in figure.10. when LSRC detects or is notified of the failures on both the segment of the working path and the interconnection link. so it will send a failure message to the backup interconnection node LSRF, Then LSRF will active its corresponding protection path(LSRF-LSR4-LSR3-LSR2) of ring 2 to transport the multi-ring traffic. (Editor's note:should supply text that describes protection against the failure of interconnection node in the chained interconnection Liu, et al. Expires April 22, 2013 [Page 11] Internet-Draft MPLS-TP protection of interconnection October 2012 scenario in the future. welcome all experts provide good solution for the failure) 4. Security Considerations TBD 5. IANA Considerations TBD. 6. Acknowledgments TBD . 7. References 7.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] N. Sprecher, A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", September 2011. [RFC 6378] S. Bryant, N. Sprecher, A. Fulignoli Y. Weingarten, "MPLS transport profile Linear Protection", September 2011. 7.2. Informative References [MPLS-TP Ring Protection] Y. Weingarten, "Multiprotocol Label Switching Transport Profile Ring Protection", Sep 2011. 7.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, "", 2008, Liu, et al. Expires April 22, 2013 [Page 12] Internet-Draft MPLS-TP protection of interconnection October 2012 . Authors' Addresses Guoman Liu ZTE Corporation No.50, Ruanjian Ave, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 88014227 Email: liu.guoman@zte.com.cn Yaacov Weingarten 34 Hagefen St Karnei Shomron 44853 Israel Phone: +972-9-775 1827 Email: wyaacov@gmail.com Masahiro Daikoku KDDI Corporation Garden Air Tower,Iidabashi, Chiyoda-ku Tokyo 102-8460 Japan Email: ms-daikoku@kddi.com Takeshi Maruyama KDDI Corporation Garden Air Tower,Iidabashi, Chiyoda-ku Tokyo 102-8460 Japan Email: ta-maruyama@kddi.com Liu, et al. Expires April 22, 2013 [Page 13]