--- 1/draft-ietf-mpls-tp-shared-ring-protection-00.txt 2016-03-21 01:15:58.448777831 -0700 +++ 2/draft-ietf-mpls-tp-shared-ring-protection-01.txt 2016-03-21 01:15:58.556780503 -0700 @@ -1,31 +1,31 @@ Network Working Group W. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li -Expires: April 12, 2016 China Mobile +Expires: September 22, 2016 China Mobile H. Helvoort Hai Gaoming BV K. Liu J. Dong J. He Huawei Technologies F. Li China Academy of Telecommunication Research, MIIT., China J. Yang ZTE Corporation P.R.China J. Wang Fiberhome Telecommunication Technologies Co., LTD. - October 10, 2015 + March 21, 2016 MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology - draft-ietf-mpls-tp-shared-ring-protection-00 + draft-ietf-mpls-tp-shared-ring-protection-01 Abstract This document describes requirements, architecture 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 how it satisfies the requirements for optimized ring protection in RFC 5654 is analyzed. This document also defines the Ring Protection Switch (RPS) Protocol which is used to coordinate the protection behavior of the nodes on MPLS ring. @@ -44,84 +44,85 @@ 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 April 12, 2016. + This Internet-Draft will expire on September 22, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 2. Requirements for MPLS-TP Ring Protection . . . . . . . . . . 4 2.1. Recovery of Multiple Failures . . . . . . . . . . . . . . 4 - 2.2. Smooth Upgrade from Linear Protection to Ring Protection 4 + 2.2. Smooth Upgrade from Linear Protection to Ring Protection 5 2.3. Configuration Complexity . . . . . . . . . . . . . . . . 5 3. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 4. Shared Ring Protection Architecture . . . . . . . . . . . . . 5 4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Establishment of Ring Tunnel . . . . . . . . . . . . 6 4.1.2. Label Assignment and Distribution . . . . . . . . . . 8 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 8 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 9 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 10 - 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 10 - 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 12 - 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 14 - 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 17 - 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 17 - 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 18 - 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 19 - 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 21 - 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 22 - 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 23 + 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 11 + 4.3.2. Short Wrapping . . . . . . . . . . . . . . . . . . . 13 + 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 15 + 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 18 + 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 18 + 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 20 + 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 20 + 4.4.4. Interconnected Ring Switching Procedure . . . . . . . 22 + 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 23 + 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 24 5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 24 5.1.1. Transmission and Acceptance of RPS Requests . . . . . 26 5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 26 5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27 5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29 5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31 - 5.2.1. Initial States . . . . . . . . . . . . . . . . . . . 31 - 5.2.2. State transitions When Local Request is Applied . . . 32 - 5.2.3. State Transitions When Remote Request is Applied . . 36 - 5.2.4. State Transitions When Request Addresses to Another - Node is Received . . . . . . . . . . . . . . . . . . 39 - 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 41 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 - 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 42 - 6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 43 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 - 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 43 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 44 - 10.2. Informative References . . . . . . . . . . . . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 + 5.2.1. Switch Initiation Criteria . . . . . . . . . . . . . 31 + 5.2.2. Initial States . . . . . . . . . . . . . . . . . . . 33 + 5.2.3. State transitions When Local Request is Applied . . . 34 + 5.2.4. State Transitions When Remote Request is Applied . . 37 + 5.2.5. State Transitions When Request Addresses to Another + Node is Received . . . . . . . . . . . . . . . . . . 40 + 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 43 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 + 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 44 + 6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 44 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 + 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 + 10.2. Informative References . . . . . . . . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 1. Introduction As described in 2.5.6.1 of [RFC5654], Ring Protection of MPLS-TP requirements , several service providers have expressed much interest in operating MPLS-TP in ring topologies and require a high-level survivability function in these topologies. In operational transport network deployment, MPLS-TP networks are often constructed with ring topologies. It calls for an efficient and optimized ring protection mechanism to achieve simple operation and fast, sub 50 ms, recovery @@ -259,21 +260,21 @@ | LSP Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Label stack used in MPLS-TP Shared Ring Protection 4.1.1. Establishment of Ring Tunnel - The Ring tunnels are established based on the egress node. The + The Ring tunnels are established based on the egress nodes. The egress node is the node where traffic leaves the ring. LSPs which have the same egress node on the ring share the same ring tunnels. 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 egress node, four ring tunnels are established: o one clockwise working ring tunnel, which is protected by the anticlockwise protection ring tunnel o one anticlockwise protection ring tunnel @@ -275,36 +276,36 @@ o one clockwise working ring tunnel, which is protected by the anticlockwise protection ring tunnel o one anticlockwise protection ring tunnel o one anticlockwise working ring tunnel, which is protected by the clockwise protection ring tunnel o one clockwise protection ring tunnel + The structure of the protection tunnels are determined by the selected protection mechanism. This will be detailed in subsequent sections. As shown in Figure 3, LSP1, LSP2 and LSP3 enter the ring from Node E, - Node A and Node B, respectively, and all leave the ring at 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 anticlockwise - protection ring tunnel (RaP_D) via D->C->B->A->F->E->D are - established, 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. For simplicity Figure 3 - only shows RcW_D and RaP_D. A similar provisioning should be applied - for any other node on the ring. In summary, for each node in - Figure 3 when acting as egress node, the ring tunnels are created as - follows: + Node A and Node B respectively, and all leave the ring at 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 anticlockwise protection + ring tunnel (RaP_D) via D->C->B->A->F->E->D are established, 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. For simplicity Figure 3 only shows RcW_D and RaP_D. + A similar provisioning should be applied for any other node on the + ring. In summary, for each node in Figure 3 when acting as egress + node, the ring tunnels are created as follows: o To Node A: RcW_A, RaW_A, RcP_A, RaP_A o To Node B: RcW_B, RaW_B, RcP_B, RaP_B o To Node C: RcW_C, RaW_C, RcP_C, RaP_C o To Node D: RcW_D, RaW_D, RcP_D, RaP_D o To Node E: RcW_E, RaW_E, RcP_E, RaP_E @@ -410,52 +411,87 @@ failure in the links that are connected to the failed node. 4.3. Ring Protection This section specifies the ring protection mechanisms in detail. In general, the description uses the clockwise working ring tunnel and the corresponding anti-clockwise protection ring tunnel as example, but the mechanism is applicable in the same way to the anti-clockwise working and clockwise protection ring tunnels. - Taking the topology in Figure 4 as example, the LSP1 enters the ring - at Node A and leaves the ring at Node D. In normal state, LSP1 is + In ring network, each working ring tunnel is associated with a + protection ring tunnel in the opposite direction, and every node can + obtain the ring topology either by configuration or via some topology + discovery mechanism. The ring topology and the connectivity (Intact + or Severed) between the adjacent ring nodes form the ring map. Each + ring node maintains the ring map and use it to peform ring + protection. + + Taking the topology in Figure 4 as example, LSP1 enters the ring at + Node A and leaves the ring at Node D. In normal state, LSP1 is carried by clockwise working ring tunnel (RcW_D) through the path A->B->C->D, the label operation is: [LSP1](original data traffic carried by LSP1) -> [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) -> [RCW_D(D)| LSP1](NodeC) -> [LSP1](data traffic carried by LSP1). Then at node D - the packet will be forwarded based on label stack of LSP1. + the packet will be forwarded based on the label stack of LSP1. - The following sections describes the protection mechanisms used in - ring topology. + Three typical ring protection mechanisms are specified in this + section: wrapping, short wrapping and steering. + + In wrapping ring protection, node which detects a failure or accepts + a switch request switches the traffic impacted by the failure to the + opposite direction (away from the failure). In this way, the + impacted traffic is switched to the protection ring tunnel by the + switching node upstream to the failure, then travels around the ring + to the other switching node through the protection ring tunnel, where + it is switched back onto the working ring tunnel and reach the egress + node. + + Short wrapping ring protection provides some optimization to wrapping + protection, in which the impacted traffic is only switched once to + the protection ring tunnel by the switching node upstream to the + failure. At the egress node, the traffic leave the ring from the + protection ring tunnel. This can reduce the traffic detour of + wrapping protection. + + Steering ring protection implies that the node that detects a failure + sends a request along the ring to the other node adjacent to the + failure, and all nodes in the ring process this information. For the + impaced traffic, the ingress node (which adds traffic to the ring) + perform switching from working to the protection ring tunnel, and at + the egress node the traffic leaves the ring from the protection ring + tunnel. + + The following sections describes these protection mechanisms in + detail. 4.3.1. Wrapping With the wrapping mechanism, the protection ring tunnel is a closed ring identified by the egress node. As shown in Figure 4, the RaP_D is the anticlockwise protection ring tunnel for the clockwise working ring tunnel RcW_D. As specified in the following sections, the closed ring protection tunnel can protect both the link failure and the node failure. 4.3.1.1. Wrapping for Link Failure When a link failure between Node B and Node C occurs, if it is a bi- directional failure, both Node B and Node C can detect the failure via OAM mechanism; if it is a uni-directional failure, one of the two nodes would detect the failure and it would inform the other node via the Ring Protection Switch Protocol (RPS) which is specified in section 5. Then 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 + C switches anticlockwise protection ring tunnel(RaP_D) back to the clockwise working ring tunnel(RcW_D). The data traffic which enters the ring at Node A and leaves the ring 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 leaves the ring). +---+#####[RaP_D(F)]######+---+ @@ -489,30 +525,30 @@ 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 LSP1) -> [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 LSP1). In one special case where node D fails, all the ring tunnels with node D as egress will become unusable. However, before the failure - location is propagated to all the ring nodes, the wrapping protection - mechanism may cause temporary traffic loop: node C detects the - failure and switches the traffic from the clockwise work ring tunnel - (RcW_D) to the anticlockwise protection ring tunnel (RaP_D), node E - also detects the failure and would switch the traffic from - anticlockwise protection ring tunnel (RaP_D) back to the clockwise - work ring tunnel (RcW_D). A possible mechanism to mitigate the - temporary loop problem is: the TTL of the ring tunnel label is set to - 2*N by the ingress ring node of the traffic, where N is the number of - nodes on the ring. + location information is propagated to all the ring nodes, the + wrapping protection mechanism may cause temporary traffic loop: node + C detects the failure and switches the traffic from the clockwise + work ring tunnel (RcW_D) to the anticlockwise protection ring tunnel + (RaP_D), node E also detects the failure and would switch the traffic + from anticlockwise protection ring tunnel (RaP_D) back to the + clockwise work ring tunnel (RcW_D). A possible mechanism to mitigate + the temporary loop problem is: the TTL of the ring tunnel label is + set to 2*N by the ingress ring node of the traffic, where N is the + number of nodes on the ring. +---+#####[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 @@ -523,54 +559,52 @@ LSP1 +-- | D |-------------------| C | +---+#####[RaP_D(C)]####+---+ -----physical links xxxxxx Failure Node *****RcW_D ###### RaP_D Figure 6. Wrapping for node failure 4.3.2. Short Wrapping - With the traditional wrapping protection scheme, Protection switching - is executed at both nodes detecting the failure, consequently the + With the traditional wrapping protection scheme, protection switching + is executed at both nodes adjacent to the failure, consequently the traffic will be wrapped twice. This mechanism will cause additional latency and bandwidth consumption when traffic is switched to the protection path. With short wrapping protection, data traffic switching is executed - only at the upstream node detecting the failure, and data traffic - leaves the ring in the protection ring tunnel at the egress node. - This scheme can reduce the additional latency and bandwidth - consumption when traffic is switched to the protection path. + only at the node upstream to the failure, and data traffic leaves the + ring in the protection ring tunnel at the egress node. This scheme + can reduce the additional latency and bandwidth consumption when + traffic is switched to the protection path. - In the traditional wrapping solution, the protection ring tunnel is a - closed ring in normal state, while in the short wrapping solution, + In the traditional wrapping solution, in normal state the protection + ring tunnel is a closed ring, while in the short wrapping solution, the protection ring tunnel is ended at the egress node, which is similar to the working ring tunnel. Short wrapping is easy to implement in shared ring protection because both the working and protection ring tunnels are terminated on the egress nodes. Figure 7 shows the clockwise working ring tunnel and the anticlockwise protection ring tunnel with node D as the egress node. 4.3.2.1. Short Wrapping for Link Failure As shown in Figure 7, in normal state, LSP1 is carried by the clockwise working ring tunnel (RcW_D) through the path A->B->C->D. When a link failure between Node B and Node C occurs, Node B switches The working ring tunnel RcW_D to the protection ring tunnel RaP_D in the opposite direction. The difference occurs in the protection ring tunnel at egress node. In short wrapping protection, Rap_D ends in Node D and then traffic will be forwarded based on the LSP labels. Thus with short wrapping mechanism, LSP1 will follow the path A->B->A->F->E->D when link failure between Node B and Node C happens. - For node failure, the protection with short wrapping is similar to - the mechanism with link failure. +---+#####[RaP_D(F)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ #/* *\# [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) #/* *\# +---+ +---+ | E | | B | +---+ +---+ @@ -581,42 +615,42 @@ LSP1 +-- | D |-------------------| C | +---+ +---+ ----- physical links xxxxx Failure Link ****** RcW_D ###### RaP_D Figure 7. Short wrapping for link failure 4.3.2.2. Short Wrapping for Node Failure - For the failure scenarios which happen on a non-egress node, short - wrapping protection switching is similar to the link failure as + For the node failure which happens on a non-egress node, short + wrapping protection switching is similar to the link failure case as described in the previous section. This section specifies the scenario of egress node failure. As shown in Figure 8, LSP1 enters the ring on node A, and leaves the - ring on node D. in normal state, LSP1 is carried by the clockwise + ring on node D. In normal state, LSP1 is carried by the clockwise working ring tunnel (RcW_D) through the path A->B->C->D. When node D fails, traffic of LSP1 cannot be protected by any ring tunnels which use node D as the egress node. However, before the failure location - is propagated to all the ring nodes, node C switches all the traffic - on the working ring tunnel RcW_D to the protection ring tunnel RaP_D - in the opposite direction. When the traffic arrives at node E which - also detects the failure of node D, the protection ring tunnel RaP_D - cannot be used to forward traffic to node D. Since with short - wrapping mechanism, protection switching can only be performed once - from the working ring tunnel to the protection ring tunnel, thus node - E MUST NOT switch the traffic which is already carried on the + information is propagated to all the ring nodes, node C switches all + the traffic on the working ring tunnel RcW_D to the protection ring + tunnel RaP_D in the opposite direction. When the traffic arrives at + node E which also detects the failure of node D, the protection ring + tunnel RaP_D cannot be used to forward traffic to node D. Since with + short wrapping mechanism, protection switching can only be performed + once from the working ring tunnel to the protection ring tunnel, thus + node E MUST NOT switch the traffic which is already carried on the protection ring tunnel back to the working ring tunnel in the opposite direction. Instead, node E will discard the traffic received on RaP_D locally. This can avoid the temporary traffic loop - when the faiulre happens on the egress node of the ring tunnel. This + when the failure happens on the egress node of the ring tunnel. This also illustrates one of the benefits of having separate working and protection ring tunnels in each ring direction. +---+#####[RaP_D(F)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ #/* *\# [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) #/* *\# +---+ +---+ @@ -629,36 +663,38 @@ LSP1 +-- x D x-------------------| C | xxxxx +---+ -----physical links xxxxxx Failure Node *****RcW_D ###### RaP_D Figure 8. Short Wrapping for egress node failure 4.3.3. Steering - In ring topology, each working ring tunnel is associated with a - protection ring tunnel in the opposite direction, and every node can - obtain the ring topology either by configuration or via some topology - discovery mechanism. The ring topology and the connectivity (Intact - or Severed) between the adjacent ring nodes form the ring map. Every - ring node maintains its ring map. When a failure occurs in the ring, - the nodes that detect the failure via OAM mechanism will transmit the - failure information in the opposite direction of the failure hop by - hop along the ring. When a node receives the message that identifies + With steering protection mechanism, the ingress node (which adds + traffic to the ring) perform switching from working to the protection + ring tunnel, and at the egress node the traffic leaves the ring from + the protection ring tunnel. + + When a failure occurs in the ring, the node which detects the failure + via OAM mechanism sends the failure information in the opposite + direction of the failure hop by hop along the ring using RPS request + message. When a ring node receives the RPS message which identifies a failure, it can quickly determine the location of the fault by using the topology information that is maintained by the node and - upate the ring map accordingly, then it can determine whether the + update the ring map accordingly, then it can determine whether the LSPs entering the ring locally need to switchover or not. For LSPs that needs to switchover, it will switch the LSPs from the working ring tunnels to its corresponding protection ring tunnels. +4.3.3.1. Steering for Link Failure + Ring map of F +--LSPl +-+-+-+-+-+-+-+ +---+ ###[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| +---+ +---+ +-- LSP2 @@ -675,23 +711,23 @@ +-+-+-+-+-+-+ +-+-+-+-+-+-+ ----- physical links ***** RcW_D ##### RaP_D I: Intact S: Severed Figure 9. Steering operation and protection switching As shown in Figure 9, 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. - In the normal state, LSP1 is carried by the clockwise working ring - tunnel (RcW_D) through the path A->B->C->D, the label operation is: - [LSP1] -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> + In normal state, LSP1 is carried by the clockwise working ring tunnel + (RcW_D) through the path A->B->C->D, the label operation is: [LSP1] + -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> [RcW_D(D)|LSP1](NodeC) -> [LSP1] (data traffic carried by LSP1) . LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught 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 LSP2) . If the link between nodes C and D fails, according to the fault detection and distribution mechanisms, Node D will find out that there is a failure in the link between C and D, and it will update @@ -708,40 +744,40 @@ When Node A receives the failure report message and updates the link state of its ring topology, it is aware that there is a fault on the clockwise working ring tunnel to node D (RcW_D), and LSP1 enters the ring locally and is carried by this ring tunnel, thus Node A will decide to switch the LSP1 onto the anticlockwise protection ring tunnel to node D (RaP_D). After the switchover, LSP1 will follow the path A->F->E->D, the label operation is: [LSP1] -> [RaP_D(F)| LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> [LSP1] (data traffic carried by LSP1). - The same also apply to the operation of LSP2. When Node B updates - the link state of its ring topology, and finds out that the working - ring tunnel RcW_D has failed, it will switch the LSP2 to the + The same procedure also applies to the operation of LSP2. When Node + B updates the link state of its ring topology, and finds out that the + working ring tunnel RcW_D has failed, it will switch the LSP2 to the anticlockwise protection tunnel RaP_D. After the switchover, LSP2 goes through the path B->A->F->E->D, and the label operation is: [LSP2] -> [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 LSP2). - Then assume the link between nodes A and B breaks down, as shown in + Assume the link between nodes A and B breaks down, as shown in Figure 10. Similar to the above failure case, Node B will detect 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 hop by hop in the - clockwise direction, notifying every node that there is a fault - between node A and B, and every node updates the link state of its - ring topology. As a result, Node A will detect a fault in the - working ring tunnel to node D, and switch LSP1 to the protection ring - tunnel, while Node B determine that the working ring tunnel for LSP2 - still works fine, and will not perform the switchover. + fault in the link between A and B, and it will update its ring map, + changing the link state between A and B from normal to fault. The + state report message is sent hop by hop in the clockwise direction, + notifying every node that there is a fault between node A and B, and + every node updates the link state of its ring topology. As a result, + Node A will detect a fault in the working ring tunnel to node D, and + switch LSP1 to the protection ring tunnel, while Node B determine + that the working ring tunnel for LSP2 still works fine, and will not + perform the switchover. /-- LSPl +-+-+-+-+-+-+-+ +---+ ###[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 +-- LSP2 +-+-+-+-+-+-+-+ +---+ +---++-+-+-+-+-+-+-+ @@ -753,34 +789,47 @@ +-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ |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 10. Steering operation and protection switching (2) +4.3.3.2. Steering for Node Failure + + For node failure which happens on a non-egress node, steering + protection switching is similar to the link failure case as described + in the previous section. + + If the failure occurs at the egress node of the LSP, since the + ingress node can update its ring map according to the received RPS + messages, it will determine that the egress node is not reachable + after the failure, thus it will not send traffic to either the + working or protection tunnel, and traffic loop can be avoided. + 4.4. Interconnected Ring Protection 4.4.1. Interconnected Ring Topology - Interconnected ring topology is often used in MPLS-TP networks. This - document will discuss two typical interconnected ring topologies: + Interconnected ring topology is widely used in MPLS-TP networks. + This document will discuss two typical interconnected ring + topologies: 1. Single-node interconnected rings In single-node interconnected rings, the connection between the two rings is through a single node. Because the interconnection node is in fact a single point of failure, this topology should be avoided in real transport networks. - Figure 10 shows the topology of single-node interconnected + Figure 11 shows the topology of single-node interconnected rings. Node C is the interconnection node between Ring1 and Ring2. 2. Dual-node interconnected rings In dual-node interconnected rings, the connection between the two rings is through two nodes. The two interconnection nodes belong to both interconnected rings. This topology can recover from one interconnection node failure. @@ -816,113 +865,108 @@ +---+ +---+ +---+ +---+ +---+ | F |------| E |------| D |------| J |------| I | +---+ +---+ +---+ +---+ +---+ Figure 12. Dual-node interconnected rings 4.4.2. Interconnected Ring Protection Mechanisms Interconnected rings can be treated as two independent rings. Ring protection switching (RPS) protocol operates on each ring - independently. Failure in one ring only triggers protection - switching on the ring itself and does not affect the other ring. - This way, protection switching on each ring is the same as the - mechanisms described in section 4.3. + independently. Failure happened on one ring only triggers protection + switching on the ring itself and does not affect the other ring, + unless the failure is on the interconnection node. This way, + protection switching on each ring is the same as the mechanisms + described in section 4.3. - The service LSPs that traverse the interconnected rings via the - interconnection nodes MUST use different ring tunnels in different - rings, and the service LSPs traversing the interconnected rings are + The service LSPs that traverse the interconnected rings use seperate + ring tunnels on each ring, and the LSPs on different rings are stitched by the interconnection node. On the interconnection node, - the ring tunnel label used in the source ring will be popped, the - service LSP label will be swapped, and the ring tunnel label of the - destination ring will be pushed. + the ring tunnel label of the source ring is popped, then LSP label is + swapped, after that the ring tunnel label of the destination ring is + pushed. In the dual-node interconnected ring scenario, the two - interconnection nodes can be managed as a virtual interconnection - node group. Each ring should assign working and protection ring - tunnels for the virtual interconnection node group. Both the - interconnection nodes in the virtual interconnection node group can - terminate the working ring tunnel of each ring. The protection ring - tunnel is used to protect the working ring tunnel of each ring and - can be terminated by any node in the virtual interconnection node - group. - - On the nodes in the virtual interconnection node group of the dual- - node interconnected ring, the same label is allocated for each - service LSP. This way any interconnection node in the virtual node - group can stitch the service LSPs between the source ring tunnel and - the destination ring tunnel. + interconnection nodes can be managed as a virtual node group. In + addition to the ring tunnels to each physical ring node, Each ring + SHOULD assign the working and protection ring tunnels to the virtual + interconnection node group. In addition, on both nodes in the + virtual interconnection node group, the same LSP label is assigned + for each traversed LSP. This way, any interconnection node in the + virtual node group can terminate the working or protection ring + tunnels targeted to the virtual node group, and stitch the service + LSP from the source ring tunnel to the destination ring tunnel. - 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 SHOULD also follow the clockwise - direction when the service leaves Ring1 and enters Ring2. + When the service LSP passes through the interconnected rings, the + direction of the working ring tunnels used on both rings SHOULD be + the same. For example, if the service LSP uses the clockwise working + ring tunnel on Ring1, when the service LSP leaves Ring1 and enters + Ring2, the working ring tunnel used on Ring2 SHOULD also follow the + clockwise direction. 4.4.3. Ring Tunnels in Interconnected Rings The same ring tunnels as described in section 4.1 are used in each - ring of the interconnected rings. Note that ring tunnels to the - virtual interconnection node group will be established by each ring - of the interconnected rings, i.e.: + ring of the interconnected rings. In addition, ring tunnels to the + virtual interconnection node group are established on each ring of + the interconnected rings, i.e.: o one clockwise working ring tunnel to the virtual interconnection node group o one anticlockwise protection ring tunnel to the virtual interconnection node group o one anticlockwise working ring tunnel to the virtual interconnection node group o one clockwise protection ring tunnel to the virtual interconnection node group - These ring tunnels will terminated at all nodes in the virtual + These ring tunnels will terminated at any node in the virtual interconnection node group. - For example, all the ring tunnels on Ring1 of Figure 12 are - established as follows: + For example, all the ring tunnels on Ring1 in Figure 13 are + provisioned as follows: o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F o 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 13 are - provisioned as follows: + All the ring tunnels on Ring2 in Figure 13 are provisioned as + follows: o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J o To the virtual interconnection node group(including Node F and - Node A): R2cW_FandA, R2aW_FandA, R2cP_FandA, R2aP_FandA + Node A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A +---+cccccccccccc +---+ | H |-------------| I |--->LSP1 +---+ +---+ c/a a\ c/a a\ c/a a\ +---+ +---+ | G | Ring2 | J | +---+ +---+ c\a a/c @@ -945,186 +989,173 @@ +---+ccccccccccccc+---+ ccccccccccc R1cW_F&A aaaaaaaaaaa R1aP_F&A ccccccccccc R2cW_I aaaaaaaaaaa R2aP_I Figure 13. Ring tunnels for the interconnected rings 4.4.4. Interconnected Ring Switching Procedure - As shown in Figure 13, 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 as below. + As shown in Figure 13, for the service 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 short wrapping protection + scheme is described as 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 normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. + At the interconnection node F, the label used for the working ring + tunnel R1cW_F&A in Ring1 is popped, the LSP label is swapped, and the + label used for the working ring tunnel R2cW_I in Ring2 will be pushed + based the inner LSP label lookup. The working path that the service + 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, Nodes F and E will detect the failure - and execute protection switching as described in 4.3.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. + link between Node F and Node E, Node E will detect the failure and + execute protection switching as described in 4.3.2. The path that + the service LSP1 follows after switching change to: LSP1->R1cW_F&A(D- + >E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. - In case of a non interconnection node failure, for example, when the - failure occurs at Node E in Ring1, Nodes F and D will detect the - failure and execute protection switching as described in 4.3.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 a non-interconnection node failure, for example, when the + failure occurs at Node E in Ring1, Node D will detect the failure and + execute protection switching as described in 4.3.2. The path that + the service LSP1 follows after switching becomes: + LSP1->R1cW_F&A(D)->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. In case of an interconnection node failure, for example, when the - failure occurs at the interconnection Node F. Nodes E and A in Ring1 - will detect the failure, and execute protection switching as - described in 4.3.1.2. Nodes 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. + failure occurs at the interconnection Node F. Node E in Ring1 will + detect the failure, and execute protection switching as described in + 4.3.2. Node A in Ring2 will also detect the failure, and execute + protection switching as described in 4.3.2. 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)->R2aP_I(A->J->I)->LSP1. 4.4.5. Interconnected Ring Detection Mechanism - As show in Figure 14, the service traffic LSP1 traverses A->B->C in - Ring1 and C->G->H->I in Ring2. Node C and Node D are the - interconnection nodes. When both the link between Node C and Node G - and the link between Node C and Node D fail, the ring tunnel from - Node C to Node I in Ring2 becomes unreachable. However, Node D is - still available, and LSP1 can still reach Node I. - - +---+ *********+---+**********+---+ +---+**********+---+ -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 14. Interconnected ring + As show in Figure 13, in normal state the service traffic LSP1 + traverses D->E->F in Ring1 and F->G->H->I in Ring2. Node A and F are + the interconnection nodes. When both the link between Node F and + Node G and the link between Node F and Node A fail, the ring tunnel + from Node F to Node I in Ring2 becomes unreachable. However, the + other interconnection node A is still available, and LSP1 can still + reach Node I via node A. In order to achieve this, the interconnection nodes need to know the ring topology of each ring so that they can judge whether a node is - reachable. This judgment is based on the knowledge of each ring - topology and the fault location as described in section 3.4. The - ring topology can be obtained from the NMS or topology discovery - mechanisms. The fault location can be obtained by transmitting the - fault information around the ring. The nodes that detect the failure - will transmit the fault information in the opposite direction node by - node in the ring. When the interconnection node receives the message + reachable. This judgment is based on the knowledge of ring map and + the fault location as described in section 3.4. The ring map can be + obtained from the NMS or topology discovery mechanisms. The fault + location can be obtained by transmitting the fault information around + the ring. The nodes that detect the failure will transmit the fault + information in the opposite direction hop by hop using the RPS + protocol message. When the interconnection node receives the message that informs the failure, it will quickly calculate the location of - the fault by the topology information that is maintained by itself - and determines whether the LSPs entering the ring at itself can reach - the destination. If the destination node is reachable, the LSP will - leave the source ring and enter the destination ring. If the - destination node is not reachable, the LSP will switch to the + the fault according to the topology information that is maintained by + itself and determines whether the LSPs entering the ring at itself + can reach the destination. If the destination node is reachable, the + LSP will leave 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. - In Figure 14, Node C determines that the ring tunnel to Node I is - unreachable, the service traffic LSP1 for which the destination node - on the ring tunnel is Node I should switch to the protection LSP - (R1aP_C&D) and consequently the service traffic LSP1 traverses the - interconnected rings at Node D. Node D will remove the ring tunnel - label of Ring1 and add the ring tunnel label of Ring2. + In Figure 13, Node F determines that the ring tunnel to Node I is + unreachable, the service LSP1 for which the destination node on the + ring2 is Node I MUST switch to the protection ring tunnel (R1aP_F&A) + and consequently the service traffic LSP1 traverses the + interconnected rings at Node A. Node A will pop the ring tunnel + label of Ring1 and push the ring tunnel label of Ring2 and send the + traffic to Node I via ring tunnel (R2aW_I). 5. Ring Protection Coordination Protocol + 5.1. RPS Protocol The MSRP protection operation MUST be controlled with the help of the Ring Protection Switch Protocol (RPS). The RPS processes in each of the individual ring nodes that form the ring SHOULD communicate using the G-ACh channel. The RPS protocol MUST carry the ring status information and RPS - requests, i.e., automatically initiated and externally initiated, + requests, either automatically initiated or externally initiated, between the ring nodes. Each node on the ring MUST be uniquely identified by assigning it a node ID. The node ID MUST be unique on each ring. 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. Every node obtains the ring topology either by configuration or via some topology discovery mechanism. The ring map consists of the ring topology information, and connectivity status (Intact or Severed) between the adjacent ring nodes, which is determined via the OAM - message exchange between the adjacent nodes. The ring map is used by - every ring node to determine the switchover behavoir of the ring + message exchanged between the adjacent nodes. The ring map is used + by every ring node to determine the switchover behavior of the ring tunnels. When no protection switching is 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 15. RPS communication between the ring nodes in case of - no failures in the ring + Figure 14. RPS communication between the ring nodes in case of + no failure 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 in the same direction 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 16. RPS communication between the ring nodes in case of + 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, the two adjacent nodes detect the failure and send each other an RPS request in opposite directions. o In rings utilizing the wrapping protection. When the destination node receives the RPS request it MUST perform the switch from/to the working ring tunnels to/from the protection ring tunnels if it has no higher priority active RPS request. + o In rings utilizing the short wrapping protection. Only the node + which is directly upstream to the failure on the working ring + tunnel perform the switch from the working ring tunnels to the + protection ring tunnels. This may be triggered by local failure + detection or the received RPS request. + o In rings utilizing the steering protection. When a ring switch is required, any node MUST perform the switches if its added/dropped traffic is affected by the failure. Determination of the affected traffic SHOULD be performed by examining the RPS requests (indicating the nodes adjacent to the failure or failures) and the stored ring maps (indicating the relative position of the failure and the added traffic destined towards that failure). When the failure has cleared and the Wait-to-Restore (WTR) timer has expired, the nodes sourcing RPS requests MUST drop their respective switches (tail end) and MUST source an RPS request carrying the 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 + specified in Section 5.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 an RPS request MUST be generated, the former protection switch MUST be dropped, and the latter protection switch established. MSRP mechanism SHOULD support multiple protection switches in the @@ -1157,21 +1188,21 @@ an RPS message. The ACH MUST NOT include the ACH TLV Header [RFC5586] meaning that no ACH TLVs can be included in the message. 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 17. G-ACh RPS Packet Format + Figure 16. G-ACh RPS Packet Format The following fields MUST be provided: o Destination Node ID: The destination node ID MUST always be set to value of the node ID of the adjacent node. The Node ID MUST be unique on each ring. Valid destination node ID values are 1-127. o Source node ID: The source node ID MUST always be set to the ID value of the node generating the RPS request. The Node ID MUST be unique on each ring. Valid source node ID values are 1-127. @@ -1207,21 +1238,21 @@ 5.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. + ring tunnels in both directions. 5.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. @@ -1270,21 +1301,21 @@ flow on protection ring tunnels in both directions. 5.1.4. RPS State Transitions All state transitions are triggered by an incoming RPS request change, a WTR expiration, an externally initiated command, or locally detected MPLS-TP section failure conditions. RPS requests due to a locally detected failure, an externally initiated command, or received RPS request shall pre-empt existing - RPS requests in the prioritized order given in Section 3.1.2, unless + RPS requests in the prioritized order given in Section 5.1.2, unless the requests are allowed to coexist. 5.1.4.1. Transitions Between Idle and Pass-through States The transition from the idle state to pass-through state MUST be triggered by a valid RPS request change, in any direction, from the NR code to any other code, as long as the new request is not destined to the node itself. Both directions move then into a pass-through state, so that, traffic entering the node through the protection Ring tunnels are transferred transparently through the node. @@ -1367,21 +1398,99 @@ externally initiated command o The detection of an equal priority, a higher priority, or an allowed coexisting automatic initiated command o The receipt of an equal, a higher priority, or an allowed coexisting RPS request destined to this node 5.2. RPS State Machine -5.2.1. Initial States +5.2.1. Switch Initiation Criteria + +5.2.1.1. Administrative Commands + + Administrative commands can be initiated by the network operator + through the Network Management System (NMS). The operator command + may be transmitted to the appropriate node via the MPLS-TP RPS + message. + + The following commands can be transferred by the RPS message: + + o Lockout of Protection (LP): This command prevents any protection + activity and prevents using ring switches anywhere in the ring. + If any ring switches exist in the ring, this command causes the + switches to drop. + + o Forced Switch to protection (FS): This command performs the ring + switch of normal traffic from the working entity to the protection + entity for the span between the node at which the command is + initiated and the adjacent node to which the command is directed. + This switch occurs regardless of the state of the MPLS-TP section + for the requested span, unless a higher priority switch request + exists. + + o Manual Switch to protection (MS): This command performs the ring + switch of the normal traffic from the working entity to the + protection entity for the span between the node at which the + command is initiated and the adjacent node to which the command is + directed. This occurs if the MPLS-TP section for the requested + span is not satisfying an equal or higher priority switch request. + + o Exercise - Ring (EXER): This command exercises ring protection + switching on the addressed span without completing the actual + switch. The command is issued and the responses (RR) are checked, + but no normal traffic is affected. + + The following commands are not transferred by the RPS message: + + o Clear: This command clears the administrative command and Wait-To- + Restore timer (WTR) at the node to which the command was + addressed. The node-to-node signaling after the removal of the + externally initiated commands is performed using the no-request + code (NR). + + o Lockout of Working: This command prevents the normal traffic + transported over the addressed span from being switched to the + protection entity by disabling the node's capability of requesting + switch for this span in case of failure. If any normal traffic is + already switched on the protection entity, the switch is dropped. + If no other switch requests are active on the ring, the no-request + code (NR) is transmitted. This command has no impact on any other + span. If the node receives the switch request from the adjacent + node from any side it will perform the requested switch. If the + node receives the switch request addressed to the other node, it + will enter the pass-through state. + +5.2.1.2. Automatically Initiated Commands + + Automatically initiated commands can be initiated based on MPLS-TP + section layer OAM indication and the received switch requests. + + The node can initiate the following switch requests automatically: + + o Signal Fail (SF): This command is issued when the MPLS-TP section + layer OAM detects signal failure condition. + + o Wait-To-Restore (WTR): This command is issued when MPLS-TP section + detects that the SF condition has cleared. It is used to maintain + the state during the WTR period unless it is pre-empted by a + higher priority switch request. The WTR time may be configured by + the operator in 1 minute steps between 0 and 12 minutes; the + default value is 5 minutes. + + o Reverse Request (RR): This command is transmitted to the source + node of the received RPS message over the short path as an + acknowledgment for receiving the switch request. + +5.2.2. Initial States + +-----------------------------------+----------------+ | State | Signaled RPS | +-----------------------------------+----------------+ | A | Idle | NR | | | Working: no switch | | | | Protection: no switch | | +-----+-----------------------------+----------------+ | B | Pass-trough | N/A | | | Working: no switch | | | | Protection: pass through | | @@ -1408,21 +1517,21 @@ +-----+-----------------------------+----------------+ | H | Switching - WTR | WTR | | | Working: switched | | | | Protection: switched | | +-----+-----------------------------+----------------+ | I | Switching - EXER | EXER | | | Working: no switch | | | | Protection: no switch | | +-----+-----------------------------+----------------+ -5.2.2. State transitions When Local Request is Applied +5.2.3. 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 ------------- ----------- --------- A (Idle) LP C (Switching - LP) LW D (Idle - LW) FS E (Switching - FS) @@ -1567,21 +1677,21 @@ FS E (Switching - FS) SF F (Switching - SF) Recover from SF N/A MS G (Switching - MS) Clear A WTR expires N/A EXER N/A - if on the same span I (Switching - EXER) ===================================================================== -5.2.3. State Transitions When Remote Request is Applied +5.2.4. State Transitions When Remote Request is Applied The priority of a 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) @@ -1699,21 +1808,21 @@ 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 ===================================================================== -5.2.4. State Transitions When Request Addresses to Another Node is +5.2.5. State Transitions When Request Addresses to Another Node is Received The priority of a remote request does not depend on the side from which the request is received. ===================================================================== Initial state New request New state ------------- ----------- --------- A (Idle) LP B (Pass-trough) FS B (Pass-trough)