MPLS Working Group G. Liu Internet-Draft J. Yang Intended status: Informational l. Jiang Expires: March 18, 2010 X. Dai ZTE Corporation September 14, 2009 Multiprotocol Label Switching Transport Profile Ring Protection draft-liu-mpls-tp-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. 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), 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 March 18, 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. Liu, et al. Expires March 18, 2010 [Page 1] Internet-Draft MPLS-TP ring protection September 2009 Abstract according to MPLS-TP Requirement draft, there are two requirements : requirement 56.B Recovery techniques used for P2P and P2MP should be identical to simplify implementation and operation.another require as section 2.5.6.1 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 a maintenance operation. this decument will describle and provide two types of ring protection solutions. both solutions can satisfy these requirements of recovery in mpls-tp ring network. 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.3. Comparison . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Liu, et al. Expires March 18, 2010 [Page 2] Internet-Draft MPLS-TP ring protection September 2009 1. Introduction this draft mainly introduce two new ring protection solutions, solution 1 is based on MPLS FRR-bypass solution to realize to protect all kind of service(eg. P2P or p2mp) when there are a few fault or detects in the ring at the same time. while solution 2 is based on G.8132 Steering protection solution to be able to realize to protect P2P or P2MP services very rapidly. at last it provide the comparsion of the two ring protection solutions from the view of a protection performance. 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 Liu, et al. Expires March 18, 2010 [Page 3] Internet-Draft MPLS-TP ring protection September 2009 3. proposed ring protection solution this section mainly proposed two kinds of ring protection solution.the two ring protection solutions can need to detect and notify the failure of the ring by MPLS or MPLS-TP OAM functions,so that the source node or the local failure node will switch these relative services to protection path.but the two ring protection solutions also have a few differences. solution 1 provide protection of all failure services by setting up protection tunnel,while the later ring protection solution provide one dedicate protection path for each working LSP path to protect and recovery all failure services in the ring. 3.1. Solution 1 The ring protection solution in MPLS-TP network mainly make use of protection tunnel to protect all failure services.firstly a prime node will be choosed in the ring. at the same time. in order to continue to protect all failure services when the prime node have a failure, a secondary node will be choosed to be backup node for the prime node in the ring. and other node in the ring need to pre- configured and set up a bidirectional protection tunnel to the prime node and the secondary node; and there is BFD function packet to detect link or node failure between two directly interconnection node in the ring. when a node of the ring detects a failure include link failure or peer node failure, it will generate a failure notify message to send to prime node and secondary node of the ring by pre-configured protection tunnel. and the frame format of the failure notify message is as the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0001| 0000 | 00000000 | channel type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP identifier TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 NOTE: LSP Identifier TLV: a standard TLV frame construct. including Type , Liu, et al. Expires March 18, 2010 [Page 4] Internet-Draft MPLS-TP ring protection September 2009 Length,and Value, and the value field may be divided into two parts: the former is the identifier of LSP path, the later is Entry Label of the LSP path in the ring. this LSP Identifier TLV format is as the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | Length | LSP Identifier | Entry label| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 NOTE: LSP Identifier: it identify solely LSP path in the ring, eg: TTSI; Entry Label: Local Entry Label of the LSP Path in the node . when the prime node of the ring received the failure notify message packet from two end nodes that have detected the failure. the prime node will bind the relation of the two protection tunnel .so the failure notify messages that have received from a protection tunnel can continue to transport by another protection tunnel. at last the failure notify message will be transported to another upstream node. and the upstream node receives the failure notify message packet and analysises the message packet. if the failure notify message has no any LSP Identifier TLV or NULL TLV, all working LSP services in the upstream node are still transported by working label. or else it will look up label swithing table by LSP Identifier in LSP Identifier TLV. if there exist a few working services that need to switch into protection path. Entry Label in LSP Identifier TLV will replace of the export label for the same LSP Identifier. when a normal service packet reachs the node, the node will change switch label into entry label of LSP Identifier TLV ,Then the service packet will be transported by protection tunnel between the node and the prime node in the ring. when the prime node receives the service packet from the upstream node.the service packet will continue to be tranported in another protection tunnel that has already been bound by switching label of protection tunnel layer. at last the service packet will be transported to the downstream node and continue to be transported in original working LSP like wrapping solution. the implement in detail as the following figure : Liu, et al. Expires March 18, 2010 [Page 5] Internet-Draft MPLS-TP ring protection September 2009 secondary node Prime node | +---+ @@@@@@@@ +---+ sink node---- | F |-------------| A | +---+ +---+ @/ \@ @/ \@ @/ \@ +---+ +---+ | E | | B |Source node +---+ +---+ \ /@ X /@ \ /@ +---+ +---+ | D |-----X------| C | +---+ +---+ NOTE: @@@@@@: protection tunnel path X: failure Figure 3 if there is a service from node B to node F , under the normal condition,the service will be transported by B-C-D-E-F working path. when there is a failure individually in link (C-D) and link(D-E), firstly C,D,E node will detect the failure by BFD function and the three node will generate a failure notify message individually and send the failure notify message packet to the prime node A and the secondary node F by their own specail protection tunnels.as the D node have already been a isolate point , its failure notify message will not be transported to the prime node by its own protection tunnel. only the failure notify message from C,E node will be transported to the prime node A individually through C-A and E-A protection tunnel.when prime node A receives failure notify message from C and E node protection tunnel. it will bind the two protection tunnels and the failure notify message packet from C will be sent to E node. at the same time. the failure notify message packet from E node will be sent to C node. and for the service from B to F , C will be upstream node to E node. when C node receive the failure notify message from E , It will look up its own switching table by LSP Identifier in the LSP Identifier TLV. we suppose that entry label is 1 and export label is 2 at the C node for the service from B to F , while entry label is 100 and out label is 200 at the E node for the Liu, et al. Expires March 18, 2010 [Page 6] Internet-Draft MPLS-TP ring protection September 2009 service and the service LSP Identifer is 300 under normal condition. when a failure have happened ,C node will look for which LSP Identifier is 300. if it find the LSP service. and the service will be transported by protection path and entry label in E node will replace of export label in C node for the service from B to F node. then the service packets in C node will be transported to the prime node A by C to A protection tunnel path. then by switching protection tunnel, the service packets will be transported to E by A-E protection tunnel.at last the serivce packets will be tranported by switching originate working LSP path and to destination node F. when the nodes detect no failure in the ring. They will send a free- failure notify message packet to the prime node A and the secondary node F through their own protection tunnel.and the prime node A receives the free-failure notify message packet and sends to its upstream node , so the upstream node will make all service pakcets be transported by originate working LSP path. 3.2. Solution 2 This ring protection solution can extend G.8132 Steering protection solution to simply , quickly and effectively protect all service include p2p or p2mp in the MPLS-TP ring. in order to protect and restore all failure services when a failure has happened in the ring. firstly each LSP service should configure one working LSP path and one protecting LSP path in the ring. and the direction of the two LSP path is reverse in the ring. when a failure has been detected by BFD function, a failure notify message packet will be generated and sent to other nodes in the ring by control channel or other channel. when other nodes receive the failure notify message packet, they firstly make their source services bridge to the working path and the protecting path and double send the service to its destination node in the directions of working path and protecting path. if a node in the ring is destination node for a service. It will select a direction of path to receive service packet. each sink node will detect whether the direction of receive service packet is changable. if it happens, the sink node will return the message of receiving state change to its source node for a LSP service. when the source node for a LSP service receives all messages from other sink nodes and analysis. if all sink nodes receive service packets in the same direction include working path or protecting path. the source node of the service will select a path(working path or protecting path) to send service packet. or else it will continue to send service packet in the two path(working path and protecting path). after a period of time, when a node detects the failure is clear, the node will generate a free-failure notify message and send to all other nodes in the ring. all other nodes receive the free-failure notify message and stop sending double their service pakcets ,all service packets will Liu, et al. Expires March 18, 2010 [Page 7] Internet-Draft MPLS-TP ring protection September 2009 only be transported in the direction of working path. at the same time , each sink node for a service will select the direction of working path to receive service packet as normal condition. the implement in detail as the following figure : +---+ @@@@@@@@ +---+ sink node 2--- | F |-------------| A | +---+ +---+ @/ \@ @/ \@ @/ \@ +---+ +---+ sink node 1--| E | | B |Source node +---+ +---+ \ /@ X /@ \ /@ +---+ +---+ | D |-----X------| C | +---+ +---+ NOTE: @: direction of transport packet; X: failure Figure 4 If there is a P2MP service from source node B to sink node 1 E and sink node 2 F in the above ring.under normal situation,the service pakcet will be transported by working path B-C-D-[E]-[F]; when link C-D and link D-E failure happens, node C or node E that detects a failure will generate a failure notify message packet to send to other node in the ring through control channel or other channel. when other node C(E),B,A,F receive the failure notify message packet, they will make all source services bridge to working LSP path and protecting LSP path firstly. eg. the service from B to E,F , node B firstly send doule packet separately along its working path B-C-D-E-F and its protecting path B-A-[F]-[E]. As there are the failure in C-D link and D-E link, service sink node E ,F will not receive service packets by its working path B-C-D-E-F. so the two sink nodes must receive the service packet by its protectiong path B-A-[F]-[E].at the Liu, et al. Expires March 18, 2010 [Page 8] Internet-Draft MPLS-TP ring protection September 2009 same time. the sink node E, F have changed the direction of receiving service packet ,so the node E,F will generate the message of receiving state change and send to service source node B. so source node B will receive the message and anylisis the message. because both sink nodes receive service from their protecting path. so the source node will only select protecting path to send its service packet as the following figure: +---+ @@@@@@@@ +---+ sink node 2--- | F |-------------| A | +---+ +---+ @/ \@ @/ \@ @/ \@ +---+ +---+ sink node 1--| E | | B |Source node +---+ +---+ \ / X / \ / +---+ +---+ | D |-----X------| C | +---+ +---+ NOTE: @: direction of transport packet; X: failure Figure 5 when the failure is clear up, the node C,E detect the failure state have changed, the node C ,E will generate a free-failure notify message and send to all other nodes in the ring. when other nodes receive the free-failure notify message , each node will send and receive its own service only in the working path .eg,the p2mp service from B to E,F will return to working path B-C-D-[E]-[F] to send and receive its own service packet as the following. Liu, et al. Expires March 18, 2010 [Page 9] Internet-Draft MPLS-TP ring protection September 2009 +---+ sink node 2--- | F |-------------| A | +---+ +---+ @/ \ @/ \ @/ \ +---+ +---+ sink node 1--| E | | B |Source node +---+ +---+ @\ /@ @\ /@ @ \ /@ +---+ +---+ | D |-------------| C | +---+ @@@@@@@@ +---+ NOTE: @: direction of transport packet; X: failure Figure 6 3.3. Comparison The two ring protection solutions can fulfil MPLS-TP requirement of ring recovery. but there are different protection and recovery mechanism and different character, the detail is the following table: Liu, et al. Expires March 18, 2010 [Page 10] Internet-Draft MPLS-TP ring protection September 2009 +-----------------+----------+------------ | Items |solution 1|solution 2 | | | | | +-----------------+----------+------------+ | Amounts of the | Less | As many as | | backup LSP | | the | | | | protected | | | | LSP | +-----------------+----------+------------+ | Bandwidth | lower | high | | utilization | | | | ratio | | | +-----------------+----------+------------+ | Bandwidth share | Support | Support | +-----------------+----------+------------+ | the number of | more | less | | elements of , | | | | recovery | | | +-----------------+----------+------------+ | the number of | less | more | | OAM | | | +-----------------+----------+------------+ | complexity | simple | complex | +-----------------+----------+------------+ | Lable stack | Increase | Changeless | | | one more | | | | layer | | +-----------------+----------+------------+ | P2P and | Support | Support | | P2MP | | | | service | | | +-----------------+----------+------------+ | multi-failure | support | support | | recovery | | | | | | | +-----------------+----------+------------+ Table 1: comparison of ring protection Figure 7 Liu, et al. Expires March 18, 2010 [Page 11] Internet-Draft MPLS-TP ring protection September 2009 4. Security Considerations The security considerations for the authentication TLV need further study. 5. IANA Considerations TBD. 6. Acknowledgments TBD. 7. References 7.1. Normative References [IETF RFC4090] IETF, "IETF RFC4090(Fast Reroute Extensions to RSVP-TE for LSP Tunnels)", May 2005. [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 Framework] M. Bocci, S. Bryant, L. Levrau , "A Framework for MPLS in Transport Networks", August 2009. [MPLS-TP Requirements] B.Niven-Jenkins, D.Brungard, M.Betts,N. Sprecher ,S.Ueno, "MPLS transport profile Requirements", August 2009. [MPLS-TP Survivability Framework] N. Sprecher, A. Farrel, "Multiprotocol Label Switching Transport Profile Survivability Framework", April 2009. Liu, et al. Expires March 18, 2010 [Page 12] Internet-Draft MPLS-TP ring protection September 2009 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 Yang Jian ZTE Corporation 5F,RD 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 Jiang lili ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52871745 Email: jiang.lili@zte.com.cn Dai Xuehui ZTE Corporation No.68, Zijinghua Road, Yuhuatai District Nanjing 210012 P.R.China Phone: +86 025 52877162 Email: dai.xuihui@zte.com.cn Liu, et al. Expires March 18, 2010 [Page 13]