Network Working Group WQ. Cheng Internet-Draft L. Wang Intended status: Informational H. Li Expires: April 18, 2013 China Mobile K. Liu J. He Huawei Technologies Co., Ltd. F. Li Research Institute of Telecommunication Transmission,China Academy of Telecommunication Research, MIIT. China J. Yang ZTE Corporation P.R.China J. Wang Fiberhome Telecommunication Technologies Co.,LTD October 15, 2012 MPLS-TP Shared Ring protection (MSRP) mechanism draft-cheng-mpls-tp-shared-ring-protection-00 Abstract This document describes requirements and solutions for MPLS-TP Shared ring protection (MSRP) in ring topology for point to point (P2P) services. The mechanisms of MSRP are illustrated and analyzed how to satisfy the MPLS-TP requirements in RFC5654 for optimized ring protection. MSRP could support wrapping and steering protection mechanisms for P2P services, which provide a simple and reliable protection switching. The survivability of the network could be improved and the operation and maintain could be more easy. Ring protection solution for p2mp services will be documented in another draft latterly. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Cheng, et al. Expires April 18, 2013 [Page 1] Internet-Draft MSRP October 2012 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Cheng, et al. Expires April 18, 2013 [Page 2] Internet-Draft MSRP October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Recovery for Multiple failures . . . . . . . . . . . . 4 1.1.2. Upgrade from linear protection to ring protection . . 5 1.1.3. Configuration complexity . . . . . . . . . . . . . . . 5 1.2. Terminology and Notation . . . . . . . . . . . . . . . . . 5 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 2. Shared ring protection for P2P . . . . . . . . . . . . . . . . 6 2.1. Basic conception . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. The establishment of the Ring tunnels . . . . . . . . 7 2.1.2. The distribution and management of ring labels . . . . 8 2.1.3. Failure detection . . . . . . . . . . . . . . . . . . 9 2.2. P2P wrapping . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Wrapping Link Failure . . . . . . . . . . . . . . . . 10 2.2.2. Wrapping node Failure . . . . . . . . . . . . . . . . 11 2.3. P2P steering . . . . . . . . . . . . . . . . . . . . . . . 11 3. Coordination protocol . . . . . . . . . . . . . . . . . . . . 14 4. Conclusions and Recommendations . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Normative References . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Cheng, et al. Expires April 18, 2013 [Page 3] Internet-Draft MSRP October 2012 1. Introduction As described in 2.5.6.1. Ring Protection of MPLS-TP requirements [RFC5654], several service providers have expressed a high level of interest in operating MPLS-TP in ring topologies and require a high level of survivability function in these topologies. MPLS-TP networks are often constructed with ring topologies which allow service providers setting up a efficient and optimized ring protection mechanism to achieve simplified operation and fast recovery performance. The requirements for MPLS-TP [RFC5654] state that recovery mechanisms are optimized for Ring topologies may be developed if it can provide following optimization scenarios: a. Minimize the number of OAM entities for protection b. Minimize the number of elements of recovery c. Minimize the number of labels required d. Minimize the amount of control and management-plane transactions e. Minimize the impact on information exchange if control plane supported This document specifies MPLS-TP Shared-Ring Protection mechanisms which can meet all those requirements on Ring protection listed in [RFC5654]. This document focus on the solutions for Point-to-point transport path and a related topic in [RFC5654] states the required support for point-to-multipoint transport path. The solution for point-to- multipoint solution is under evaluation and will be illustrated in a separate document based on the basic conception in this document. 1.1. Problem statement 1.1.1. Recovery for Multiple failures MPLS-TP is expected to be used in carrier grade metro networks and backbone networks for providing mobile backhauling, business customers' services and etc., in such kind of application scenarios the network survivability are very important. According to R106 B in RFC5654, MPLS-TP recovery mechanisms in a ring SHOULD protect against multiple failures. It's expected deploying ring protection in ring topology could enhance the network Cheng, et al. Expires April 18, 2013 [Page 4] Internet-Draft MSRP October 2012 survivability to against multiple failures in many cases. Following context provide some more detail illustration to "multiple failures". In metro and backbone networks, the single risk factor often affects multiple links or nodes. Some examples of risk factors are given in follows: - multiple links using fibers in one cable or pipeline - Several nodes shared one power supply system - weather sensitive micro-wave system Once one risk factor happens, multiple near-simultaneous links or nodes failures occur and those failed links or nodes may locate on single ring as well as on interconnected multiple rings. The ability of ring protecting against multiple failures should cover both multiple failures on single ring scenario and multiple failures on interconnected multiple rings. 1.1.2. Upgrade from linear protection to ring protection It is beneficial for service providers to upgrade their MPLS-TP based network from the linear protection to ring protection without service interruption, and supporting in-service insertion and removal of a node on the ring. In order to realize this requirement, the ring protection Mechanisms should be developed and optimized to comply with this upgrading principle. 1.1.3. Configuration complexity In the application scenarios of deploying linear protection in MPLS-TP network, the configuration of protection has close relationship with the services, LSP quantities. Especially in some large metro networks with more than ten thousands of services access node, the LSP linear protection capabilities of the metro core nodes should be large enough to meet the network planning requirements, which also leads to the complexity of network protection configurations and operations. While the ring protection is based on the mechanisms on section layer, it has loose relationship with the services quantities which could simplify the network protection configurations and operations. 1.2. Terminology and Notation The following syntax will be used to describe the contents of the label stack: Cheng, et al. Expires April 18, 2013 [Page 5] Internet-Draft MSRP October 2012 1. The label stack will be enclosed in square brackets ("[]"). 2. Each level in the stack will be separated by the '|' character. It should be noted that the label stack may contain additional levels however, we only present the levels that are germane to the protection mechanism. 3. If the Label is assigned by Node x, the Node Name will enclosed in bracket(" ()") 1.3. Contributing Authors Wen Ye(China Mobile) 2. Shared ring protection for P2P None 2.1. Basic conception This document introduces an independent logic layer of ring for both working path and protection path for shared ring protection in MPLS-TP networks. The logic layer is a ring tunnel on top of the working path or the protection path as shown in Figure 1, namely working ring tunnel or protection ring tunnel respectively. Once the ring tunnel is established, the configuration, management and protection of the ring are all based on the ring tunnel. One port can carry more than one ring tunnel, while one ring tunnel can carry several LSPs. |------------- |-------------| |-------------| | =====PW1======| | | | | Ring | Physical =====PW2======| LSP | Tunnel | Port | | | =====PW3======| | | |-------------| | |-------------| |------------- Figure 1 the logic layers of the ring The label stack used in MPLS-TP Shared Ring Protection mechanism are shown as below. Cheng, et al. Expires April 18, 2013 [Page 6] Internet-Draft MSRP October 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring tunnel Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Label Stack used in MPLS-TP Shared Ring Protection 2.1.1. The establishment of the Ring tunnels A ring tunnel is created as per exit node. The exit node means the node on the ring where the traffic leaves the ring. All the LSPs which transverse the ring and exit at the same ring node share the same working ring tunnels and protection ring tunnels. For each exit node, 4 ring tunnels are established: - 1 clockwise working ring tunnel, protected by - 1 anticlockwise protection ring tunnel, - 1 anticlockwise working ring tunnel, protected by - 1 clockwise protection ring tunnel. An example is shown in Figure 3 where Node D behaves as an exit node. LSP 1 entering the ring at Node E, LSP2 at Node A and LSP 3 at Node B, all leave the ring at Node D. . To protect these LSPs traversing the ring, a clockwise working ring tunnel (RcW_D), E->F->A->B->C->D and its protection ring tunnel in the reverse direction (RaP_D), D->C->B->A->F->E->D ; Ananticlockwise working ring channel (RaW_D), C->B->A->F->E->D and its clockwise protection ring tunnel (RcP_D), D->E->F->A->B->C->D are established for Node D. Figure 3 only shows RcW_D and RaP_D for readability. The similar provisioning should be repeated for every other node on the ring. The ring tunnels created for the other nodes in Figure 3 when acting as exit node are provided as follows: To Node A: RcW_A, RaW_A, RcP_A, RaP_A; To Node B: RcW_B, RaW_B, RcP_B, RaP_B; To Node C: RcW_C, RaW_C, RcP_C, RaP_C; To Node E: RcW_E, RaW_E, RcP_E, RaP_E; Cheng, et al. Expires April 18, 2013 [Page 7] Internet-Draft MSRP October 2012 To Node F: RcW_F, RaW_F, RcP_F, RaP_F; In Node D, two working ring tunnels, RcW_D and RaW_D are terminated; and two protection ring tunnels, RcP_D and RaP_D, are transit. That means through those working ring tunnels with protection ring tunnels, LSPs which enter the ring from Node D can reach any other nodes on the ring, while Node D can also receive the traffic from any other nodes. +---+#############+---+ | F |-------------| A | +-- LSP2 +---+*************+---+ #/* *\# #/* *\# #/* *\# +---+ +---+ LSP1-+ | E | | B |+-- LSP3 +---+ +---+ #\ */# #\ */# #\ */# +---+*************+---+ LSP1 +--| D |-------------| C | LSP2 +---+#############+---+ LSP3 ---- physical links **** RcW_D #### RaP_D Figure 3 the Ring tunnels of the ring 2.1.2. The distribution and management of ring labels Ring tunnel labels are distributed by means of downstream-assigned mechanism as defined in [RFC3031]. When an MPLS-TP transport path, e.g. LSP, enters the ring, according to the ring ID and the exit node, the ingress node pushes the working ring tunnel label and sends the traffic to the next hop; The transit nodes of the working ring tunnel swap the ring tunnel label and forward the packets to the next hop; When arriving at the egress node, the egress node pops the ring tunnel label and forwards the packets based on the inner LSP label and PW label.Figure 4 shows the label operation in MPLS-TP Shared Ring Protection mechanism. Suppose LSP 1 enters the ring at Node A and exit at Node D, the following label operations are executed. 1. The traffic LSP1 arrives at Node A with a label stack [LSP1] and Cheng, et al. Expires April 18, 2013 [Page 8] Internet-Draft MSRP October 2012 is supposed to be forwarded in the clockwise direction of the ring. The clockwise working ring tunnel label RcW_D will be pushed at Node A, the label stack for the forwarded packet at Node A is changed to [RcW_D(B)|LSP1] 2．Transit nodes, in this case Node B and C, forward the packet by swapping the working ring tunnel label. For Example, the label [RcW_D(B)|LSP1] is swapped to [RcW_D(C)|LSP1] at Node B. 3. When the packet arrives at Node D (i.e. egress node) with label stack [RcW_D(D)|LSP1], Node D Pops RcW_D(D) and further deals with the inner labels of LSP1. 4. All the LSPs exit at the same node share the same Ring tunnel label. +---+#####[RaP_D(A)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ #/* *\# [RaP_D(F)]#/*[RcW_D(F)] RcW_D(B)]*\#RaP_D(B) #/* *\# +---+ +---+ | E | | B | +---+ +---+ #\ */# [RaP_D(D)]#\ [RxW_D(C)]*/#RaP_D(C) #\ */# +---+*****[RcW_D(D)]****+---+ LSP1 +-- | D |-------------------| C | +---+#####[RaP_D(C)]####+---+ -----physical links ****** RcW_D ###### RaP_D Figure 4 Label operation of the ring 2.1.3. Failure detection The MPLS-TP section layer OAM is used to monitor the connectivity between each two adjacent nodes on the ring using the mechanisms defined in [RFC6371].Protection switching occurs on the detection of failure on a link in the ring monitored by OAM functions. Two end ports of a link form a MEG, and an MEG end point (MEP) function is installed in each ring port. Periodic CC-V OAM packets exchange is activated between each pair of MEPs to monitor the link Cheng, et al. Expires April 18, 2013 [Page 9] Internet-Draft MSRP October 2012 health. Sequential consecutive loss of CC-V packets (3 packets) is interpreted as a link failure. A node failure is regarded as the failure of two links attached to the node. The two nodes adjacent to the failed node detect the failure on the links connected to the failed node. 2.2. P2P wrapping Normal state is shown in Figure 4. The clockwise LSP1 towards node D enters the ring at Node A. In normal state, LSP 1 follows the path A->B->C-D, label operation is [LSP1](original data traffic carried by LSP 1)->[RCW_D(B)|LSP1](NodeA)->[RCW_D(C)|LSP1](NodeB)->[RCW_D(D)| LSP1](NodeC)->[LSP1]( data traffic carried by LSP 1). Then traffic packet will be forwarded on the basis of LSP1. 2.2.1. Wrapping Link Failure When a link failure between Node B and Node C occurrs, both Node B and Node C detect the failure by OAM mechanism. Node B switches the clockwise working ring tunnel(RcW_D) to the anticlockwise protection ring tunnel (RaP_D)and Node C switches anticlockwise protection ring tunnel(RaP_D) to the clockwisework ring tunnel(RcW_D). The data traffic which enters the ring at Node A and exits at Node D follows the pathA->B->A->F->E->D->C->D. The label operation is [LSP1](Original data packet)-> [RcW_D(B)|LSP1](NodeA)-> [RaP_D(A)| LSP1](NodeB)->[RaP_D(F)|LSP1](NodeA)->[RaP_D(E)|LSP1] (NodeF)-> [RaP_D(D)|LSP1] (NodeE)-> [RaP_D(C)|LSP1] (NodeD)-> [RcW_D(D)| LSP1](NodeC)->[LSP1](Exit data packet). +---+#####[RaP_D(F)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ #/* *\# [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) #/* *\# +---+ +---+ | E | | B | +---+ +---+ #\ *x# [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) #\ *x# +---+*****[RcW_D(D)]****+---+ LSP1 +-- | D |-------------------| C | +---+#####[RaP_D(C)]####+---+ -----physical links xxxx Failure Link Cheng, et al. Expires April 18, 2013 [Page 10] Internet-Draft MSRP October 2012 ****** RcW_D ###### RaP_D Figure 5 Link Failure of P2P Wrapping 2.2.2. Wrapping node Failure When Node B fails, Node A detects the failure between A and B and switches the clockwise work ring tunnel(RcW_D) to the anticlockwise protection ring tunnel(RaP_D), Node C detects the failure between C and B and switches the anticlockwise protection ring tunnel(RaP_D) to the clockwise working ring tunnel(RcW_D). The data traffic which enters the ring at Node A and exits at Node D follows the path A->F->E->D->C->D. The label operation is [LSP1](original data traffic carried by LSP 1)-> [RaP_D(F)|LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)-> [RaP_D(D)|LSP1](NodeE)-> [RaP_D(C)|LSP1] (NodeD)->[RcW_D(D)|LSP1] (NodeC)->[LSP1](data traffic carried by LSP 1). +---+#####[RaP_D(F)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ #/* *\# [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) #/* *\# +---+ xxxxx | E | x B x +---+ xxxxx #\ */# [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) #\ */# +---+*****[RcW_D(D)]****+---+ LSP1 +-- | D |-------------------| C | +---+#####[RaP_D(C)]####+---+ -----physical links xxxxxx Failure Node *****RcW_D ###### RaP_D Figure 6 Node Failure of P2P Wrapping 2.3. P2P steering Each working ring tunnel is associated with a protection ring tunnel in the opposite direction. Every node needs to know the ring topology by configuration or topology discovery. When the failure occurs, the nodes which detect the failure will spread the fault information in the opposite direction node by node in the ring respectively. When the node receives the message that informs the Cheng, et al. Expires April 18, 2013 [Page 11] Internet-Draft MSRP October 2012 failure, it will quickly figure out the location of the fault by the topology information that is maintained by itself, so that it will determine whether the LSPs enter the ring from itself needs switch- over. If yes, it will switch the LSPs from the working ring tunnel to its protection ring tunnel. If no, it will ignore the fault indication message. +--LSP l +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---+ +-+-+-+-+-+-+-+ |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ |I|I|I|S|I|I| |I|I|S|I|I|I| +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] #/* [RcW_D(F)] *\# +-+-+-+-+-+-+-+ #/* *\# |E|F|A|B|C|D|E| +---+ +---+ +-- LSP 2 +-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ |I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B| +-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ #\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I| [RaP_D(D)] #\* */# +-+-+-+-+-+-+ #\* */# [RaP_D(B)] +-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+ |D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C| +-+-+-+-+-+-+-+ LSP 1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+ |I|I|I|I|I|S| LSP 2 |S|I|I|I|I|I| +-+-+-+-+-+-+ +-+-+-+-+-+-+ ----- physical links ***** RcW_D ##### RaP_D Figure 7 the P2P steering operation and protection switching(1) Steering Example is shown in figure 7. LSP1 enters the ring from Node A while Node B has an LSP2, and both of them have the same destination node D. As per Figure 7, in normal state, LSP1 follows the path A->B->C->D, the label operation is [LSP1](original data traffic carried by LSP 1 )->[RcW_D(B)|LSP1](NodeA)->[RcW_D(C)| LSP1](NodeB)->[RcW_D(D)|LSP1](NodeC)->[LSP1] ( data traffic carried by LSP 1) . LSP2 goes through the path B->C->D, the label operation is [LSP2]->[RcW_D(C)|LSP2](NodeB)->[RcW_D(D)|LSP2](NodeC)-> [LSP2] ( data traffic carried by LSP 1) . If the link between C and D breaks down, as Figure 7 shows, according to the fault detection function of each link, Node D will find out that there is a failure in the link between C and D, and it will Cheng, et al. Expires April 18, 2013 [Page 12] Internet-Draft MSRP October 2012 update the link state of its ring topology, changing the link state between C and D from normal to fault, as Figure 7 shows. In the direction that goes away from the failure point, Node D will send the state report message to Node E, informing Node E of the fault between C and D, and E will update the link state of its ring topology, changing the link state between C and D from normal to fault. And the like, the state report message is sent from node to node in the clockwise direction.Similar to Node D, Node C will spread the failure information in anti-clockwise direction. Until Node A updates the link state of its ring topology, and knows there is a fault within its working path. And at the same time it can get the conclusion that the anticlockwise path from A to D is working all right. so that Node A will switch the LSP1 operation to the anticlockwise tunnel. LSP1 will follow the path A->F->E->D, the label operation is [LSP1](original data traffic carried by LSP 1 )->[RaP_D(F)| LSP1](NodeA)->[RaP_D(E)|LSP1](NodeF)->[RaP_D(D)|LSP1](NodeE)->[LSP1] ( data traffic carried by LSP 1). The same goes with LSP2 operation, when Node B updates the link state of its ring topology, and find out the working path fault, so it will stop sending the LSP2 operation in clockwise direction and switch the LSP2 to the anticlockwise protection tunnel. LSP2 goes through the path B->A->F->E->D, the label operation is [LSP2](original data traffic carried by LSP 2 )-> [RaP_D(A)|LSP2](NodeB)->[RaP_D(F)| LSP2](NodeA)->[RaP_D(E)|LSP2](NodeF)->[RaP_D(D)|LSP2](NodeE)->[LSP2] ( data traffic carried by LSP 2). Imagine the ring between A and B breaks down, as figure 8 shows. Like above, Node B will find out that there is a fault in the link between A and B, and it will update the link state of its ring topology, changing the link state between A and B from normal to fault. The state report message is sent from node to node in the clockwise direction, informing every node that there is a fault between node A and B, so that every node updates the link state of its ring topology. Node A will find out the working path fault of LSP1 and switch LSP1 to protection Ring tunnel, while Node B finds out the LSP2 working path is all right and there is no need for switching. Cheng, et al. Expires April 18, 2013 [Page 13] Internet-Draft MSRP October 2012 +-- LSP l +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---+ +-+-+-+-+-+-+-+ |F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ |I|S|I|I|I|I| #/* x |S|I|I|I|I|I| +-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ [RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] #/* x +-- LSP 2 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ |E|F|A|B|C|D|E| | E | | B ||B|C|D|E|F|A|B| +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ |I|I|S|I|I|I| #\* */# |I|I|I|I|I|S| +-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+ [RaP_D(D)] #\* */# [RaP_D(B)] +-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ |D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| +-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ |I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| +-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ ----- physical links ***** RcW_D ##### RaP_D Figure 8 the P2P steering operation and protection switching(2) 3. Coordination protocol TBD 4. Conclusions and Recommendations TBD 5. IANA Considerations None 6. Security Considerations TBD Cheng, et al. Expires April 18, 2013 [Page 14] Internet-Draft MSRP October 2012 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. Authors' Addresses Weiqiang Cheng China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: chengweiqiang@chinamobile.com Lei Wang China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: Wangleiyj@chinamobile.com Han Li China Mobile No.32 Xuanwumen West Street Beijing 100053 China Email: Lihan@chinamobile.com Cheng, et al. Expires April 18, 2013 [Page 15] Internet-Draft MSRP October 2012 Kai Liu Huawei Technologies Co., Ltd. Huawei base, Bantian, Longgang District Shenzhen 518129 China Email: alex.liukai@huawei.com Jia He Huawei Technologies Co., Ltd. Huawei base, Bantian, Longgang District Shenzhen 518129 China Email: hejia@huawei.com Fang Li Research Institute of Telecommunication Transmission,China Academy of Telecommunication Research, MIIT. China Number 52, Huayuan street, Haidian District Shenzhen 100191 China Email: lifang@ritt.cn Jian Yang ZTE Corporation P.R.China ZTE Industrial Zone,Liuxian Road, Xili District, Shenzhen Shenzhen 518055 China Email: yang.jian90@zte.com.cn Junfang Wang Fiberhome Telecommunication Technologies Co.,LTD No.5, Dongxin Lu, Guandong Industrial Park, Wuhan, Hubei Wuhan 430073 China Email: wjf@fiberhome.com.cn Cheng, et al. Expires April 18, 2013 [Page 16]