[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 draft-ietf-mpls-tp-shared-ring-protection

Network Working Group                                          WQ. Cheng
Internet-Draft                                                   L. Wang
Intended status: Informational                                     H. Li
Expires: April 18, 2013                                     China Mobile
                                                                  K. Liu
                                                                   J. He
                                           Huawei Technologies Co., Ltd.
                                                                   F. Li
                                                   Research Institute of
                                                       Telecommunication
                                           Transmission,China Academy of
                                             Telecommunication Research,
                                                             MIIT. China
                                                                 J. Yang
                                               ZTE Corporation P.R.China
                                                                 J. Wang
                                             Fiberhome Telecommunication
                                                    Technologies Co.,LTD
                                                        October 15, 2012


            MPLS-TP Shared Ring protection (MSRP) mechanism
             draft-cheng-mpls-tp-shared-ring-protection-00

Abstract

   This document describes requirements and solutions for MPLS-TP Shared
   ring protection (MSRP) in ring topology for point to point (P2P)
   services.  The mechanisms of MSRP are illustrated and analyzed how to
   satisfy the MPLS-TP requirements in RFC5654 for optimized ring
   protection.  MSRP could support wrapping and steering protection
   mechanisms for P2P services, which provide a simple and reliable
   protection switching.  The survivability of the network could be
   improved and the operation and maintain could be more easy.  Ring
   protection solution for p2mp services will be documented in another
   draft latterly.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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



Cheng, et al.            Expires April 18, 2013                 [Page 1]


Internet-Draft                    MSRP                      October 2012


   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 April 18, 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.































Cheng, et al.            Expires April 18, 2013                 [Page 2]


Internet-Draft                    MSRP                      October 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Problem statement  . . . . . . . . . . . . . . . . . . . .  4
       1.1.1.  Recovery for Multiple failures . . . . . . . . . . . .  4
       1.1.2.  Upgrade from linear protection to ring protection  . .  5
       1.1.3.  Configuration complexity . . . . . . . . . . . . . . .  5
     1.2.  Terminology and Notation . . . . . . . . . . . . . . . . .  5
     1.3.  Contributing Authors . . . . . . . . . . . . . . . . . . .  6
   2.  Shared ring protection for P2P . . . . . . . . . . . . . . . .  6
     2.1.  Basic conception . . . . . . . . . . . . . . . . . . . . .  6
       2.1.1.  The establishment of the Ring tunnels  . . . . . . . .  7
       2.1.2.  The distribution and management of ring labels . . . .  8
       2.1.3.  Failure detection  . . . . . . . . . . . . . . . . . .  9
     2.2.  P2P wrapping . . . . . . . . . . . . . . . . . . . . . . . 10
       2.2.1.  Wrapping Link Failure  . . . . . . . . . . . . . . . . 10
       2.2.2.  Wrapping node Failure  . . . . . . . . . . . . . . . . 11
     2.3.  P2P steering . . . . . . . . . . . . . . . . . . . . . . . 11
   3.  Coordination protocol  . . . . . . . . . . . . . . . . . . . . 14
   4.  Conclusions and Recommendations  . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15



























Cheng, et al.            Expires April 18, 2013                 [Page 3]


Internet-Draft                    MSRP                      October 2012


1.  Introduction

   As described in 2.5.6.1.  Ring Protection of MPLS-TP requirements
   [RFC5654], several service providers have expressed a high level of
   interest in operating MPLS-TP in ring topologies and require a high
   level of survivability function in these topologies.  MPLS-TP
   networks are often constructed with ring topologies which allow
   service providers setting up a efficient and optimized ring
   protection mechanism to achieve simplified operation and fast
   recovery performance.

   The requirements for MPLS-TP [RFC5654] state that recovery mechanisms
   are optimized for Ring topologies may be developed if it can provide
   following optimization scenarios:

   a.  Minimize the number of OAM entities for protection

   b.  Minimize the number of elements of recovery

   c.  Minimize the number of labels required

   d.  Minimize the amount of control and management-plane transactions

   e.  Minimize the impact on information exchange if control plane
   supported

   This document specifies MPLS-TP Shared-Ring Protection mechanisms
   which can meet all those requirements on Ring protection listed in
   [RFC5654].

   This document focus on the solutions for Point-to-point transport
   path and a related topic in [RFC5654] states the required support for
   point-to-multipoint transport path.  The solution for point-to-
   multipoint solution is under evaluation and will be illustrated in a
   separate document based on the basic conception in this document.

1.1.  Problem statement

1.1.1.  Recovery for Multiple failures

   MPLS-TP is expected to be used in carrier grade metro networks and
   backbone networks for providing mobile backhauling, business
   customers' services and etc., in such kind of application scenarios
   the network survivability are very important.

   According to R106 B in RFC5654, MPLS-TP recovery mechanisms in a ring
   SHOULD protect against multiple failures.  It's expected deploying
   ring protection in ring topology could enhance the network



Cheng, et al.            Expires April 18, 2013                 [Page 4]


Internet-Draft                    MSRP                      October 2012


   survivability to against multiple failures in many cases.  Following
   context provide some more detail illustration to "multiple failures".

   In metro and backbone networks, the single risk factor often affects
   multiple links or nodes.  Some examples of risk factors are given in
   follows:

   - multiple links using fibers in one cable or pipeline

   - Several nodes shared one power supply system

   - weather sensitive micro-wave system

   Once one risk factor happens, multiple near-simultaneous links or
   nodes failures occur and those failed links or nodes may locate on
   single ring as well as on interconnected multiple rings.  The ability
   of ring protecting against multiple failures should cover both
   multiple failures on single ring scenario and multiple failures on
   interconnected multiple rings.

1.1.2.  Upgrade from linear protection to ring protection

   It is beneficial for service providers to upgrade their MPLS-TP based
   network from the linear protection to ring protection without service
   interruption, and supporting in-service insertion and removal of a
   node on the ring.  In order to realize this requirement, the ring
   protection Mechanisms should be developed and optimized to comply
   with this upgrading principle.

1.1.3.  Configuration complexity

   In the application scenarios of deploying linear protection in
   MPLS-TP network, the configuration of protection has close
   relationship with the services, LSP quantities.  Especially in some
   large metro networks with more than ten thousands of services access
   node, the LSP linear protection capabilities of the metro core nodes
   should be large enough to meet the network planning requirements,
   which also leads to the complexity of network protection
   configurations and operations.  While the ring protection is based on
   the mechanisms on section layer, it has loose relationship with the
   services quantities which could simplify the network protection
   configurations and operations.

1.2.  Terminology and Notation

   The following syntax will be used to describe the contents of the
   label stack:




Cheng, et al.            Expires April 18, 2013                 [Page 5]


Internet-Draft                    MSRP                      October 2012


   1.  The label stack will be enclosed in square brackets ("[]").

   2.  Each level in the stack will be separated by the '|' character.

   It should be noted that the label stack may contain additional levels
   however, we only present the levels that are germane to the
   protection mechanism.

   3.  If the Label is assigned by Node x, the Node Name will enclosed
   in bracket(" ()")

1.3.  Contributing Authors

   Wen Ye(China Mobile)


2.  Shared ring protection for P2P

   None

2.1.  Basic conception

   This document introduces an independent logic layer of ring for both
   working path and protection path for shared ring protection in
   MPLS-TP networks.  The logic layer is a ring tunnel on top of the
   working path or the protection path as shown in Figure 1, namely
   working ring tunnel or protection ring tunnel respectively.  Once the
   ring tunnel is established, the configuration, management and
   protection of the ring are all based on the ring tunnel.  One port
   can carry more than one ring tunnel, while one ring tunnel can carry
   several LSPs.

                                               |-------------
                                 |-------------|
                   |-------------|             |
     =====PW1======|             |             |
                   |             |  Ring       |  Physical
     =====PW2======|    LSP      |  Tunnel     |  Port
                   |             |             |
     =====PW3======|             |             |
                   |-------------|             |
                                 |-------------|
                                               |-------------

                   Figure 1 the logic layers of the ring

   The label stack used in MPLS-TP Shared Ring Protection mechanism are
   shown as below.



Cheng, et al.            Expires April 18, 2013                 [Page 6]


Internet-Draft                    MSRP                      October 2012


                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |            Ring tunnel Label        |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                 LSP Label           |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                 PW Label            |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                 Payload             |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2 Label Stack used in MPLS-TP Shared Ring Protection

2.1.1.  The establishment of the Ring tunnels

   A ring tunnel is created as per exit node.  The exit node means the
   node on the ring where the traffic leaves the ring.  All the LSPs
   which transverse the ring and exit at the same ring node share the
   same working ring tunnels and protection ring tunnels.  For each exit
   node, 4 ring tunnels are established:

   - 1 clockwise working ring tunnel, protected by

   - 1 anticlockwise protection ring tunnel,

   - 1 anticlockwise working ring tunnel, protected by

   - 1 clockwise protection ring tunnel.

   An example is shown in Figure 3 where Node D behaves as an exit node.
   LSP 1 entering the ring at Node E, LSP2 at Node A and LSP 3 at Node
   B, all leave the ring at Node D. .  To protect these LSPs traversing
   the ring, a clockwise working ring tunnel (RcW_D), E->F->A->B->C->D
   and its protection ring tunnel in the reverse direction (RaP_D),
   D->C->B->A->F->E->D ; Ananticlockwise working ring channel (RaW_D),
   C->B->A->F->E->D and its clockwise protection ring tunnel (RcP_D),
   D->E->F->A->B->C->D are established for Node D. Figure 3 only shows
   RcW_D and RaP_D for readability.  The similar provisioning should be
   repeated for every other node on the ring.  The ring tunnels created
   for the other nodes in Figure 3 when acting as exit node are provided
   as follows:

   To Node A: RcW_A, RaW_A, RcP_A, RaP_A;

   To Node B: RcW_B, RaW_B, RcP_B, RaP_B;

   To Node C: RcW_C, RaW_C, RcP_C, RaP_C;

   To Node E: RcW_E, RaW_E, RcP_E, RaP_E;



Cheng, et al.            Expires April 18, 2013                 [Page 7]


Internet-Draft                    MSRP                      October 2012


   To Node F: RcW_F, RaW_F, RcP_F, RaP_F;

   In Node D, two working ring tunnels, RcW_D and RaW_D are terminated;
   and two protection ring tunnels, RcP_D and RaP_D, are transit.  That
   means through those working ring tunnels with protection ring
   tunnels, LSPs which enter the ring from Node D can reach any other
   nodes on the ring, while Node D can also receive the traffic from any
   other nodes.


                 +---+#############+---+
                 | F |-------------| A | +-- LSP2
                 +---+*************+---+
                 #/*                   *\#
                #/*                     *\#
               #/*                       *\#
             +---+                     +---+
      LSP1-+ | E |                     | B |+-- LSP3
             +---+                     +---+
               #\                       */#
                #\                     */#
                 #\                   */#
                 +---+*************+---+
       LSP1   +--| D |-------------| C |
       LSP2      +---+#############+---+
       LSP3

              ---- physical links
                    **** RcW_D
                    #### RaP_D

                   Figure 3 the Ring tunnels of the ring

2.1.2.  The distribution and management of ring labels

   Ring tunnel labels are distributed by means of downstream-assigned
   mechanism as defined in [RFC3031].  When an MPLS-TP transport path,
   e.g.  LSP, enters the ring, according to the ring ID and the exit
   node, the ingress node pushes the working ring tunnel label and sends
   the traffic to the next hop; The transit nodes of the working ring
   tunnel swap the ring tunnel label and forward the packets to the next
   hop; When arriving at the egress node, the egress node pops the ring
   tunnel label and forwards the packets based on the inner LSP label
   and PW label.Figure 4 shows the label operation in MPLS-TP Shared
   Ring Protection mechanism.  Suppose LSP 1 enters the ring at Node A
   and exit at Node D, the following label operations are executed.

   1.  The traffic LSP1 arrives at Node A with a label stack [LSP1] and



Cheng, et al.            Expires April 18, 2013                 [Page 8]


Internet-Draft                    MSRP                      October 2012


   is supposed to be forwarded in the clockwise direction of the ring.
   The clockwise working ring tunnel label RcW_D will be pushed at Node
   A, the label stack for the forwarded packet at Node A is changed to
   [RcW_D(B)|LSP1]

   2.Transit nodes, in this case Node B and C, forward the packet
   by swapping the working ring tunnel label.  For Example, the label
   [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node B.

   3.  When the packet arrives at Node D (i.e. egress node) with label
   stack [RcW_D(D)|LSP1], Node D Pops RcW_D(D) and further deals with
   the inner labels of LSP1.

   4.  All the LSPs exit at the same node share the same Ring tunnel
   label.


                         +---+#####[RaP_D(A)]######+---+
                         | F |---------------------| A | +-- LSP1
                         +---+*****[RcW_D(A)]******+---+
                          #/*                        *\#
               [RaP_D(F)]#/*[RcW_D(F)]       RcW_D(B)]*\#RaP_D(B)
                        #/*                            *\#
                      +---+                          +---+
                      | E |                          | B |
                      +---+                          +---+
                        #\                            */#
               [RaP_D(D)]#\                [RxW_D(C)]*/#RaP_D(C)
                          #\                        */#
                          +---+*****[RcW_D(D)]****+---+
                LSP1  +-- | D |-------------------| C |
                          +---+#####[RaP_D(C)]####+---+

                   -----physical links      ****** RcW_D    ###### RaP_D


                   Figure 4 Label operation of the ring

2.1.3.  Failure detection

   The MPLS-TP section layer OAM is used to monitor the connectivity
   between each two adjacent nodes on the ring using the mechanisms
   defined in [RFC6371].Protection switching occurs on the detection of
   failure on a link in the ring monitored by OAM functions.

   Two end ports of a link form a MEG, and an MEG end point (MEP)
   function is installed in each ring port.  Periodic CC-V OAM packets
   exchange is activated between each pair of MEPs to monitor the link



Cheng, et al.            Expires April 18, 2013                 [Page 9]


Internet-Draft                    MSRP                      October 2012


   health.  Sequential consecutive loss of CC-V packets (3 packets) is
   interpreted as a link failure.

   A node failure is regarded as the failure of two links attached to
   the node.  The two nodes adjacent to the failed node detect the
   failure on the links connected to the failed node.

2.2.  P2P wrapping

   Normal state is shown in Figure 4.  The clockwise LSP1 towards node D
   enters the ring at Node A. In normal state, LSP 1 follows the path
   A->B->C-D, label operation is [LSP1](original data traffic carried by
   LSP 1)->[RCW_D(B)|LSP1](NodeA)->[RCW_D(C)|LSP1](NodeB)->[RCW_D(D)|
   LSP1](NodeC)->[LSP1]( data traffic carried by LSP 1).  Then traffic
   packet will be forwarded on the basis of LSP1.

2.2.1.  Wrapping Link Failure

   When a link failure between Node B and Node C occurrs, both Node B
   and Node C detect the failure by OAM mechanism.  Node B switches the
   clockwise working ring tunnel(RcW_D) to the anticlockwise protection
   ring tunnel (RaP_D)and Node C switches anticlockwise protection ring
   tunnel(RaP_D) to the clockwisework ring tunnel(RcW_D).  The data
   traffic which enters the ring at Node A and exits at Node D follows
   the pathA->B->A->F->E->D->C->D. The label operation is
   [LSP1](Original data packet)-> [RcW_D(B)|LSP1](NodeA)-> [RaP_D(A)|
   LSP1](NodeB)->[RaP_D(F)|LSP1](NodeA)->[RaP_D(E)|LSP1] (NodeF)->
   [RaP_D(D)|LSP1] (NodeE)-> [RaP_D(C)|LSP1] (NodeD)-> [RcW_D(D)|
   LSP1](NodeC)->[LSP1](Exit data packet).


                          +---+#####[RaP_D(F)]######+---+
                          | F |---------------------| A | +-- LSP1
                          +---+*****[RcW_D(A)]******+---+
                          #/*                        *\#
               [RaP_D(E)]#/*[RcW_D(F)]      [RcW_D(B)]*\#RaP_D(A)
                        #/*                            *\#
                      +---+                          +---+
                      | E |                          | B |
                      +---+                          +---+
                        #\                            *x#
               [RaP_D(D)]#\                [RcW_D(C)]*x#RaP_D(B)
                          #\                        *x#
                          +---+*****[RcW_D(D)]****+---+
                LSP1  +-- | D |-------------------| C |
                          +---+#####[RaP_D(C)]####+---+

                -----physical links    xxxx Failure Link



Cheng, et al.            Expires April 18, 2013                [Page 10]


Internet-Draft                    MSRP                      October 2012


                ****** RcW_D           ###### RaP_D


                   Figure 5 Link Failure of P2P Wrapping

2.2.2.  Wrapping node Failure

   When Node B fails, Node A detects the failure between A and B and
   switches the clockwise work ring tunnel(RcW_D) to the anticlockwise
   protection ring tunnel(RaP_D), Node C detects the failure between C
   and B and switches the anticlockwise protection ring tunnel(RaP_D) to
   the clockwise working ring tunnel(RcW_D).  The data traffic which
   enters the ring at Node A and exits at Node D follows the path
   A->F->E->D->C->D. The label operation is [LSP1](original data traffic
   carried by LSP 1)-> [RaP_D(F)|LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)->
   [RaP_D(D)|LSP1](NodeE)-> [RaP_D(C)|LSP1] (NodeD)->[RcW_D(D)|LSP1]
   (NodeC)->[LSP1](data traffic carried by LSP 1).

                          +---+#####[RaP_D(F)]######+---+
                          | F |---------------------| A | +-- LSP1
                          +---+*****[RcW_D(A)]******+---+
                          #/*                        *\#
               [RaP_D(E)]#/*[RcW_D(F)]      [RcW_D(B)]*\#RaP_D(A)
                        #/*                            *\#
                      +---+                          xxxxx
                      | E |                          x B x
                      +---+                          xxxxx
                        #\                            */#
               [RaP_D(D)]#\                [RcW_D(C)]*/#RaP_D(B)
                          #\                       */#
                          +---+*****[RcW_D(D)]****+---+
                LSP1  +-- | D |-------------------| C |
                          +---+#####[RaP_D(C)]####+---+

                  -----physical links     xxxxxx  Failure Node
                  *****RcW_D              ######  RaP_D


                   Figure 6 Node Failure of P2P Wrapping

2.3.  P2P steering

   Each working ring tunnel is associated with a protection ring tunnel
   in the opposite direction.  Every node needs to know the ring
   topology by configuration or topology discovery.  When the failure
   occurs, the nodes which detect the failure will spread the fault
   information in the opposite direction node by node in the ring
   respectively.  When the node receives the message that informs the



Cheng, et al.            Expires April 18, 2013                [Page 11]


Internet-Draft                    MSRP                      October 2012


   failure, it will quickly figure out the location of the fault by the
   topology information that is maintained by itself, so that it will
   determine whether the LSPs enter the ring from itself needs switch-
   over.  If yes, it will switch the LSPs from the working ring tunnel
   to its protection ring tunnel.  If no, it will ignore the fault
   indication message.

                                                    +--LSP l
  +-+-+-+-+-+-+-+     +---+ ###[RaP_D(F)]### +---+  +-+-+-+-+-+-+-+
  |F|A|B|C|D|E|F|     | F | ---------------- | A |  |A|B|C|D|E|F|A|
  +-+-+-+-+-+-+-+     +---+ ***[RcW_D(A)]*** +---+  +-+-+-+-+-+-+-+
   |I|I|I|S|I|I|                                     |I|I|S|I|I|I|
   +-+-+-+-+-+-+      #/*                     *\#    +-+-+-+-+-+-+
         [RaP_D(E)]  #/*           [RcW_D(B)]  *\# [RaP_D(A)]
                    #/* [RcW_D(F)]              *\#
 +-+-+-+-+-+-+-+   #/*                           *\#
 |E|F|A|B|C|D|E| +---+                            +---+ +-- LSP 2
 +-+-+-+-+-+-+-+ | E |                            | B | +-+-+-+-+-+-+-+
  |I|I|I|I|S|I|  +---+                            +---+ |B|C|D|E|F|A|B|
  +-+-+-+-+-+-+     #\*                            */#   +-+-+-+-+-+-+-+
                     #\* [RcW_D(E)]    [RcW_D(C)] */#     |I|S|I|I|I|I|
         [RaP_D(D)]   #\*                        */#      +-+-+-+-+-+-+
                       #\*                      */# [RaP_D(B)]
 +-+-+-+-+-+-+-+       +---+     [RcW_D(D)]    +---+    +-+-+-+-+-+-+-+
 |D|E|F|A|B|C|D|  +--  | D | xxxxxxxxxxxxxxxxx | C |    |C|D|E|F|A|B|C|
 +-+-+-+-+-+-+-+ LSP 1 +---+     [RaP_D(C)]    +---+    +-+-+-+-+-+-+-+
  |I|I|I|I|I|S|  LSP 2                                   |S|I|I|I|I|I|
  +-+-+-+-+-+-+                                          +-+-+-+-+-+-+

         ----- physical links  ***** RcW_D  ##### RaP_D



      Figure 7 the P2P steering operation and protection switching(1)

   Steering Example is shown in figure 7.  LSP1 enters the ring from
   Node A while Node B has an LSP2, and both of them have the same
   destination node D. As per Figure 7, in normal state, LSP1 follows
   the path A->B->C->D, the label operation is [LSP1](original data
   traffic carried by LSP 1 )->[RcW_D(B)|LSP1](NodeA)->[RcW_D(C)|
   LSP1](NodeB)->[RcW_D(D)|LSP1](NodeC)->[LSP1] ( data traffic carried
   by LSP 1) .  LSP2 goes through the path B->C->D, the label operation
   is [LSP2]->[RcW_D(C)|LSP2](NodeB)->[RcW_D(D)|LSP2](NodeC)-> [LSP2] (
   data traffic carried by LSP 1) .

   If the link between C and D breaks down, as Figure 7 shows, according
   to the fault detection function of each link, Node D will find out
   that there is a failure in the link between C and D, and it will



Cheng, et al.            Expires April 18, 2013                [Page 12]


Internet-Draft                    MSRP                      October 2012


   update the link state of its ring topology, changing the link state
   between C and D from normal to fault, as Figure 7 shows.  In the
   direction that goes away from the failure point, Node D will send the
   state report message to Node E, informing Node E of the fault between
   C and D, and E will update the link state of its ring topology,
   changing the link state between C and D from normal to fault.  And
   the like, the state report message is sent from node to node in the
   clockwise direction.Similar to Node D, Node C will spread the failure
   information in anti-clockwise direction.

   Until Node A updates the link state of its ring topology, and knows
   there is a fault within its working path.  And at the same time it
   can get the conclusion that the anticlockwise path from A to D is
   working all right. so that Node A will switch the LSP1 operation to
   the anticlockwise tunnel.

   LSP1 will follow the path A->F->E->D, the label operation is
   [LSP1](original data traffic carried by LSP 1 )->[RaP_D(F)|
   LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)->[RaP_D(D)|LSP1](NodeE)->[LSP1]
   ( data traffic carried by LSP 1).

   The same goes with LSP2 operation, when Node B updates the link state
   of its ring topology, and find out the working path fault, so it will
   stop sending the LSP2 operation in clockwise direction and switch the
   LSP2 to the anticlockwise protection tunnel.  LSP2 goes through the
   path B->A->F->E->D, the label operation is [LSP2](original data
   traffic carried by LSP 2 )-> [RaP_D(A)|LSP2](NodeB)->[RaP_D(F)|
   LSP2](NodeA)->[RaP_D(E)|LSP2](NodeF)->[RaP_D(D)|LSP2](NodeE)->[LSP2]
   ( data traffic carried by LSP 2).

   Imagine the ring between A and B breaks down, as figure 8 shows.
   Like above, Node B will find out that there is a fault in the link
   between A and B, and it will update the link state of its ring
   topology, changing the link state between A and B from normal to
   fault.  The state report message is sent from node to node in the
   clockwise direction, informing every node that there is a fault
   between node A and B, so that every node updates the link state of
   its ring topology.  Node A will find out the working path fault of
   LSP1 and switch LSP1 to protection Ring tunnel, while Node B finds
   out the LSP2 working path is all right and there is no need for
   switching.










Cheng, et al.            Expires April 18, 2013                [Page 13]


Internet-Draft                    MSRP                      October 2012


                                                      +-- LSP l
 +-+-+-+-+-+-+-+      +---+ ###[RaP_D(F)]####  +---+  +-+-+-+-+-+-+-+
 |F|A|B|C|D|E|F|      | F | -----------------  | A |  |A|B|C|D|E|F|A|
 +-+-+-+-+-+-+-+      +---+ ***[RcW_D(A)]****  +---+  +-+-+-+-+-+-+-+
  |I|S|I|I|I|I|       #/*                       x      |S|I|I|I|I|I|
  +-+-+-+-+-+-+      #/*                         x     +-+-+-+-+-+-+
        [RaP_D(E)]  #/*[RcW_D(F)]       [RcW_D(B)]x [RaP_D(A)]
                   #/*                             x    +-- LSP 2
 +-+-+-+-+-+-+-+  +---+                             +---++-+-+-+-+-+-+-+
 |E|F|A|B|C|D|E|  | E |                             | B ||B|C|D|E|F|A|B|
 +-+-+-+-+-+-+-+  +---+                             +---++-+-+-+-+-+-+-+
  |I|I|S|I|I|I|     #\*                            */#    |I|I|I|I|I|S|
  +-+-+-+-+-+-+      #\*[RcW_D(E)]    [RcW_D(C)]  */#     +-+-+-+-+-+-+
          [RaP_D(D)]  #\*                        */# [RaP_D(B)]
 +-+-+-+-+-+-+-+       #\*                      */#     +-+-+-+-+-+-+-+
 |D|E|F|A|B|C|D|       +---+ ***[RcW_D(D)]*** +---+     |C|D|E|F|A|B|C|
 +-+-+-+-+-+-+-+  +--  | D | ---------------- | C |     +-+-+-+-+-+-+-+
  |I|I|I|S|I|I|   LSP1 +---+ ###[RaP_D(C)]### +---+      |I|I|I|I|S|I|
  +-+-+-+-+-+-+   LSP2                                   +-+-+-+-+-+-+

              ----- physical links  ***** RcW_D  ##### RaP_D




      Figure 8 the P2P steering operation and protection switching(2)


3.  Coordination protocol

   TBD


4.  Conclusions and Recommendations

   TBD


5.  IANA Considerations

   None


6.  Security Considerations

   TBD





Cheng, et al.            Expires April 18, 2013                [Page 14]


Internet-Draft                    MSRP                      October 2012


7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
              and S. Ueno, "Requirements of an MPLS Transport Profile",
              RFC 5654, September 2009.

   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
              Maintenance Framework for MPLS-Based Transport Networks",
              RFC 6371, September 2011.


Authors' Addresses

   Weiqiang Cheng
   China Mobile
   No.32 Xuanwumen West Street
   Beijing  100053
   China

   Email: chengweiqiang@chinamobile.com


   Lei Wang
   China Mobile
   No.32 Xuanwumen West Street
   Beijing  100053
   China

   Email: Wangleiyj@chinamobile.com


   Han Li
   China Mobile
   No.32 Xuanwumen West Street
   Beijing  100053
   China

   Email: Lihan@chinamobile.com







Cheng, et al.            Expires April 18, 2013                [Page 15]


Internet-Draft                    MSRP                      October 2012


   Kai Liu
   Huawei Technologies Co., Ltd.
   Huawei base, Bantian, Longgang District
   Shenzhen 518129
   China

   Email: alex.liukai@huawei.com


   Jia He
   Huawei Technologies Co., Ltd.
   Huawei base, Bantian, Longgang District
   Shenzhen 518129
   China

   Email: hejia@huawei.com


   Fang Li
   Research Institute of Telecommunication Transmission,China Academy of Telecommunication Research, MIIT. China
   Number 52, Huayuan street, Haidian District
   Shenzhen 100191
   China

   Email: lifang@ritt.cn


   Jian Yang
   ZTE Corporation P.R.China
   ZTE Industrial Zone,Liuxian Road, Xili District, Shenzhen
   Shenzhen 518055
   China

   Email: yang.jian90@zte.com.cn


   Junfang Wang
   Fiberhome Telecommunication Technologies Co.,LTD
   No.5, Dongxin Lu, Guandong Industrial Park, Wuhan, Hubei
   Wuhan 430073
   China

   Email: wjf@fiberhome.com.cn








Cheng, et al.            Expires April 18, 2013                [Page 16]


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