[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [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: Standards Track                                  H.  Li
Expires: January 26, 2015                                   China Mobile
                                                         H. van Helvoort
                                                                 K.  Liu
                                                                  J.  He
                                           Huawei Technologies Co., Ltd.
                                                                 F.   Li
               China Academy of Telecommunication Research, MIIT., China
                                                                 J. Yang
                                               ZTE Corporation P.R.China
                                                               JF.  Wang
                      Fiberhome Telecommunication Technologies Co., LTD.
                                                           July 25, 2014


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

Abstract

   This document describes requirements and solutions for MPLS-TP Shared
   Ring Protection (MSRP) in the ring topology for point-to-point (P2P)
   services.  The mechanism of MSRP is illustrated and analyzed how it
   satisfies the requirements in RFC6564 [RFC5654] for optimized ring
   protection.

Requirements Language

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

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



 Cheng, et al.           Expires January 26, 2015               [Page 1]


Internet-Draft                    MSRP                         July 2014


   This Internet-Draft will expire on January 3, 2015.

Copyright Notice

   Copyright (c) 2014 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
     1.1.  Requirements for MPLS-TP ring protection  . . . . . . . .   4
       1.1.1.  Recovery for Multiple failures  . . . . . . . . . . .   4
       1.1.2.  Smooth Upgrade from linear protection to ring
               protection  . . . . . . . . . . . . . . . . . . . . .   4
       1.1.3.  Configuration complexity  . . . . . . . . . . . . . .   4
     1.2.  Terminology and Notation  . . . . . . . . . . . . . . . .   5
     1.3.  Contributing Authors  . . . . . . . . . . . . . . . . . .   5
   2.  Shared-ring protection for P2P  . . . . . . . . . . . . . . .   5
     2.1.  Basic concept . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  The establishment of the Ring tunnels . . . . . . . .   6
       2.1.2.  The distribution and management of ring labels  . . .   8
       2.1.3.  Failure detection . . . . . . . . . . . . . . . . . .   9
     2.2.   P2P wrapping . . . . . . . . . . . . . . . . . . . . . .   9
       2.2.1.  Wrapping for Link Failure . . . . . . . . . . . . . .  10
       2.2.2.  Wrapping for node Failure . . . . . . . . . . . . . .  10
     2.3.  P2P short wrapping  . . . . . . . . . . . . . . . . . . .  11
     2.4.  P2P steering  . . . . . . . . . . . . . . . . . . . . . .  12
     2.5.  P2P wrapping for Interconnected Rings . . . . . . . . . .  15
       2.5.1.  Interconnected ring topology  . . . . . . . . . . . .  15
       2.5.2.  Interconnected ring protection scheme . . . . . . . .  16
   3.  Coordination protocol . . . . . . . . . . . . . . . . . . . .  21
     3.1.  RPS protocol  . . . . . . . . . . . . . . . . . . . . . .  21
       3.1.1.  Transmission and acceptance of RPS requests . . . . .  23
       3.1.2.  RPS PDU structure . . . . . . . . . . . . . . . . . .  23
       3.1.3.  Ring node RPS states  . . . . . . . . . . . . . . . .  24
       3.1.4.  RPS state transitions . . . . . . . . . . . . . . . .  26
     3.2.  RPS state machine . . . . . . . . . . . . . . . . . . . .  28
       3.2.1.  Initial states  . . . . . . . . . . . . . . . . . . .  28



 Cheng, et al.           Expires January 26, 2015               [Page 2]


Internet-Draft                    MSRP                         July 2014


       3.2.2.  State transitions when local request is applied . . .  29
       3.2.3.  State transitions when remote request is applied  . .  33
       3.2.4.   State Transitions when request addresses to another
               node is         received  . . . . . . . . . . . . . .  35
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  39
   6.  Normative Refereces . . . . . . . . . . . . . . . . . . . . .  39
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39

1.  Introduction

   As described in 2.5.6.1. ring protection of MPLS-TP requirements
   RFC5654 [RFC5654], several service providers have expressed much
   interest in operating MPLS-TP in ring topologies and required a high-
   level survivability function in these topologies.  In operation
   network deployment, MPLS-TP networks are often constructed with ring
   topologies.  It calls for an efficient and optimized ring protection
   mechanism to achieve simplified operation and fast recovery
   performance.

   The requirements for MPLS-TPRFC5654 [RFC5654] state that recovery
   mechanisms which are optimized for ring topologies could be further
   developed if it can provide the following features:

   a.  Minimize the number of OAM entities for protection

   b.  Minimize the number of elements of recovery

   c.  Minimize the required label number

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

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

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

   This document focus on the solutions for point-to-point transport
   path.  The solution for point-to-multipoint transport is under study
   and will be presented in a separate document.  The basic concept
   stated in this document also apply to point-multipoint transport
   path.







 Cheng, et al.           Expires January 26, 2015               [Page 3]


Internet-Draft                    MSRP                         July 2014


1.1.  Requirements for MPLS-TP ring protection

   The requirements for MPLS-TP ring protection are specified in RFC5654
   [RFC5654].  This document elaborates the requirements in detail.

1.1.1.  Recovery for Multiple failures

   MPLS-TP is expected to be used in carrier grade metro networks and
   backbone networks to provide mobile backhaul, carry business
   customers' services and etc., in which the network survivability is
   very important.  According to R106 B in RFC5654 [RFC5654], MPLS-TP
   recovery mechanisms in a ring SHOULD protect against multiple
   failures.  The following context provides some more detailed
   illustration about "multiple failures".  In metro and backbone
   networks, the single risk factor often affects multiple links or
   nodes.  Some examples of risk factors are given as follows:

   - multiple links using fibers in one cable or pipeline

   - Several nodes shared one power supply system

   - weather sensitive micro-wave system

   Once one of the above risk factors happens, multiple links or nodes
   failures may occur simultaneously and those failed links or nodes may
   locate on a single ring as well as on interconnected rings.  Ring
   protection against multiple failures should cover both multiple
   failures on a single ring and multiple failures on interconnected
   rings.

1.1.2.  Smooth Upgrade from linear protection to ring protection

   It is beneficial for service providers to upgrade protection scheme
   from linear protection to ring protection in their MPLS-TP network
   without service interruption.  In-service insertion and removal of a
   node on the ring should also be supported.  Therefore, the MPLS-TP
   ring protection mechanism is supposed be developed and optimized to
   comply with this smooth upgrading principle.

1.1.3.  Configuration complexity

   While deploying linear protection in MPLS-TP networks, the
   configuration effort of protection depends on the quantity of the
   services carried.  In some large metro networks with more than ten
   thousand services access, 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 configuration and operation.  While ring protection can



 Cheng, et al.           Expires January 26, 2015               [Page 4]


Internet-Draft                    MSRP                         July 2014


   reduce the dependency of configuration on the quantity of services,
   it will simplify the network protection configuration and operation
   effort.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 effort.

1.2.  Terminology and Notation

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

   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
   layers.  However, we only present the layers that are related 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,Minxue Wang,Sheng Liu (China Mobile)

2.  Shared-ring protection for P2P

2.1.  Basic concept

   This document introduces a novel logic layer of the ring for both
   working path and protection path for shared ring protection in MPLS-
   TP networks.  As shown in Figure 1, the new logic layer is a ring
   tunnel on top of the working path or the protection path, namely
   working ring tunnel and protection ring tunnel respectively.  Once a
   ring tunnel is established, the configuration, management and
   protection of the ring are all based on the ring tunnel.  One port
   can carry multiple ring tunnels, while one ring tunnel can carry
   multiple LSPs.




 Cheng, et al.           Expires January 26, 2015               [Page 5]


Internet-Draft                    MSRP                         July 2014


                                                |-------------
                                  |-------------|
                    |-------------|             |
      =====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 is
   shown as below.

                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                   |            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

   LSPs which have same exit node share the same ring tunnel.  The exit
   node is the node where the traffic leaves the ring.  In other words,
   all the LSPs that traverse the ring and exit from the same node share
   the same working ring tunnel and protection ring tunnel.  For each
   exit node, four ring tunnels are established:

   - one clockwise working ring tunnel, which is protected by the
   following protection tunnel,

   - one anticlockwise protection ring tunnel,

   - one anticlockwise working ring tunnel, which is protected by the
   following protection tunnel,

   - one clockwise protection ring tunnel.





 Cheng, et al.           Expires January 26, 2015               [Page 6]


Internet-Draft                    MSRP                         July 2014


   An example is shown in Figure 3 where Node D is the exit node.  LSP
   1, LSP 2 and LSP 3 enter the ring from Node E, Node A and Node B,
   respectively, and all leave the ring from Node D.  To protect these
   LSPs that traverse the ring, a clockwise working ring tunnel (RcW_D)
   via E->F->A->B->C->D, and its protection ring tunnel in the reverse
   direction (RaP_D) via D->C->B->A->F->E->D are established,
   respectively; Also, an anti-clockwise working ring tunnel (RaW_D) via
   C->B->A->F->E->D, and its clockwise protection ring tunnel (RcP_D)
   via D->E->F->A->B->C->D are established, respectively.  Figure 3 only
   shows RcW_D and RaP_D.  A similar provisioning should be applied for
   any other node on the ring.  For other nodes in Figure 3 when acting
   as an exit node, the ring tunnels are created 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;

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

   For exit Node D, two working ring tunnels, RcW_D and RaW_D, are
   terminated on Node D, and two protection ring tunnels, RcP_D and
   RaP_D, are started from Node D.  That means through these 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.






















 Cheng, et al.           Expires January 26, 2015               [Page 7]


Internet-Draft                    MSRP                         July 2014


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

                  ---- physical links
                   **** RcW_D
                   #### RaP_D
                  Figure 3 Ring tunnels in MSRP

2.1.2.  The distribution and management of ring labels

   Ring tunnel labels are distributed by means of downstream-assigned
   mechanism as defined in RFC5654 [RFC3031].  When a MPLS-TP transport
   path, such as LSP, enters the ring, the ingress node pushes the
   working ring tunnel label and sends the traffic to the next hop
   according to the ring ID and the exit node.  The transit nodes within
   the working ring tunnel swap ring tunnel labels and forward the
   packets to the next hop; When arriving at the egress node, the egress
   node removes the ring tunnel label and forwards the packets based on
   the inner LSP label and PW label.  Figure 4 shows the label operation
   in the MPLS- TP shared ring protection mechanism.  Assume that LSP 1
   enters the ring at Node A and exits from Node D, and the following
   label operations are executed.

   1.  The traffic LSP1 arrives at Node A with a label stack [LSP1] and
   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 Node C forward the
   packets by swapping the working ring tunnel labels.  For example, the
   label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node B.





 Cheng, et al.           Expires January 26, 2015               [Page 8]


Internet-Draft                    MSRP                         July 2014


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

   4.  All the LSPs which exit from the same node share the same set of
   ring tunnel labels.

                     +---+#####[RaP_D(F)]######+---+
                     | F |---------------------| A | +-- LSP1
                     +---+*****[RcW_D(A)]******+---+
                      #/*                        *\#
           [RaP_D(E)]#/*[RcW_D(F)]      [RcW_D(B)]*\#[RaP_D(A)]
                    #/*                            *\#
                  +---+                          +---+
                  | E |                          | B |
                  +---+                          +---+
                    #\                            */#
           [RaP_D(D)]#\                [RxW_D(C)]*/#[RaP_D(B)]
                      #\                        */#
                      +---+*****[RcW_D(D)]****+---+
            LSP1  +-- | D |-------------------| C |
                      +---+#####[RaP_D(C)]####+---+
           -----physical links      ****** RcW_D    ###### RaP_D
                     Figure 4 Label operation of MSRP

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 [RFC6371].  Protection switching is triggered by
   the failure detection in a link in the ring monitored by OAM
   functions.

   Two end ports of a link form an MEG, and an MEG end point (MEP)
   function is installed in each ring port.  CC-V OAM packets are
   periodically exchanged between each pair of MEPs to monitor the link
   health.  Consecutive losses of CC-V packets (3 packets) will be
   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 in the links that are 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



 Cheng, et al.           Expires January 26, 2015               [Page 9]


Internet-Draft                    MSRP                         July 2014


   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 based on LSP1 at nodeD.

2.2.1.  Wrapping for Link Failure

   When a link failure between Node B and Node C occurs, 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 path A->B->A->F->E->D->C->D.  The label operation is
   [LSP1](Original data traffic)-> [RcW_D(B)|LSP1](Node A)->
   [RaP_D(A)|LSP1](Node B)->[RaP_D(F)|LSP1](Node A)->[RaP_D(E)|LSP1]
   (Node F)->[RaP_D(D)|LSP1] (Node E)-> [RaP_D(C)|LSP1] (Node D)->
   [RcW_D(D)|LSP1](Node C)->[LSP1](Data traffic exits the ring).

                      +---+#####[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
              ****** RcW_D           ###### RaP_D
             Figure 5 P2P wrapping for link failure in a single ring

2.2.2.  Wrapping for 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)->



 Cheng, et al.           Expires January 26, 2015              [Page 10]


Internet-Draft                    MSRP                         July 2014


   [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 P2P wrapping for node failure in a single ring

2.3.  P2P short wrapping

   For traditional wrapping protection scheme, Protection switching
   execute at both nodes neighbored failure respectively , so the
   traffic will be wrapped twice.  This mechanism will cause more
   latency and bandwidth consume when traffic switched to protection
   path.

   For Short wrapping protection, switching only execute at up-stream
   node neighbored failure node, and exited ring in protection ring
   tunnel.  This scheme can optimized latency and bandwidth consume when
   traffic switched to protection path.

   In traditional wrapping solution, protection ring tunnel is a closed
   path in normal state, while in short wrapping solution, protection
   ring tunnel will remove at exit node.  Short wrapping is easy to
   implement in shared ring protection because the working and
   protection ring tunnel is established base on exit nodes.

   As show in figure 7, the data traffic which enters the ring at Node A
   and exits at Node D follows the path A->B->C->D in normal state.
   When a link failure between Node B and Node C occurs, NodeB switched
   work ring tunnel RcW_D to opposite protection ring tunnel RaP_D same
   as traditionally wrapping.  The different occurs in protection ring
   tunnel at exit node.  In short wrapping protection, Rap_D will remove
   in Node D and deal with inner LSP label.  So LSP1 will follows the



 Cheng, et al.           Expires January 26, 2015              [Page 11]


Internet-Draft                    MSRP                         July 2014


   path A->B->A->F->E->D when link failure between Node B and Node C
   when using short wrapping.

                      +---+#####[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 |
                      +---+                   +---+
              -----physical links    xxxx Failure Link
              ****** RcW_D           ###### RaP_D
             Figure 7 P2P short wrapping for link failure

2.4.  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 in the ring, the nodes which detect the failure will spread
   the failure information in the opposite direction node by node in the
   ring respectively.  When the node receives the message that informs
   the 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.
















 Cheng, et al.           Expires January 26, 2015              [Page 12]


Internet-Draft                    MSRP                         July 2014


                                                    +--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 8 P2P steering operation and protection switching (1)

   Steering Example is shown in Figure 8.  LSP1 enters the ring from
   Node A while LSP2 enters the ring from Node B, and both of them have
   the same destination node D.  As Figure 8 shows, in the 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 8 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
   update the link state of its ring topology, changing the link state
   between C and D from normal to fault, as Figure 8 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.  In
   this manner, the state report message is sent node by node in the
   clockwise direction.  Similar to Node D, Node C will spread the
   failure information in the anti-clockwise direction.



 Cheng, et al.           Expires January 26, 2015              [Page 13]


Internet-Draft                    MSRP                         July 2014


   Until Node A updates the link state of its ring topology and be aware
   of there is a fault within its working path, it can reach the
   conclusion that the anticlockwise path from A to D is working all
   right, and thus Node A will switch the LSP1 operation to the
   anticlockwise ring 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 also apply to the operation of LSP2.  When Node B updates
   the link state of its ring topology, and finds out the working path
   fault, it will stop sending the LSP2 operation in the clockwise
   direction and switch the LSP2 to the anticlockwise protection tunnel.
   LSP2 goes through the path B->A->F->E->D, and the label operation is
   [LSP2](original data traffic carried by LSP 2 )-> [RaP_D(A)|LSP2](Nod
   eB)->[RaP_D(F)|LSP2](NodeA)->[RaP_D(E)|LSP2](NodeF)->[RaP_D(D)|LSP2](
   NodeE)->[LSP2]( data traffic carried by LSP 2).

   Assume that the ring between A and B breaks down, as Figure 9 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 node by 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 a fault in the working path
   of LSP1, and switch LSP1 to the protection Ring tunnel, while Node B
   will find out the LSP2 working path is all right and there is no need
   for switching.




















 Cheng, et al.           Expires January 26, 2015              [Page 14]


Internet-Draft                    MSRP                         July 2014


                                                      +-- 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 9 the P2P steering operation and protection switching (2)

2.5.  P2P wrapping for Interconnected Rings

2.5.1.  Interconnected ring topology

   Interconnected ring topology is often used in MPLS-TP networks.
   There are two typical interconnected ring topologies that will be
   addressed in this document.

   1) Single-node interconnected rings

   In single-node interconnected rings, the connection between two rings
   is through a single node.  As the interconnection node may cause a
   single point of failure, this topology should be avoided in real
   networks;

   2) Dual-node interconnected rings

   In dual-node interconnected rings, the connection between two rings
   is through two nodes.  The two interconnection nodes belong to both
   interconnected rings.  This topology can recover from one
   interconnection node failure.







 Cheng, et al.           Expires January 26, 2015              [Page 15]


Internet-Draft                    MSRP                         July 2014


2.5.1.1.  Single-node interconnected rings

   Figure 10 shows the topology of single-node interconnected rings.
   Node C is interconnection node between Ring1 and Ring2.

               +---+          +---+                         +---+          +---+
                   | A |----------| B |------             ------| G |----------| H |
                   +---+          +---+      \           /      +---+          +---+
                   |                        \         /                        |
                   |                         \ +---+ /                         |
                   |            Ring1          | C |          Ring2            |
                   |                         / +---+ \                         |
                   |                         /         \                        |
                   +---+          +---+      /           \      +---+          +---+
                   | F |----------| E |------             ------| J |----------| I |
                   +---+          +---+                         +---+          +---+


                Figure 10 Single-node interconnected rings

2.5.1.2.  Dual-node interconnected rings

   Figure 11 shows the topology of dual-node interconnected rings.  Node
   C and Node D are interconnection nodes between Ring1 and Ring2.

                   +---+          +---+          +---+          +---+          +---+
                   | A |----------| B |----------| C |----------| G |----------| H |
                   +---+          +---+          +---+          +---+          +---+
                       |                            | |                            |
                       |                            | |                            |
                       |            Ring1           | |           Ring2            |
                       |                            | |                            |
                       |                            | |                            |
                   +---+          +---+          +---+          +---+          +---+
                   | F |----------| E |----------| D |----------| J |----------| I |
                   +---+          +---+          +---+          +---+          +---+

                                Figure 11 Dual-node interconnected rings

2.5.2.  Interconnected ring protection scheme

2.5.2.1.  Introduction

   - Interconnected rings can be regarded as two independent rings.
   Each ring runs protection switching independently.  Failure in one
   ring only triggers protection switching in itself and does not affect
   the other ring.  Protection switch in a single ring is same as which
   described in section 3 Shared ring protection for P2P.



 Cheng, et al.           Expires January 26, 2015              [Page 16]


Internet-Draft                    MSRP                         July 2014


   - The service LSPs that traverse the interconnected rings via the
   interconnection nodes must use different ring tunnels in different
   rings.  The ring tunnel used in the source ring will be removed, and
   the ring tunnel of destination ring will be added in interconnection
   nodes.

   - For protected interconnection node in dual-node interconnected
   ring, the service LSPs in the interconnection nodes should use the
   same MPLS label.  So any interconnection node can terminate source
   ring runnel and push destination ring tunnel according to service LSP
   label.

   - Two interconnection nodes can be managed as a virtual
   interconnection node group.  Each ring should assign ring tunnels to
   the virtual interconnection node group.  The interconnection nodes in
   the group should terminate the working ring tunnel in each ring.
   Protection ring tunnel is a open ring to switch with the working ring
   tunnel at the nodes which detect the fault and end at the egress
   node.

   - When the service traffic passes through the interconnection node,
   the direction of the working ring tunnels in each ring for this
   service traffic should be the same.  For example, if the working ring
   tunnel follows the clockwise direction in Ring1, the working ring
   tunnel for the same service traffic in Ring2 also follows the
   clockwise direction when the service leaves Ring1 and enters Ring2.

2.5.2.2.  Ring tunnels of interconnected rings

   The same ring tunnels as described in 2.1.1 are used in each ring of
   the interconnected rings.  Besides, ring tunnels to the virtual
   interconnection node group will be established by each ring of the
   interconnected rings, i.e.:

   - one clockwise working ring tunnel to the virtual interconnection
   node group;

   - one anticlockwise protection ring tunnel to the virtual
   interconnection node group,

   - one anticlockwise working ring tunnel to the virtual
   interconnection node group;

   - one clockwise protection ring tunnel to the virtual interconnection
   node group.

   These ring tunnel will terminated at all nodes in virtual
   interconnection node group.



 Cheng, et al.           Expires January 26, 2015              [Page 17]


Internet-Draft                    MSRP                         July 2014


   All the ring tunnels established in Ring1 in Figure 12 is provided as
   follows:

   To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A;

   To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B;

   To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C;

   To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D;

   To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E;

   To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F;

   To the virtual interconnection node group (including Node F and Node
   A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A;

   All the ring tunnels established in Ring2 in Figure 12 is provided as
   follows:

   To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A;

   To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F;

   To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G;

   To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H;

   To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I;

   To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J;

   To the virtual interconnection node group(including Node F and Node
   A): R2cW_FandA, R2aW_FandA, R2cP_FandA, R2aP_FandA;

2.5.2.3.  Interconnected ring switch mechanism














 Cheng, et al.           Expires January 26, 2015              [Page 18]


Internet-Draft                    MSRP                         July 2014


                       +---+cccccccccccc +---+
                       | H |-------------| I |--->LSP1
                       +---+             +---+
                       c/a                   a\
                      c/a                     a\
                     c/a                       a\
                   +---+                     +---+
                   | G |        Ring2        | J |
                   +---+                     +---+
                     c\a                      a/c
                      c\a                    a/c
                       c\a  aaaaaaaaaaaaa   a/c
                       +---+ccccccccccccc+---+
                       | F |-------------| A |
                       +---+ccccccccccccc+---+
                       c/aaaaaaaaaaaaaaaaaaa a\
                      c/                      a\
                     c/                        a\
                   +---+                     +---+
                   | E |        Ring1        | B |
                   +---+                     +---+
                     c\a                      a/c
                      c\a                    a/c
                       c\a                  a/c
                       +---+aaaaaaaaaaaa +---+
               LSP1--->| D |-------------| C |
                       +---+ccccccccccccc+---+

                        ccccccccccc  R1cW_F&A
                        aaaaaaaaaaa  R1aP_F&A
                        ccccccccccc  R2cW_I
                        aaaaaaaaaaa  R2aP_I
         Figure 12 Ring tunnels for the interconnected rings

   As shown in Figure 12, for the service traffic LSP1 which enters
   Ring1 at Node D and leaves Ring1 at Node F and continues to enter
   Ring2 at Node F and leaves Ring2 at Node I, the protection scheme is
   described below.

   In normal state, LSP1 follows R1cW_F&A in Ring1 and R2CW_I in Ring2.
   The label used for the working ring tunnel R1cW_F&A in Ring1 is
   popped and the label used for the working ring tunnel R2cW_I will be
   pushed based the inner label lookup at the interconnection node F.
   The working path that the service traffic LSP1 follows is:
   LSP1->R1cW_F&A (D->E->F)->R2cW_I(F->G->H->I)->LSP1.

   In case of link failure, for example, when a failure occurs on the
   link between Node F and Node E, Node F and E will detect the failure



 Cheng, et al.           Expires January 26, 2015              [Page 19]


Internet-Draft                    MSRP                         July 2014


   and execute protection switching as described in 2.2.1.1.  The path
   that the service traffic LSP1 follows after switching change to
   LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A->F)->R1cW_F(F)
   ->R2cW_I(F->G->H->I)->LSP1.

   In case of non interconnection node failure, for example, when the
   failure occurs at Node E in Ring1, Node F and E will detect failure
   and execute protection switching as described in 2.2.1.2.  The path
   that the service traffic LSP1 follows after switching becomes:
   LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A->F)->
   R1cW_F(F)->R2cW_I(F->G->H->I).

   In case of interconnection node failure, for example, when failure
   occurs at the interconnection Node F.  Node E and A in Ring1 will
   detect the failure, and execute protection switching as described in
   2.2.1.2.  Node G and A in Ring2 will also detects the failure, and
   execute protection switching.  The path that the service traffic LSP1
   follows after switching is:
   LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R1cW_A(A)
   ->R2aP_I(A->J->I)->LSP1.

2.5.2.4.  Interconnected ring topology detection mechanism

   As show in Figure 13, the service traffic LSP1 traverses A->B-C in
   Ring1 and C->G->H->I in Ring2.  Node C and Node D is the
   interconnection node.  When both the link between Node C and Node G
   and the link between Node C and Node D fail, ring tunnel from Node C
   to Node I in Ring 2 becomes unreachable.  However, Node D is still
   available, by which LSP1 can still reach Node I.

   In order to do so, the interconnection nodes need to know the ring
   topology in each ring independently so that they can judge whether a
   node is reachable.  The judgment is based on the knowledge of ring
   topology and the fault location as described in section 3.4.  The
   ring topology can be obtained by NMS or topology discovery
   mechanisms.  The fault location can be obtained by spreading the
   fault information around the ring.  The nodes which detect the
   failure will spread the fault information in the opposite direction
   node by node in the ring respectively.  When the interconnection node
   receives the message that informs the failure, it will quickly figure
   out the location of the fault by the topology information that is
   maintained by itself and determine whether the LSPs enter the ring
   from itself can reach the destination.  If the destination node is
   reachable, the LSP will exit the source ring and enter the
   destination ring.  If the destination node is not reachable, the LSP
   will switch to the anticlockwise protection ring tunnel.





 Cheng, et al.           Expires January 26, 2015              [Page 20]


Internet-Draft                    MSRP                         July 2014


   In Figure 13 Node C judges the ring tunnel to Node I is unreachable,
   the service traffic LSP1 of which the destination node on the ring
   tunnel is Node I should switch to the protection LSP (R1aP_C&D) so
   that the service traffic LSP1 traverses the interconnected rings at
   Node D.  Node D will remove the ring tunnel label of Ring1 and add
   ring tunnel label of Ring2.

                    +---+ *********+---+**********+---+          +---+**********+---+
             LSP1-> | A |----------| B |----------| C |XXXXXXXXXX| G |----------| H |
                    +---+##########+---+##########+---+          +---+##########+---+
                      |#                            X                            #|*
                      |#                            X                            #|*
                      |#           Ring1            X           Ring2            #|*
                      |#                            X                            #|*
                      |#                             X                            #|*
                    +---+##########+---+##########+---+######### +---+##########+---+
                    | F |----------| E |----------| D |----------| J |----------| I | ->LSP1
                    +---+          +---+          +---+          +---+          +---+

                             ***********  R1cW_C&D
                             ###########  R1aP_C&D
                             ***********  R2cW_I
                             ###########  R2aP_I
                       Figure 13 interconnected ring

3.  Coordination protocol

3.1.  RPS protocol

   The MSRP protection operation MUST be controlled with the help of the
   Ring Protection Switch Protocol(RPS).  The RPS processes in the each
   of the individual nodes that form the ring SHOULD communicate using
   G-ACh channel.

   The RPS protocol MUST carry the ring status information and RPS
   requests, both automatic and externally initiated commands, between
   the ring nodes.

   Each node on the ring MUST be uniquely identified by assigning it a
   node ID.The maximum number of nodes on the ring supported by the RPS
   protocol is 127.  The node ID SHOULD be independent of the order in
   which the nodes appear on the ring.  The node ID is used to identity
   the source and destination nodes of each RPS request.

   Each node SHOULD have a ring map containing information about the
   sequence of the nodes around the ring.  The method of configuring the
   nodes with the ring maps is TBD.




 Cheng, et al.           Expires January 26, 2015              [Page 21]


Internet-Draft                    MSRP                         July 2014


   When no protection switches are active on the ring, each node MUST
   dispatch periodically RPS requests to the two adjacent nodes,
   indicating No Request (NR).  When a node determines that a protection
   switching is required, it MUST send the appropriate RPS request in
   both directions.

                    +---+ A->B(NR)    +---+ B->C(NR)    +---+ C->D(NR)
             -------| A |-------------| B |-------------| C |-------
           (NR)F<-A +---+    (NR)A<-B +---+    (NR)B<-C +---+


       Figure 14: RPS communication between the ring nodes in case of no
                             failures in the ring

   A destination node is a node that is adjacent to a node that
   identified a failed span.  When a node that is not the destination
   node receives an RPS request and it has no higher priority local
   request, it MUST transfer the RPS request as received.  In this way,
   the switching nodes can maintain direct RPS protocol communication in
   the ring.

                     +---+ C->B(SF)    +---+ B->C(SF)    +---+ C->B(SF)
              -------| A |-------------| B |----- X -----| C |-------
            (SF)C<-B +---+    (SF)C<-B +---+    (SF)B<-C +---+


         Figure 15: RPS communication between the ring nodes in case of
                          failure between nodes B and C

   Note that in the case of a bidirectional failure such as a cable cut,
   two nodes detect the failure and send each other an RPS request in
   opposite directions.

   o In rings utilizing the wrapping protection, when the destination
   node receives the RPS request it MUST perform the switch from/to the
   working ring tunnels to/from the protection ring tunnels if it has no
   higher priority active RPS request.

   o In rings utilizing the steering protection, when a ring switch is
   required, any node MUST perform the switches if its added/dropped
   traffic is affected by the failure.  Determination of the affected
   traffic SHOULD be performed by examining the RPS requests (indicating
   the nodes adjacent to the failure or failures) and the stored ring
   maps (indicating the relative position of the failure and the added
   traffic destined towards that failure).

   When the failure has cleared and the Wait-to-Restore (WTR) timer has
   expired, the nodes sourcing RPS requests MUST drop their respective



 Cheng, et al.           Expires January 26, 2015              [Page 22]


Internet-Draft                    MSRP                         July 2014


   switches (tail end) and MUST source an RPS request carrying NR code.
   The node receiving from both directions such RPS request (head end)
   MUST drop its protection switches.

   A protection switch MUST be initiated by one of the criteria
   specified in Section 3.2.  A failure of the RPS protocol or
   controller MUST NOT trigger a protection switch.

   Ring switches MUST be preempted by higher priority RPS requests.  For
   example, consider a protection switch that is active due to a manual
   switch request on the given span, and another protection switch is
   required due to a failure on another span.  Then a RPS request MUST
   be generated, the former protection switch MUST be dropped, and the
   latter protection switch established.

   MSPP mechanism SHOULD support multiple protection switches in the
   ring, resulting the ring being segmented into two or more separate
   segments.  This may happen when several RPS requests of the same
   priority exist in the ring due to multiple failures or external
   switch commands.

   Proper operation of the MSRP mechanism relies on all nodes having
   knowledge of the state of the ring (nodes and spans) so that nodes do
   not preempt existing RPS request unless they have a higher-priority
   RPS request.  In order to accommodate ring state knowledge, during
   protection switch the RPS requests MUST be sent in both directions.

3.1.1.  Transmission and acceptance of RPS requests

   A new RPS request MUST be transmitted immediately when a change in
   the transmitted status occurs.

   The first three RPS protocol messages carrying new RPS request SHOULD
   be transmitted as fast as possible.  For fast protection switching
   within 50 ms, the interval of the first three RPS protocol messages
   SHOULD be 3.3 ms.  Then RPS requests SHOULD be transmitted with the
   interval of 5 seconds.

3.1.2.  RPS PDU structure

   Figure 16 depicts the format of an RPS packet that is sent on the
   G-ACh.  The Channel Type field is set to indicate that the message is
   an RPS message.  The ACH MUST NOT include the ACH TLV Header RFC5586
   [RFC5586]meaning that no ACH TLVs can be included in the message.







 Cheng, et al.           Expires January 26, 2015              [Page 23]


Internet-Draft                    MSRP                         July 2014


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0|    RPS Channel Type (TBD)     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Dest Node ID  | Src Node ID   |   Request     |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 16: G-ACh RPS Packet

   The following fields MUST be provided:

   o Destination Node ID: The destination node ID MUST always be set to
   value of a node ID of the adjacent node.  Valid destination node ID
   values are 1-127.

   o Source node ID: The source node ID MUST always be set to the value
   of the node ID generating the RPS request.  Valid source node ID
   values are 1-127.

   o RPS request code: A code consisting of four bits as specified
   below.

            +-------------+-----------------------------+----------+
             |  Bits  4-1  |   Condition, State          | Priority |
             | (MSB - LSB) |  or external Request        |          |
             +-------------------------------------------+----------+
             |   1 1 1 1   |  Lockout of Protection (LP) |  highest |
             |   1 1 0 1   |  Forced Switch (FS)         |          |
             |   1 0 1 1   |  Signal Fail (SF)           |          |
             |   0 1 1 0   |  Manual Switch (MS)         |          |
             |   0 1 0 1   |  Wait-To-Restore (WTR)      |          |
             |   0 0 1 1   |  Exerciser (EXER)           |          |
             |   0 0 0 1   |  Reverse Request (RR)       |          |
             |   0 0 0 0   |  No Request (NR)            |  lowest  |
             +-------------+-----------------------------+----------+

3.1.3.  Ring node RPS states

   Idle state: A node is in the idle state when it has no RPS request
   and is sourcing and receiving NR code to/from both directions.

   Switching state: A node not in the idle or pass-through states is in
   the switching state.

   Pass-through state: A node is in the pass-through state when its
   highest priority RPS request is a request not destined to or sourced
   by it.  The pass-through is bidirectional.



 Cheng, et al.           Expires January 26, 2015              [Page 24]


Internet-Draft                    MSRP                         July 2014


3.1.3.1.  Idle state

   A node in the idle state MUST source the NR request in both
   directions.

   A node in the idle state MUST terminate RPS requests flow in both
   directions.

   A node in the idle state MUST block the traffic flow on protection
   LSPs/tunnels in both directions.

3.1.3.2.  Switching state

   A node in the switching state MUST source RPS request to adjacent
   node with its highest RPS request code in both directions when it
   detects a failure or receives an external command.

   A node in the switching state MUST terminate RPS requests flow in
   both directions.

   As soon as it receives an RPS request from the short path, the node
   to which it is addressed MUST acknowledge the RPS request by replying
   with the RR code on the short path, and with the received RPS request
   code on the long path.

   This rule refers to the unidirectional failure detection: the RR
   SHOULD be issued only when the node does not detect the failure
   condition (i.e., the node is a head end), that is, it is not
   applicable when a failure is detected bidirectionally, because, in
   this latter case, both nodes send an RPS request for the failure on
   both paths (short and long).

   The following switches MUST be allowed to coexist:

   o LP with LP

   o FS with FS

   o SF with SF

   o FS with SF

   When multiple MS RPS requests over different spans exist at the same
   time, no switch SHOULD be executed and existing switches MUST be
   dropped.  The nodes MUST signal, anyway, the MS RPS request code.

   Multiple EXER request MUST be allowed to coexist in the ring.




 Cheng, et al.           Expires January 26, 2015              [Page 25]


Internet-Draft                    MSRP                         July 2014


   A node in a ring switching state that receives the external command
   LW for the affected span MUST drop its switch and MUST signal NR for
   the locked span if there is no other RPS request on another span.
   Node still SHOULD signal relevant RPS request for another span.

3.1.3.3.  Pass-through state

   When a node is in a pass-through state, it MUST transmit on one side,
   the same RPS request as it receives from the other side.

   When a node is in a pass-through state, it MUST allow the traffic
   flow on protection ring tunnels in both directions.

3.1.4.  RPS state transitions

   All state transitions are triggered by an incoming RPS request
   change, a WTR expiration, an externally initiated command, or locally
   detected MPLS-TP section failure conditions.

   RPS requests due to a locally detected failure, an externally
   initiated command, or received RPS request shall pre-empt existing
   RPS requests in the prioritized order given in Section 3.1.2, unless
   the requests are allowed to coexist.

3.1.4.1.  Transitions between the idle and pass-through states

   The transition from the idle state to pass-through state MUST be
   triggered by a valid RPS request change, in any direction, from the
   NR code to any other code, as long as the new request is not destined
   for the node itself.  Both directions move then into a pass-through
   state, so that, traffic entering the node through the protection Ring
   tunnels are by-passed across the node.

   A node MUST revert from pass-through state to the idle state when it
   detects NR codes incoming from both directions.  Both directions
   revert simultaneously from the pass-through state to the idle state.

3.1.4.2.  Transitions between the idle and switching states

   Transition of a node from the idle state to the switching state MUST
   be triggered by one of the following conditions:

   o a valid RPS request change from the NR code to any code received on
   either the long or the short path and destined to this node

   o an externally initiated command for this node





 Cheng, et al.           Expires January 26, 2015              [Page 26]


Internet-Draft                    MSRP                         July 2014


   o the detection of an MPLS-TP section layer failure at this node.
   Actions taken at a node in idle state upon transition to switching
   state are:

   o for all protection switch requests, except EXER and LP, the node
   MUST execute the switch

   o for EXER, and LP, the node MUST signal appropriate request but not
   execute the switch.

   A node MUST revert from the switching state to the idle state when it
   detects NR codes received from both directions.

   o At the tail end: When a WTR time expires or an externally initiated
   command is cleared at a node, the node MUST drop its switch, transit
   to Idle state and signal the NR code in both directions.

   o At the head end: Upon reception of the NR code, from both
   directions, the head-end node MUST drop its switch, transition to
   Idle state and signal the NR code in both directions.

3.1.4.3.  Transitions between switching states

   When a node that is currently executing any protection switch
   receives a higher priority RPS request (due to a locally detected
   failure, an externally initiated command, or a ring protection switch
   request destined to it) for the same span, it MUST upgrade the
   priority of the switch it is executing to the priority of the
   received RPS request.

   When a failure condition clears at a node, the node MUST enter WTR
   condition and remain in it for the appropriate time-out interval,
   unless:

   o a different RPS request of higher priority than WTR is received

   o another failure is detected

   o an externally initiated command becomes active.

   The node MUST send out a WTR code on both the long and short paths.

   When a node that is executing a switch in response to incoming SF RPS
   request (not due to a locally detected failure) receives a WTR code
   (unidirectional failure case), it MUST send out RR code on the short
   path and the WTR on the long path.





 Cheng, et al.           Expires January 26, 2015              [Page 27]


Internet-Draft                    MSRP                         July 2014


3.1.4.4.  Transitions between switching and pass-through states

   When a node that is currently executing a switch receives an RPS
   request for a non-adjacent span of higher priority than the switch it
   is executing, it MUST drop its switch immediately and enter the pass-
   through state.

   The transition of a node from pass-through to switching state MUST be
   triggered by:

   o an equal, higher priority, or allowed coexisting externally
   initiated command

   o the detection of an equal, higher priority, or allowed coexisting
   failure

   o the receipt of an equal, higher priority, or allowed coexisting RPS
   request destined to this node.

3.2.  RPS state machine

3.2.1.  Initial states





























 Cheng, et al.           Expires January 26, 2015              [Page 28]


Internet-Draft                    MSRP                         July 2014


         +-----------------------------------+----------------+
         |        State                      |  Signaled RPS  |
         +-----------------------------------+----------------+
         |  A  |  Idle                       |  NR            |
         |     |  Working: no switch         |                |
         |     |  Protection: no switch      |                |
         +-----+-----------------------------+----------------+
         |  B  |  Pass-trough                |  N/A           |
         |     |   Working: no switch        |                |
         |     |   Protection: pass through  |                |
         +-----+-----------------------------+----------------+
         |  C  |  Switching - LP             |  LP            |
         |     |  Working: no switch         |                |
         |     |  Protection: no switch      |                |
         +-----+-----------------------------+----------------+
         |  D  |  Idle - LW                  |  NR            |
         |     |  Working: no switch         |                |
         |     |  Protection: no switch      |                |
         +-----+-----------------------------+----------------+
         |  E  |  Switching - FS             |  FS            |
         |     |  Working: switched          |                |
         |     |  Protection: switched       |                |
         +-----+-----------------------------+----------------+
         |  F  |  Switching - SF             |  SF            |
         |     |  Working: switched          |                |
         |     |  Protection: switched       |                |
         +-----+-----------------------------+----------------+
         |  G  |  Switching - MS             |  MS            |
         |     |  Working: switched          |                |
         |     |  Protection: switched       |                |
         +-----+-----------------------------+----------------+
         |  H  |  Switching - WTR            |  WTR           |
         |     |  Working: switched          |                |
         |     |  Protection: switched       |                |
         +-----+-----------------------------+----------------+
         |  I  |  Switching - EXER           |  EXER          |
         |     |  Working: no switch         |                |
         |     |  Protection: no switch      |                |
         +-----+-----------------------------+----------------+

3.2.2.  State transitions when local request is applied

   In the state description below 'O' means that new local request will
   be rejected because of exiting request.

   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------



 Cheng, et al.           Expires January 26, 2015              [Page 29]


Internet-Draft                    MSRP                         July 2014


   A (Idle)             LP                C (Switching - LP)
                        LW                D (Idle - LW)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        Recover from SF   N/A
                        MS                G (Switching - MS)
                        Clear             N/A
                        WTR expires       N/A
                        EXER              I (Switching - EXER)
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   B (Pass-trough)      LP                C (Switching - LP)
                        LW                B (Pass-trough)
                        FS                O - if current state is due to
                                              LP sent by another node
                                          E (Switching - FS) - otherwise
                        SF                O - if current state is due to
                                              LP sent by another node
                                          F (Switching - SF) - otherwise
                        Recover from SF   N/A
                        MS                O - if current state is due to
                                              LP, SF or FS sent by
                                              another node
                                          G (Switching - MS) - otherwise
                        Clear             N/A
                        WTR expires       N/A
                        EXER              O
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   C (Switching - LP)   LP                N/A
                        LW                O
                        FS                O
                        SF                O
                        Recover from SF   N/A
                        MS                O
                        Clear             A (Idle) - if there is no
                                             failure in the ring
                                          F (Switching - SF) - if there
                                             is a failure at this node
                                          B (Pass-trough) - if there is
                                             a failure at another node
                        WTR expires       N/A
                        EXER              O
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------



 Cheng, et al.           Expires January 26, 2015              [Page 30]


Internet-Draft                    MSRP                         July 2014


   D (Idle - LW)        LP                C (Switching - LP)
                        LW                N/A - if on the same span
                                          D (Idle - LW) - if on another
                                             span
                        FS                O - if on the same span
                                          E (Switching - FS) - if on
                                             another span
                        SF                O - if on the addressed span
                                          F (Switching - SF) - if on
                                             another span
                        Recover from SF   N/A
                        MS                O - if on the same span
                                          G (Switching - MS) - if on
                                             another span
                        Clear             A (Idle) - if there is no
                                             failure on addressed span
                                          F (Switching - SF) - if there
                                             is a failure on this span
                        WTR expires       N/A
                        EXER              O
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   E (Switching - FS)   LP                C (Switching - LP)
                        LW                O - if on another span
                                          D (Idle - LW) - if on the same
                                             span
                        FS                N/A - if on the same span
                                          E (Switching - FS) - if on
                                             another span
                        SF                O - if on the addressed span
                                          E (Switching - FS) - if on
                                             another span
                        Recover from SF   N/A
                        MS                O
                        Clear             A (Idle) - if there is no
                                             failure in the ring
                                          F (Switching - SF) - if there
                                             is a failure at this node
                                          B (Pass-trough) - if there is
                                             a failure at another node
                        WTR expires       N/A
                        EXER              O
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   F (Switching - SF)   LP                C (Switching - LP)
                        LW                O - if on another span



 Cheng, et al.           Expires January 26, 2015              [Page 31]


Internet-Draft                    MSRP                         July 2014


                                          D (Idle - LW) - if on the same
                                             span
                        FS                E (Switching - FS)
                        SF                N/A - if on the same span
                                          F (Switching - SF) - if on
                                             another span
                        Recover from SF   H (Switching - WTR)
                        MS                O
                        Clear             N/A
                        WTR expires       N/A
                        EXER              O
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   G (Switching - MS)   LP                C (Switching - LP)
                        LW                O - if on another span
                                          D (Idle - LW) - if on the same
                                             span
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        Recover from SF   N/A
                        MS                N/A - if on the same span
                                          G (Switching - MS) - if on
                                             another span release the
                                             switches but signal MS
                        Clear             A
                        WTR expires       N/A
                        EXER              O
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   H (Switching - WTR)  LP                C (Switching - LP)
                        LW                D (Idle - W)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        Recover from SF   N/A
                        MS                G (Switching - MS)
                        Clear             A
                        WTR expires       A
                        EXER              O
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   I (Switching - EXER) LP                C (Switching - LP)
                        LW                D (idle - W)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        Recover from SF   N/A



 Cheng, et al.           Expires January 26, 2015              [Page 32]


Internet-Draft                    MSRP                         July 2014


                        MS                G (Switching - MS)
                        Clear             A
                        WTR expires       N/A
                        EXER              N/A - if on the same span
                                          I (Switching - EXER)
   =====================================================================

3.2.3.  State transitions when remote request is applied

   The priority of remote request does not depend on the side from which
   the request is received.

   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   A (Idle)             LP                C (Switching - LP)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        MS                G (Switching - MS)
                        WTR               N/A
                        EXER              I (Switching - EXER)
                        RR                N/A
                        NR                A (Idle)
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   B (Pass-trough)      LP                C (Switching - LP)
                        FS                N/A - cannot happen when there
                                               is LP request in the ring
                                          E (Switching - FS) - otherwise
                        SF                N/A - cannot happen when there
                                               is LP request in the ring
                                          F (Switching - SF) - otherwise
                        MS                N/A - cannot happen when there
                                                is LP, FS or SF request
                                                in the ring
                                          G (Switching - MS) - otherwise
                        WTR               N/A - cannot happen when there
                                                is LP, FS, SF or MS
                                                request in the ring
                        EXER              N/A - cannot happen when there
                                                is LP, FS, SF, MS or WTR
                                                request in the ring
                                          I (Switching - EXER) -
                                                otherwise
                        RR                N/A
                        NR                A (Idle) - if received from
                                                     both sides



 Cheng, et al.           Expires January 26, 2015              [Page 33]


Internet-Draft                    MSRP                         July 2014


   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   C (Switching - LP)   LP                C (Switching - LP)
                        FS                N/A - cannot happen when there
                                               is LP request in the ring
                        SF                N/A - cannot happen when there
                                               is LP request in the ring
                        MS                N/A - cannot happen when there
                                               is LP request in the ring
                        WTR               N/A
                        EXER              N/A - cannot happen when there
                                               is LP request in the ring
                        RR                C (Switching - LP)
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   D (Idle - LW)        LP                C (Switching - LP)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        MS                G (Switching - MS)
                        WTR               N/A
                        EXER              I (Switching - EXER)
                        RR                N/A
                        NR                D (Idle - LW)
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   E (Switching - FS)   LP                C (Switching - LP)
                        FS                E (Switching - FS)
                        SF                E (Switching - FS)
                        MS                N/A - cannot happen when there
                                               is FS request in the ring
                        WTR               N/A
                        EXER              N/A - cannot happen when there
                                               is FS request in the ring
                        RR                E (Switching - FS)
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   F (Switching - SF)   LP                C (Switching - LP)
                        FS                F (Switching - SF)
                        SF                F (Switching - SF)
                        MS                N/A - cannot happen when there
                                               is SF request in the ring
                        WTR               N/A



 Cheng, et al.           Expires January 26, 2015              [Page 34]


Internet-Draft                    MSRP                         July 2014


                        EXER              N/A - cannot happen when there
                                               is SF request in the ring
                        RR                F (Switching - SF)
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   G (Switching - MS)   LP                C (Switching - LP)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        MS                G (Switching - MS) - release
                                             the switches but signal MS
                        WTR               N/A
                        EXER              N/A - cannot happen when there
                                               is MS request in the ring
                        RR                G (Switching - MS)
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   H (Switching - WTR)  LP                C (Switching - LP)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        MS                G (Switching - MS)
                        WTR               H (Switching - WTR)
                        EXER              N/A - cannot happen when there
                                              is WTR request in the ring
                        RR                H (Switching - WTR)
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   I (Switching - EXER) LP                C (Switching - LP)
                        FS                E (Switching - FS)
                        SF                F (Switching - SF)
                        MS                G (Switching - MS)
                        WTR               N/A
                        EXER              I (Switching - EXER)
                        RR                I (Switching - EXER)
                        NR                N/A
   =====================================================================

3.2.4.  State Transitions when request addresses to another node is
        received

   The priority of remote request does not depend on the side from which
   the request is received.




 Cheng, et al.           Expires January 26, 2015              [Page 35]


Internet-Draft                    MSRP                         July 2014


   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   A (Idle)             LP                B (Pass-trough)
                        FS                B (Pass-trough)
                        SF                B (Pass-trough)
                        MS                B (Pass-trough)
                        WTR               B (Pass-trough)
                        EXER              B (Pass-trough)
                        RR                N/A
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   B (Pass-trough)      LP                B (Pass-trough)
                        FS                N/A - cannot happen when there
                                               is LP request in the ring
                                          B (Pass-trough) - otherwise
                        SF                N/A - cannot happen when there
                                               is LP request in the ring
                                          B (Pass-trough) - otherwise
                        MS                N/A - cannot happen when there
                                                is LP, FS or SF request
                                                in the ring
                                          B (Pass-trough) - otherwise
                        WTR               N/A - cannot happen when there
                                                is LP, FS, SF or MS
                                                request in the ring
                                          B (Pass-trough) - otherwise
                        EXER              N/A - cannot happen when there
                                                is LP, FS, SF, MS or WTR
                                                request in the ring
                                          B (Pass-trough) - otherwise
                        RR                N/A
                        NR                B (Pass-trough)
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   C (Switching - LP)   LP                C (Switching - LP)
                        FS                N/A - cannot happen when there
                                               is LP request in the ring
                        SF                N/A - cannot happen when there
                                               is LP request in the ring
                        MS                N/A - cannot happen when there
                                               is LP request in the ring
                        WTR               N/A - cannot happen when there
                                               is LP in the ring
                        EXER              N/A - cannot happen when there



 Cheng, et al.           Expires January 26, 2015              [Page 36]


Internet-Draft                    MSRP                         July 2014


                                               is LP request in the ring
                        RR                N/A
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   D (Idle - LW)        LP                B (Pass-trough)
                        FS                B (Pass-trough)
                        SF                B (Pass-trough)
                        MS                B (Pass-trough)
                        WTR               B (Pass-trough)
                        EXER              B (Pass-trough)
                        RR                N/A
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   E (Switching - FS)   LP                B (Pass-trough)
                        FS                E (Switching - FS)
                        SF                E (Switching - FS)
                        MS                N/A - cannot happen when there
                                               is FS request in the ring
                        WTR               N/A - cannot happen when there
                                               is FS request in the ring
                        EXER              N/A - cannot happen when there
                                               is FS request in the ring
                        RR                N/A
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   F (Switching - SF)   LP                B (Pass-trough)
                        FS                F (Switching - SF)
                        SF                F (Switching - SF)
                        MS                N/A - cannot happen when there
                                               is SF request in the ring
                        WTR               N/A - cannot happen when there
                                               is SF request in the ring
                        EXER              N/A - cannot happen when there
                                               is SF request in the ring
                        RR                N/A
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   G (Switching - MS)   LP                B (Pass-trough)
                        FS                B (Pass-trough)
                        SF                B (Pass-trough)



 Cheng, et al.           Expires January 26, 2015              [Page 37]


Internet-Draft                    MSRP                         July 2014


                        MS                G (Switching - MS) - release
                                             the switches but signal MS
                        WTR               N/A - cannot happen when there
                                               is MS request in the ring
                        EXER              N/A - cannot happen when there
                                               is MS request in the ring
                        RR                N/A
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   -------------        -----------       ---------
   H (Switching - WTR)  LP                B (Pass-trough)
                        FS                B (Pass-trough)
                        SF                B (Pass-trough)
                        MS                B (Pass-trough)
                        WTR               N/A
                        EXER              N/A - cannot happen when there
                                              is WTR request in the ring
                        RR                N/A
                        NR                N/A
   =====================================================================
   Initial state        New request       New state
   I (Switching - EXER) LP                B (Pass-trough)
                        FS                B (Pass-trough)
                        SF                B (Pass-trough)
                        MS                B (Pass-trough)
                        WTR               N/A
                        EXER              I (Switching - EXER)
                        RR                N/A
                        NR                N/A
   =====================================================================

4.  IANA Considerations

   Channel Types for the Generic Associated Channel are allocated from
   the IANA PW Associated Channel Type registry defined in RFC4446
   [RFC4446] and updated byRFC5586 [RFC5586].

   IANA is requested to allocate further Channel Type as follows:

   o 0xXX Ring Protection Switching (RPS) Note to RFC Editor:

   this section may be removed on publication as an RFC.








 Cheng, et al.           Expires January 26, 2015              [Page 38]


Internet-Draft                    MSRP                         July 2014


5.  Security Considerations

   This document does not by itself raise any particular security
   considerations.

6.  Normative Refereces

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

   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

   [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

   Email: chengweiqiang@chinamobile.com


   Lei Wang
   China Mobile

   Email: Wangleiyj@chinamobile.com






 Cheng, et al.           Expires January 26, 2015              [Page 39]


Internet-Draft                    MSRP                         July 2014


   Han Li
   China Mobile

   Email: Lihan@chinamobile.com


   Huub van Helvoort
   Huawei Technologies Co., Ltd.

   Email: huub.van.helvoort@huawei.com


   Kai Liu
   Huawei Technologies Co., Ltd.

   Email: alex.liukai@huawei.com


   Jia He
   Huawei Technologies Co., Ltd.

   Email: hejia@huawei.com


   Fang Li
   China Academy of Telecommunication Research, MIIT., China

   Email: lifang@ritt.cn








 Cheng, et al.           Expires January 26, 2015              [Page 40]


Internet-Draft                    MSRP                         July 2014


   Jian Yang
   ZTE Corporation P.R.China

   Email: yang.jian90@zte.com.cn


   Junfang Wang
   Fiberhome Telecommunication Technologies Co., LTD.

   Email: wjf@fiberhome.com.cn



































 Cheng, et al.           Expires January 26, 2015              [Page 41]


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