Network Working Group WQ. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li Expires: January 09, 2014 China Mobile 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 08, 2013 MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology draft-cheng-mpls-tp-shared-ring-protection-01 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 RFC5654 for optimized ring protection. 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." This Internet-Draft will expire on January 09, 2014. Cheng, et al. Expires January 09, 2014 [Page 1] Internet-Draft MSRP July 2013 Copyright Notice Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements for MPLS-TP ring protection . . . . . . . . 3 1.1.1. Recovery for Multiple failures . . . . . . . . . . . 3 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 . . . 7 2.1.3. Failure detection . . . . . . . . . . . . . . . . . . 8 2.2. P2P wrapping . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Wrapping for Link Failure . . . . . . . . . . . . . . 9 2.2.2. Wrapping for node Failure . . . . . . . . . . . . . . 10 2.3. P2P short wrapping . . . . . . . . . . . . . . . . . . . 10 2.4. P2P steering . . . . . . . . . . . . . . . . . . . . . . 12 2.5. P2P wrapping for Interconnected Rings . . . . . . . . . . 14 2.5.1. Interconnected ring topology . . . . . . . . . . . . 14 2.5.2. Interconnected ring protection scheme . . . . . . . . 15 3. Coordination protocol . . . . . . . . . . . . . . . . . . . . 20 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction Cheng, et al. Expires January 09, 2014 [Page 2] Internet-Draft MSRP July 2013 As described in 2.5.6.1. ring protection of MPLS-TP requirements [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-TP [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]. 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. 1.1. Requirements for MPLS-TP ring protection The requirements for MPLS-TP ring protection are specified in 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, 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 Cheng, et al. Expires January 09, 2014 [Page 3] Internet-Draft MSRP July 2013 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 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. Cheng, et al. Expires January 09, 2014 [Page 4] Internet-Draft MSRP July 2013 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(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. |------------- |-------------| |-------------| | =====PW1======| | | | | Ring | Physical =====PW2======| LSP | Tunnel | Port | | | =====PW3======| | | |-------------| | |-------------| |------------- Figure 1 the logic layers of the ring Cheng, et al. Expires January 09, 2014 [Page 5] Internet-Draft MSRP July 2013 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. 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; Cheng, et al. Expires January 09, 2014 [Page 6] Internet-Draft MSRP July 2013 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. +---+#############+---+ | 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 [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 Cheng, et al. Expires January 09, 2014 [Page 7] Internet-Draft MSRP July 2013 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. 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 Cheng, et al. Expires January 09, 2014 [Page 8] Internet-Draft MSRP July 2013 defined in [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 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# Cheng, et al. Expires January 09, 2014 [Page 9] Internet-Draft MSRP July 2013 +---+*****[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)-> [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 Cheng, et al. Expires January 09, 2014 [Page 10] Internet-Draft MSRP July 2013 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 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 Cheng, et al. Expires January 09, 2014 [Page 11] Internet-Draft MSRP July 2013 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. +--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 Cheng, et al. Expires January 09, 2014 [Page 12] Internet-Draft MSRP July 2013 [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. 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 Cheng, et al. Expires January 09, 2014 [Page 13] Internet-Draft MSRP July 2013 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. +-- 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 Cheng, et al. Expires January 09, 2014 [Page 14] Internet-Draft MSRP July 2013 interconnected rings. This topology can recover from one interconnection node failure. 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 Cheng, et al. Expires January 09, 2014 [Page 15] Internet-Draft MSRP July 2013 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. - 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, Cheng, et al. Expires January 09, 2014 [Page 16] Internet-Draft MSRP July 2013 - 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. 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 09, 2014 [Page 17] Internet-Draft MSRP July 2013 +---+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. Cheng, et al. Expires January 09, 2014 [Page 18] Internet-Draft MSRP July 2013 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 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 09, 2014 [Page 19] Internet-Draft MSRP July 2013 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 TBD 4. Conclusions TBD 5. IANA Considerations None 6. Security Considerations TBD 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Cheng, et al. Expires January 09, 2014 [Page 20] Internet-Draft MSRP July 2013 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. Authors' Addresses Weiqiang Cheng China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: chengweiqiang@chinamobile.com Lei Wang China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: Wangleiyj@chinamobile.com Han Li China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: Lihan@chinamobile.com Kai Liu Huawei Technologies Co., Ltd. Huawei base, Bantian, Longgang District Shenzhen 518129 China Email: alex.liukai@huawei.com Cheng, et al. Expires January 09, 2014 [Page 21] Internet-Draft MSRP July 2013 Jia He Huawei Technologies Co., Ltd. Huawei base, Bantian, Longgang District Shenzhen 518129 China Email: hejia@huawei.com Fang Li China Academy of Telecommunication Research, MIIT., China No.52 Huayuan Street Beijing 100191 China Email: lifang@ritt.cn Jian Yang ZTE Corporation P.R.China ZTE Industrial Zone, Liuxian Road Shenzhen 518055 China Email: yang.jian90@zte.com.cn Junfang Wang Fiberhome Telecommunication Technologies Co., LTD. No.5, Dongxin Lu Wuhan 430073 China Email: wjf@fiberhome.com.cn Cheng, et al. Expires January 09, 2014 [Page 22]