[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

MPLS Working Group                                                G. Liu
Internet-Draft                                                   J. Yang
Intended status: Standards Track                                l. Jiang
Expires: March 29, 2011                                            z. Fu
                                                         ZTE Corporation
                                                      September 25, 2010


    Multiprotocol Label Switching Transport Profile Ring Protection
                  draft-liu-mpls-tp-ring-protection-01

Abstract

   according to RFC 5654 MPLS-TP Requirement, there are two requirements
   : requirement 56.B Recovery techniques used for P2P and P2MP should
   be identical to simplify implementation and operation.another
   requirement 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
   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.

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 March 29, 2011.

Copyright Notice




Liu, et al.              Expires March 29, 2011                 [Page 1]


Internet-Draft           MPLS-TP ring protection          September 2010


   Copyright (c) 2010 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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  proposed ring protection solution  . . . . . . . . . . . . . .  4
     3.1.  sub-path tunnel protection solution  . . . . . . . . . . .  4
     3.2.  Extend Steering protection . . . . . . . . . . . . . . . .  8
       3.2.1.  P2P Service Protection . . . . . . . . . . . . . . . .  8
       3.2.2.  P2MP Service Protection  . . . . . . . . . . . . . . . 10
     3.3.  Comparison . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 15
     7.3.  URL References . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16



















Liu, et al.              Expires March 29, 2011                 [Page 2]


Internet-Draft           MPLS-TP ring protection          September 2010


1.  Introduction

   this draft mainly describes two new ring protection solutions,
   solution 1 is based on sub-path Tunnel protection solution to
   implement to protect all kind of service by protecting sub-path when
   there are a few faults or defects in the ring .and there are fewer
   Sub-Path Tunnels to be set up in the ring network. while solution 2
   is based on Steering protection solution of G.8132 to be able to
   implement to protect P2P or P2MP service very quickly. at last it
   provides the comparsion of the two ring protection solutions from the
   view of a protection performance and effect.


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 29, 2011                 [Page 3]


Internet-Draft           MPLS-TP ring protection          September 2010


   LER: Label Edge Router

   PST: Path Segment Tunnel

   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 failure of the ring by OAM or APS functions,so that the source
   node of working sub-path tunnel and LSP path will switch these
   protected services into protecting sub-path tunnel and LSP path.but
   the two ring protection solutions also have a few differences.
   solution 1 provide protection of all failure LSP services of a
   working sub-path tunnel by setting up protecting sub-path tunnel
   ,while the later ring protection solution provides one dedicate
   protection path for each working LSP path to protect and recovery all
   failure services in the ring.

3.1.  sub-path tunnel protection solution

   This ring protection solution in MPLS-TP network mainly make use of
   protecting sub-path tunnel to protect all LSP services of a failure
   working sub-path tunnel .firstly two prime transfer nodes will be
   selected for the ring. and the two prime transfer nodes would backup
   for each other to ensure to transport service under the condition
   that one prime transfer node has failure. and other nodes in the ring
   need to pre-configured and set up two bidirectional sub-path tunnel
   separately in the direction of clockwise and anticlockwise along the
   ring to the two prime transfer nodes ; and there is CC or CV packet
   to verify the connectivity of every sub-path tunnel.and each sub-path
   Tunnel will reserve 50 percent bandwidth or capacity to use for
   protecting another working sub-path tunnel.

   when an end node of a working sub-path tunnel detects a failure in
   its own sub-path tunnel by OAM fucntion, it will generate a State
   notify message (APS or PSC) to send to another end node of the sub-
   path tunnel through pre-configured relative protecting sub-path. and
   the frame format of the state notify message is as the following:










Liu, et al.              Expires March 29, 2011                 [Page 4]


Internet-Draft           MPLS-TP ring protection          September 2010


        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | 0001|  0000 |      00000000    | channel type (APS or PSC)|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                           |
        |                state control message                      |
        |                                                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                                 Figure 1


   when another end node of the sub-path tunnel received State Notify
   messgae from peer node, it would process the message and switch to
   its relative protecting sub-path to transport all LSP Services of the
   failure working sub-path tunnel. for example, there is the following
   ring include A ,B, C,D,E,F node. and A and D node is configured as
   two prime transfer nodes separately for the ring.while working and
   protecting sub-path tunnel will be set up and pre-configured between
   two primer transfer nodes A ,D and other nodes include B,C,D,E,F.it
   will need to configure and set up 16 sub-path tunnel in the ring. for
   C node, there need to set up four bidirectional sub-path
   tunnels,which are separately working sub-path tunnel(A-B-C)
   identified by signal (@) and protecting sub-path tunnel ( A-F-E-D-C)
   identified by signal (#) between Prime node A and source node C . at
   the same time, they are including bidirectional working sub-path
   tunnel(C-D) identified by signal(*) and protecting sub-path tunnel(C-
   B-A-F-E-D) identified by signal($) between prime node D and soure
   node C, as the following figure.






















Liu, et al.              Expires March 29, 2011                 [Page 5]


Internet-Draft           MPLS-TP ring protection          September 2010


                                                   Prime node
                                                      |
                                  +---+  ########   +---+
                                  | F |-------------| A |
                                  +---+  $ $ $ $    +---+
                                  #/$                  $ \@
                                 #/$                    $ \@
                                #/$                      $ \@
                              +---+                     +---+
                 sink node----| E |                     | B |
                              +---+                     +---+
                                #\$                      $ /@
                                 #\$                    $ /@
                                  #\$                  $ /@
                                  +---+  * * * * *  +---+
                                  | D |-------------| C |
                                  +---+   ######    +---+
                                    |             source node
                                 Prime 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


   For a LSP service from source node C to sink node E ,under normal
   contidion,it would push into working sub-path tunnel (w)PCA|LC(A)|BOS
   firstly,then it will pop sub-path tunnel label and swap LSP label in
   the prime transfer node A .and then push into another sub-path tunnel
   (w)PAE|LA(E)|BOS and transport to sink node E. here PXY denotes a
   sub-path tunnel 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. when it detects a
   failure in the working sub-path tunnel(C-B-A) by OAM function as the
   following figure.









Liu, et al.              Expires March 29, 2011                 [Page 6]


Internet-Draft           MPLS-TP ring protection          September 2010


                                                        Prime node
                                                           |
                                       +---+  # # # #    +---+
                                       | F |-------------| A |
                                       +---+             +---+
                                       #/                   \@
                                      #/                     \@
                                     #/                       \@
                                   +---+                     +---+
                      sink node----| E |                     | B |
                                   +---+                     +---+
                                     #\                       /@
                                      #\                     X
                                       #\                   /@
                                       +---+             +---+
                                       | D |-------------| C |
                                       +---+   # # # #   +---+
                                         |             source node
                                      prime node
                                  NOTE:
                                      @: working sub-path Tunnel
                                      #: protecting sub-path Tunnel
                                      X: failure




                                 Figure 3


   for example, there is a failure in the link(C-B),all LSP services
   which would be carried and sent between C and prime node A by working
   sub-path tunnel(C-B-A) should switch to protecting sub-path tunnel(C-
   D-E-F-A) and push into protecting sub-path tunnel(P)PCA|LC(A)|BOS and
   be transported by the protecting sub-path tunnel if the protecting
   sub-path tunnel has no failure at the same time. when it arrived at
   the prime node A through the protecting sub-path tunnel, the outer-
   top SPME label would be poped and swap LSP label in the prime
   transfer node A, then the LSP service would push into another working
   sub-path tunnel (w)PAE|LA(E)|BOS and be carried to sink node E .in
   addtion, when the prime transfer node A is bad or the relative
   protecting sub-path tunnel has failure too, another prime transfer
   node D will become active prime transfer node for the LSP service.
   All LSP services of working sub-path tunnel(C-B-A) would push into
   working sub-path tunnel(C-D) (w)PCD|LC(D)|BOS to be sent to backup
   prime node D, and then POP outer-top sub-path tunnel label and swap
   LSP label.then the LSP serivce would push into another sub-path
   tunnel (w) PDE|LD(E)|BOS and be carried and sent to sink node E.



Liu, et al.              Expires March 29, 2011                 [Page 7]


Internet-Draft           MPLS-TP ring protection          September 2010


   From the number of configuring sub-path tunnel, if there are n nodes
   in the ring , there only need to set up and configure (n-2)*2 working
   sub-path tunnels and (n-2)*2 protecting sub-path tunnel. if
   configuring one working sub-path tunnel and one protecting sub-path
   tunnel between each node and other nodes of the ring , then there
   need to set up and configure O(n^2) sub-path tunnels. so this
   solution may solve the N square problem.

3.2.  Extend Steering protection

   This ring protection solution can extend G.8132 Steering protection
   solution to simply , quickly and effectively protect LSP service
   include p2p or p2mp in the MPLS-TP network ring. in order to protect
   and restore all failure services when a failure has happened in the
   ring. firstly each LSP path 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 OAM
   function of section layer, a state notify message packet will be
   generated and sent to other nodes in the ring by control channel or
   other channel very quickly for the first three packets. when other
   nodes receive the state notify message packet, they would analysis
   and judge which LSP service would be affected by the failure by state
   notify message or PRO of each LSP in the node.

3.2.1.  P2P Service Protection

   if the LSP service affected by the failure is P2P service , the
   source node of the LSP service would switch into its own protecting
   LSP path to transport to the sink node. while the sink node of the
   LSP service would select protecting LSP path to receive the service
   .for example , now there is a LSP service from B to E as the
   following figure. its working LSP path is B-A-F-E identified by
   singal @, while its protecting LSP path is B-C-D-E, Under normal
   state, the LSP service would be sent by the working LSP path in the
   source node .while be received by selecting working LSP path in the
   sink node .















Liu, et al.              Expires March 29, 2011                 [Page 8]


Internet-Draft           MPLS-TP ring protection          September 2010


                                  +---+  @@@@@@@@   +---+
                                  | F |-------------| A |
                                  +---+             +---+
                                  @/                   \@
                                 @/                     \@
                                @/                       \@
                              +---+                     +---+
                 sink node  --| E |                     | B |Source node
                              +---+                     +---+
                                #\                       /#
                                 #\                     /#
                                  #\                   /#
                                  +---+             +---+
                                  | D |-------------| C |
                                  +---+  # # # #    +---+

                             NOTE:
                                 @: working LSP path;
                                 #: protecting LSP path;




                                 Figure 4


   if there is a failure in the working LSP path. for example a failure
   happened in the link A-F as the following figure.node A or F would
   detect a failure by section CC&CV packet firstly. then node A or F
   would generate state notify message to other nodes in the ring. when
   other nodes of the ring received the state notify message , they
   would receive and process the state notify message. for the source
   node B and sink node E of the LSP service, they would analysis and
   judge whether the LSP service would be affected by the failure based
   by state notify message and PRO of each LSP in the node. as the
   link(A-F) failure would affect working LSP path of the LSP Service.
   the source node B of the LSP service would switch to bridge to
   protecting LSP path.  At the same time, the sink node E of the LSP
   Service would select protecting LSP path to accept service.












Liu, et al.              Expires March 29, 2011                 [Page 9]


Internet-Draft           MPLS-TP ring protection          September 2010


                                  +---+  @@@@@@@@   +---+
                                  | 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 failure clear
   notify message to other nodes of the ring . when the source node B
   and the sink node E of the LSP service received the failure clear
   notify message , they would restore to send and receive service
   packet from working LSP path.

3.2.2.  P2MP Service Protection


   For P2MP service of the ring , it must be unidirectional path and
   more than one egress nodes. it is difficult for source node or sink
   node to judge and analysis which P2MP LSP service would be affected
   by the failure only based by state notify message. so when a failure
   has been detected by section CC&CV function, the nodes which detect
   the failure would generate state notify message to send to other
   nodes of the ring. when other nodes received the state notify
   message,the source nodes of P2MP service firstly make their p2mp
   services bridge to the working path and the protecting path and send
   the service to its destination node along the directions of working
   path and protecting path. if a node in the ring is destination node
   for p2mp service.  It will merge select a direction of path to accept



Liu, et al.              Expires March 29, 2011                [Page 10]


Internet-Draft           MPLS-TP ring protection          September 2010


   service packet.  Then each sink node will detect whether the
   direction of receive service packet is changable. if it happens, the
   sink nodes will periodically generate the message of receiving state
   changing and send to its source node for the p2mp service. when the
   source node for the p2mp service receives all the messages from other
   sink nodes and processes them, judge whether all sink nodes of the
   p2mp service s in the same direreceive the service packetction
   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). when the failure is
   clear, the nodes which detect free-failure 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
   the message of receiving state changing periodically ,all service
   packets will come back to be transported in the working path. at the
   same time , each sink node for the service will select the direction
   of working path to receive service packet as idle state condition.

   the implement in detail as the following figure. for example, there
   is a p2mp service from source node B to sink node F,E. and working
   path is B-C-D-[E]-[F] identified by signal(#) ,while protecting path
   is B-A-[F]-[E] identified by singal(@).under normal situation,the
   service pakcet will be transported by working path B-C-D-[E]-[F].




                                  +---+  @@@@@@@@   +---+
                   sink node 2--- | F |-------------| A |
                                  +---+             +---+
                                  @/#                   \@
                                 @/#                     \@
                                @/#                       \@
                              +---+                     +---+
                 sink node 1--| E |                     | B |Source node
                              +---+                     +---+
                                 \#                      # /
                                  \#                    # /
                                   \#                  # /
                                  +---+  # # # #    +---+
                                  | D |-------------| C |
                                  +---+             +---+

                             NOTE:
                                 @: working path ;
                                 #: protecting path;




Liu, et al.              Expires March 29, 2011                [Page 11]


Internet-Draft           MPLS-TP ring protection          September 2010


                                 Figure 6


   when link C-D and link D-E failure happens, node C or node E that
   detects a failure will generate a state notify message packet to send
   to other nodes in the ring through control channel or other channel.
   when other node C,B,A,F receive the state notify message packet, they
   will make all source services bridge to working path and protecting
   path firstly. eg. the service from B to E,F , node B firstly send the
   service packet separately along its working path B-C-D-[E]-[F] and
   its protecting path B-A-[F]-[E].  As there are the failures in C-D
   link and D-E link, the sink node E ,F will not receive service packet
   by its working path B-C-D-E-F. so the two sink nodes E ,F must merge
   select its protectiong path B-A-[F]-[E] to receive the service
   packet.at the same time.  As the sink node E, F is sink nodes of the
   p2mp service ,so the node E,F will generate the message of receiving
   state changing and send to source node B of the p2mp service
   periodically. so source node B will receive the message and process
   the message. because both sink nodes receive service packet from
   their protecting path. then the source node B 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:
                                 @: transport service by protecting path
                                 X: failure



                                 Figure 7



Liu, et al.              Expires March 29, 2011                [Page 12]


Internet-Draft           MPLS-TP ring protection          September 2010


   when the failure is clear , the node C,E detect the failure state
   have been clear up, 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 by its own working path .eg,the p2mp
   service from B to E,F will come back to working path B-C-D-[E]-[F] to
   send and receive its own service packet as the following. at the same
   time, all sink nodes of p2mp services would stop generating and
   sending the message of receiving state changing at once.




                                  +---+
                   sink node 2--- | F |-------------| A |
                                  +---+             +---+
                                  #/                   \
                                 #/                     \
                                #/                       \
                              +---+                     +---+
                 sink node 1--| E |                     | B |Source node
                              +---+                     +---+
                                #\                       /#
                                 #\                     /#
                                  #\                   /#
                                   #\                 /#
                                  +---+             +---+
                                  | D |-------------| C |
                                  +---+  # # # # #  +---+

                             NOTE:
                                 #: transport service
                                 X: failure



                                 Figure 8


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 29, 2011                [Page 13]


Internet-Draft           MPLS-TP ring protection          September 2010


           +-----------------+----------+------------
          |      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  |  less    |   more     |
          |   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     |          |            |
          |                 |          |            |
          +-----------------+----------+------------+
          |    time of      |   slow   |   fast     |
          |   recovery      |          |            |
          +-----------------+----------+------------+



                               Table 1: comparison of ring protection



                                 Figure 9




Liu, et al.              Expires March 29, 2011                [Page 14]


Internet-Draft           MPLS-TP ring protection          September 2010


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

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.

   [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 Fault Management]
              G. Swallow,A. Fulignoli,M. Vigoureux,S. Boutros,D. Ward ,
              "MPLS Fault Management OAM", July 2010.




Liu, et al.              Expires March 29, 2011                [Page 15]


Internet-Draft           MPLS-TP ring protection          September 2010


   [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.

   [MPLS-TP Survivability Framework]
              N. Sprecher, A. Farrel, "Multiprotocol Label Switching
              Transport Profile Survivability Framework", June 2009.

7.3.  URL References

   [MPLS-TP-22]
              IETF - ITU-T Joint Working Team, "", 2008,
              <http://www.example.com/dominator.html>.


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











Liu, et al.              Expires March 29, 2011                [Page 16]


Internet-Draft           MPLS-TP ring protection          September 2010


   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


   Fu zhentao
   ZTE Corporation
   No.68, Zijinghua Road, Yuhuatai District
   Nanjing  210012
   P.R.China

   Phone: +86 025 52877162
   Email: fu.zhentao@zte.com.cn

































Liu, et al.              Expires March 29, 2011                [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/