Network Working Group WQ. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li Expires: January 3, 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 02, 2014 MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology draft-cheng-mpls-tp-shared-ring-protection-02 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 3, 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. APS state machine . . . . . . . . . . . . . . . . . . . . 28 3.2.1. Initial states . . . . . . . . . . . . . . . . . . . 28 Cheng, et al. Expires January 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 2015 [Page 17] Internet-Draft MSRP July 2014 All the ring tunnels established in Ring1 in Figure 11 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 11 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 3, 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 3, 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 3, 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 3, 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 APS 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 APS 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 3, 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 APS 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 3, 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 APS 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 3, 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 APS request code. Multiple EXER request MUST be allowed to coexist in the ring. Cheng, et al. Expires January 3, 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 APS request on another span. Node still SHOULD signal relevant APS 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 APS 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 APS 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 APS 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 3, 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 APS 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 APS 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 3, 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 APS request destined to this node. 3.2. APS state machine 3.2.1. Initial states Cheng, et al. Expires January 3, 2015 [Page 28] Internet-Draft MSRP July 2014 +-----------------------------------+----------------+ | State | Signaled APS | +-----------------------------------+----------------+ | 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 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 3, 2015 [Page 41]