MPLS Working Group G. Liu Internet-Draft ZTE Corporation Intended status: Standards Track Y. Ji Expires: June 17, 2012 BUPT University j. Yu ZTE Corporation December 15, 2011 Multiprotocol Label Switching Transport Profile Ring Protection draft-liu-mpls-tp-ring-protection-switching-00 Abstract according to RFC 5654 MPLS-TP Requirement, there is a paragraph for recovery requirements just as section 2.5.6.1 in RFC5654 describles: within the context of recovery in MPLS-TP networks,the optimization criteria considered in ring topologies are as follows: 1 minimize the number of OAM entities that are needed to trigger the recovery operation; 2 Minimize the number of elements of recovery in the ring; 3 Minimize the number of labels required for the protection paths across the ring; 4 minimize the amount of control and management plane transactions during maintenance operation. this document will describle two types of ring protection solutions to implement these requirements. 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." This Internet-Draft will expire on June 17, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Liu, et al. Expires June 17, 2012 [Page 1] Internet-Draft MPLS-TP ring protection December 2011 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. proposed ring protection solution . . . . . . . . . . . . . . 4 3.1. solution 1 . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. solution 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. P2P Instance . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. P2MP Instance . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.3. URL References . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Liu, et al. Expires June 17, 2012 [Page 2] Internet-Draft MPLS-TP ring protection December 2011 1. Introduction this draft mainly describes two ring protection solutions, solution 1 will use one protecting SPME to protect one working SPME when there is a defect on the working SPME. while solution 2 will use one protecting LSP to protect one working LSP.They are similar to 1:1 linear protection. but the difference is the first solution may protect many LSP working paths of one SPME. and the second one may just protect one working LSP path. 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 LSR:Label Switching Router P2MP:Point to Multi-Point P2P:Point to Point APS:Automatic Protection Switch PSC:Protection Switching Coordination SD:Signal Degrade SF:Signal Fail BFD:Bidirectional Forward Detection MPLS:Multi-Protocol Label Switching MPLS-TP:Multi-Protocol Label Switching Transport Profile TTSI:Trail Termination Source Identifier_source LER ID+LSP ID MEP:MEG End Point LER: Label Edge Router Liu, et al. Expires June 17, 2012 [Page 3] Internet-Draft MPLS-TP ring protection December 2011 CC&CV: Check continuity and connectivity verification SPME: Sub-Path maintenace entity 3. proposed ring protection solution this section mainly proposed two types of ring protection solution.the two ring protection solutions need to detect and notify the defect by OAM and APS functions,so that the source node of working SPME and LSP path will switch these protected services into protecting SPME and LSP path.but the two ring protection solutions also have a few differences. solution 1 provides recovery of all LSP services of a defective working SPME by protecting SPME ,while another solution just provides one dedicate protecting path for each working LSP path. 3.1. solution 1 This ring protection solution in MPLS-TP network mainly use protecting SPME to protect working SPME .firstly two transfer nodes will be selected in the ring. and the two transfer nodes would backup for each other to ensure to transport service under the condition that one prime transfer node has failure.other nodes in the ring need to set up two bidirectional SPME separately in the direction of clockwise and anticlockwise along the ring to the two transfer nodes ; and use CC or CV packet to detect defect on each SPME. when an end point of a working SPME detects a defect on its own SPME , it will generate a State notify message (PSC) to be sent to another end point of the SPME. so that the two end point can coordinate the switch state. and the frame format of the state notify message is the following 1: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0001| 0000 | 00000000 | channel type (PSC) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PSC Control packet | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 when another end point of the SPME received State Notify messgae from Liu, et al. Expires June 17, 2012 [Page 4] Internet-Draft MPLS-TP ring protection December 2011 peer end point, it would process the message and switch to its relative protecting SPME to transport all LSP Services of the defective working SPME. for example, there is the following ring including point A ,B, C,D,E and F .Point A and D are configured as two transfer nodes separately in the ring.while working and protecting SPME will be set up between the two transfer nodes A and D and other nodes include B,C,D,E,F.it will need to set up 16 SPME in the ring. Just as C node, there need to set up four bidirectional SPME,which are separately working SPME(A-B-C) identified by signal (@) and protecting SPME ( A-F-E-D-C) identified by signal (#) between transfer node A and node C . at the same time, they are still including bidirectional working SPME (C-D) identified by signal(*) and protecting SPME(C-B-A-F-E-D) identified by signal($) between another transfer node D and node C, just as the following figure 2. transfer node | +---+ ######## +---+ | F |-------------| A | +---+ $ $ $ $ +---+ #/$ $ \@ #/$ $ \@ #/$ $ \@ +---+ +---+ sink node----| E | | B | +---+ +---+ #\$ $ /@ #\$ $ /@ #\$ $ /@ +---+ * * * * * +---+ | D |-------------| C | +---+ ###### +---+ | source node transfer node NOTE: @: working sub-path tunnel between A and C #: protecting sub-path tunnel between A and C *: working sub-path tunnel between C and D $: protecting sub-path tunnel between C and D Figure 2 Liu, et al. Expires June 17, 2012 [Page 5] Internet-Draft MPLS-TP ring protection December 2011 supposing a LSP service from source node C to sink node E ,under free-defect contidion,it would push the LSP into working SPME (w)PCA| LC(A)|BOS firstly,then it will POP outer SPME label and swap inner LSP label in the transfer node A .and then push it into another SPME (w)PAE|LA(E)|BOS and transport it to sink node E. here PXY denotes a SPME from LSR-X to LSR-Y , '|' can be used to separate each level in label stack .LX(Y) denotes a LSP service from LSR-X to LSR-Y. BOS denotes the bottom of label stack. Supposing a defect happened on the working SPME(C-B-A) by OAM function as the following figure 3. transfer node | +---+ # # # # +---+ | F |-------------| A | +---+ +---+ #/ \@ #/ \@ #/ \@ +---+ +---+ sink node----| E | | B | +---+ +---+ #\ /@ #\ X #\ /@ +---+ +---+ | D |-------------| C | +---+ # # # # +---+ | source node transfer node NOTE: @: working sub-path Tunnel #: protecting sub-path Tunnel X: failure Figure 3 for example, there is a defect on the link(C-B) just as above figure,all LSP services which would be carried and sent between C and transfer node A by working SPME(C-B-A) should switch to protecting SPME(C-D-E-F-A) and push it into protecting SPME(p)PCA|LC(A)|BOS and be transported to transfer node A if the protecting SPME has no failure at the same time. when it arrived at the transfer node A , Liu, et al. Expires June 17, 2012 [Page 6] Internet-Draft MPLS-TP ring protection December 2011 The outer SPME label would be popped and swap LSP label in the transfer node A, Then the LSP service would be pushed into another working SPME (w)PAE|LA(E)|BOS and be carried to sink node E .in addtion, when the transfer node A or the relative protecting SPME has failure too, another transfer node D will become transfer node for all LSP services which are trasfered at the transfer node A. All LSP services of working SPME(C-B-A) would be pushed into another working SPME(C-D) (w)PCD|LC(D)|BOS to be sent to backup transfer node D, and then POP outer SPME label and swap LSP label at the transfer node D .then they would be pushed into another SPME (w) PDE|LD(E)|BOS and be sent to sink node E. From the view of number of configuring SPME, if there are n nodes in the ring , there only need to set up and configure O(4N) SPME Tunnel. if configuring one working SPME and one protecting SPME between each node and other nodes of the ring , then there need to set up and configure O(n^2) SPME . so this solution maybe solve the N square problem. 3.2. solution 2 This ring protection solution can use one protecting LSP path to protect one working LSP path,since they are both in the same ring, the direction of the two LSP path is reverse in the ring. when a defect has been detected by section cc&cv function, a state notify message just as the above figure 1 will be generated and sent to all other nodes of the ring . when other nodes receive the state notify message , they would analysis which LSP service would be affected by the failure based by the state notify message and segment link state of each LSP on each node.if some working paths are affected by the failure, they will switch to its relative protecting path or bridge its service to both working path and protecting path. 3.2.1. P2P Instance if the LSP service affected by the failure is P2P service in the ring , the source node of the LSP service would switch into its own protecting LSP path to transport to the egress node of the ring. while the egress node of the LSP service would select protecting LSP path to receive the service .for example , there is a LSP service from B to E as the following figure 4. its working LSP path is B-A-F-E identified by singal @, while its protecting LSP path is B-C-D-E identified by signal #, Under normal condition, the LSP service would be sent by the working LSP path(B-A-F-E). Liu, et al. Expires June 17, 2012 [Page 7] Internet-Draft MPLS-TP ring protection December 2011 +---+ @@@@@@@@ +---+ | F |-------------| A | +---+ +---+ @/ \@ @/ \@ @/ \@ +---+ +---+ sink node --| E | | B |Source node +---+ +---+ #\ /# #\ /# #\ /# +---+ +---+ | D |-------------| C | +---+ # # # # +---+ NOTE: @: working LSP path; #: protecting LSP path; Figure 4 if there is a defect on the working LSP path. for example the link A-F has a defect as the following figure 5.node A or F would detect a defect by section CC&CV function firstly. then node A or F would generate state notify message and send it to all other nodes of the ring. when other nodes of the ring received the state notify message , they would process the state notify message and analysis which LSP service would be affected by the failure based by the state notify message and segment link state of each LSP which must save on both end node of each LSP.if the failure can change the segment link state of a LSP , the LSP will switch into the protecting path to transport service pakcet. Just as the following link(A-F) failure, when both end nodes B and E of the LSP received the state notify message from node A or F, they firstly would locate where the failure happened by the two end node address of the failure in the state notify message. then they would judge whether to affect the segment link state of the LSP(B-A-F-E) which had saved on both node.if the segment link state of the LSP has be changed. the source node B of the LSP service would switch to protecting LSP path(B-C-D-E) to transport it. At the same time, the sink node E of the LSP Service would select protecting LSP path to accept service. Liu, et al. Expires June 17, 2012 [Page 8] Internet-Draft MPLS-TP ring protection December 2011 +---+ @@@@@@@@ +---+ | F |-----X-------| A | +---+ +---+ @/ \@ @/ \@ @/ \@ +---+ +---+ sink node --| E | | B |Source node +---+ +---+ #\ /# #\ /# #\ /# +---+ +---+ | D |-------------| C | +---+ # # # # +---+ NOTE: @: working LSP path; #: protecting LSP path; X: failure Figure 5 when the failure is clear, node A or F would generate state notify message of defect-free to all other nodes of the ring . so the source node B and the sink node E of the LSP service received the state notify message , they would still analysis which LSP service would be affected by state changing and adopt relative action.so they would restore to send and receive service packet by working lsp path(B-C-D-E). 3.2.2. P2MP Instance For P2MP service of the ring , it must be unidirectional and more than one egress nodes. it is difficult for ingress node or egress node to judge and analysis which P2MP LSP service would need to be switch by the failure only by state notify message and segment link state of the p2mp path. . when a failure has been detected by section CC&CV function, the node which detects the failure would generate state notify message and send it to all other nodes of the ring. when other nodes received the state notify message,the root node of the P2MP service firstly bridge to the working path and the protecting path . so it send the service to its egress nodes by differently Liu, et al. Expires June 17, 2012 [Page 9] Internet-Draft MPLS-TP ring protection December 2011 working path and protecting path. For egress nodes of the p2mp service. They will merge select one path to accept the service packet. when the defect is clear, the node which detects defect-free will generate a state notify message of defect-free and send it to all other nodes of the ring. all other nodes receive the state notify message and restore only working path to transport the service packet. for root node of the p2mp service, it only send p2mp service packet by working path. while egress nodes will only select working path to accept the p2mp service packet. for example, there is a p2mp service from source node B to egress nodes F and E. its working path is B-C-D-[E]-[F] identified by signal(#) ,and its protecting path is B-A-[F]-[E] identified by singal(@).under normal condition, the service pakcet will be transported by working path B-C-D-[E]-[F] .just as the following figure 6: +---+ @@@@@@@@ +---+ sink node 2--- | F |-------------| A | +---+ +---+ @/# \@ @/# \@ @/# \@ +---+ +---+ sink node 1--| E | | B |Source node +---+ +---+ \# # / \# # / \# # / +---+ # # # # +---+ | D |-------------| C | +---+ +---+ NOTE: @: working path ; #: protecting path; Figure 6 when link C-D and link D-E failure happens, node C or node E that detects a defect will generate a state notify message of SF and send Liu, et al. Expires June 17, 2012 [Page 10] Internet-Draft MPLS-TP ring protection December 2011 it to all other nodes of the ring . when other nodes C,B,A,F receive the state notify message , they will make all p2mp source services be sent by both working path and protecting path firstly. eg. the service from B to E,F , root node B send the p2mp service packet separately by its working path B-C-D-[E]-[F] and its protecting path B-A-[F]-[E]. As there is a defect in separately C-D link and D-E link, for the egress nodes E and F, they will not receive service packet by its working path B-C-D-E-F. so they must select its protectiong path B-A-[F]-[E] to receive the service packet just as the following figure 7: +---+ @@@@@@@@ +---+ sink node 2--- | F |-------------| A | +---+ +---+ @/ \@ @/ \@ @/ \@ +---+ +---+ sink node 1--| E | | B |Source node +---+ +---+ \ / X / \ / +---+ +---+ | D |-----X------| C | +---+ +---+ NOTE: @: transport service by protecting path X: failure Figure 7 when the defect is clear , the node C ,E will generate a state notify message of defect-free and send it to all other nodes of the ring. when other nodes receive the state notify message , each node will restore to send and receive its own service only by its own working path .for example,the p2mp service from B to E,F will restore to working path B-C-D-[E]-[F] to send and receive the p2mp service packet as the following 8. Liu, et al. Expires June 17, 2012 [Page 11] Internet-Draft MPLS-TP ring protection December 2011 +---+ sink node 2--- | F |-------------| A | +---+ +---+ #/ \ #/ \ #/ \ +---+ +---+ sink node 1--| E | | B |Source node +---+ +---+ #\ /# #\ /# #\ /# #\ /# +---+ +---+ | D |-------------| C | +---+ # # # # # +---+ NOTE: #: transport service X: failure Figure 8 4. Security Considerations The security considerations for the authentication TLV need further study. 5. IANA Considerations TBD. 6. Acknowledgments thank Huub van Helvoort ,Italo Busi, Yaacov Weingarten, malcolm.betts and other experts providing some good comments and advices for this draft. 7. References Liu, et al. Expires June 17, 2012 [Page 12] Internet-Draft MPLS-TP ring protection December 2011 7.1. Normative References [IETF RFC4090] IETF, "IETF RFC4090(Fast Reroute Extensions to RSVP-TE for LSP Tunnels)", May 2005. [IETF RFC5654] IETF, "IETF RFC5654(Requirements of an MPLS Transport Profile)", september 2009. [IETF RFC5921] IETF, "IETF RFC5921(A Framework for MPLS in Transport Networks)", July 2010. [IETF RFC6372] IETF, "IETF RFC6372(Multiprotocol Label Switching Transport Profile Survivability Framework)", September 2011. [IETF RFC6378] IETF, "IETF RFC6379(Multiprotocol Label Switching Transport Profile Linear protection)", November 2011. [IETF RFC6427] IETF, "IETF RFC6427(Multiprotocol Label Switching Transport Profile Fault Management)", November 2011. [RFC 5586] IETF, "IETF RFC5586(MPLS Generic Associated Channel)", June 2009. 7.2. Informative References [ITUT-G.8132 Draft] ITU-T, "Draft ITU-T Recommendation G.8132(T-MPLS shared protection ring)", February 2008. [MPLS-TP Ring protection] Y. Weingarten, S. Bryant, N. Sprecher, D. Ceccarelli,D. Caviglia, F. Fondelli, M. Corsi, "MPLS-TP Ring Protection", August 2010. [MPLS-TP Ring protection switching] Igor Umansky, Huub van Helvoort, "MPLS-TP Ring Protection Switching (MRPS)", August 2010. Liu, et al. Expires June 17, 2012 [Page 13] Internet-Draft MPLS-TP ring protection December 2011 7.3. URL References [MPLS-TP-22] IETF - ITU-T Joint Working Team, "", 2008, . Authors' Addresses Liu guoman ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871606 Email: liu.guoman@zte.com.cn Ji Yuefeng BUPT University Beijing University of Posts and Telecommunications beijing 100876 P.R.China Email: jyf@bupt.edu.cn Yu jinghai ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52877162 Email: Yu.jinghai@zte.com.cn Liu, et al. Expires June 17, 2012 [Page 14]