--- 1/draft-ietf-mpls-tp-shared-ring-protection-03.txt 2016-12-13 05:13:15.672806540 -0800 +++ 2/draft-ietf-mpls-tp-shared-ring-protection-04.txt 2016-12-13 05:13:15.776809118 -0800 @@ -1,23 +1,23 @@ Network Working Group W. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li -Expires: April 2, 2017 China Mobile +Expires: June 16, 2017 China Mobile H. Helvoort Hai Gaoming BV J. Dong Huawei Technologies - September 29, 2016 + December 13, 2016 Shared-Ring protection (MSRP) mechanism for ring topology - draft-ietf-mpls-tp-shared-ring-protection-03 + draft-ietf-mpls-tp-shared-ring-protection-04 Abstract This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switch (RPS) Protocol that is used to coordinate the protection behavior of the nodes on MPLS ring. @@ -35,21 +35,21 @@ 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 2, 2017. + This Internet-Draft will expire on June 16, 2017. Copyright Notice 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 @@ -113,38 +113,38 @@ level survivability function in these topologies. In operational transport network deployment, MPLS-TP networks are often constructed using ring topologies. This calls for an efficient and optimized ring protection mechanism to achieve simple operation and fast, sub 50 ms, recovery performance. This document specifies an MPLS-TP Shared-Ring Protection mechanisms that meets the criteria for ring protection and the ring protection requirements described in section 2.5.6.1 of [RFC5654]. - The basic concept and architecture of Shared-Ring protection + The basic concept and architecture of the Shared-Ring protection mechanism are specified in this document. This document describes the solutions for point-to-point transport paths. While the basic concept may also apply to point-to-multipoint transport paths, the solution for point-to-multipoint transport paths is out of the scope of this document. 2. Terminology and Notation Terminology: - Ring Node: A ring node is a node in the ring topology that actively - participates in the ring protection. + Ring Node: All nodes in the ring topology are Ring Nodes and they + MUST actively participate in the ring protection. Ring tunnel: A ring tunnel provides a server layer for the LSPs - traverse the ring. The notation for ring tunnel is: xxxx R

_ - where = c (clockwise) or a (anticlockwise),

= W (working) or - P (protecting), and the node name. + traversing the ring. The notation used for a ring tunnel is: + R

where = c (clockwise) or a (anticlockwise),

= W + (working) or P (protecting), and = the node name. Ring map: A ring map is present in each ring-node. The ring-map contains the ring topology information, i.e. the nodes in the ring, the adjacency of the ring-nodes and the status of the links between ring-nodes (Intact or Severed) and for each protected LSP at which node it enters and leaves the ring. The ring map is used by every ring node to determine the switchover behavior of the ring tunnels. Notation: @@ -152,21 +152,21 @@ 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 is enclosed in - bracket ("()") + parentheses ("()"). 3. MPLS-TP Ring Protection Criteria and Requirements The generic requirements for MPLS-TP protection are specified in [RFC5654]. The requirements specific for ring protection are specified in section 2.5.6.1 of [RFC5654]. This section describes how the criteria for ring protection are met: a. The number of OAM entities needed to trigger protection @@ -179,21 +179,21 @@ Each ring-node requires only one instance of the RPS protocol and is independent of the number of LSPs that are protected. c. The required number of labels required for the protection paths The RPS protocol uses ring tunnels and each tunnel has a set of labels. The number of ring tunnel labels is related to the number of ring-nodes and is independent of the number of protected LSPs. d. The amount of control and management-plane transactions - Each ring-node requires only one instance of the RPS protocol this + Each ring-node requires only one instance of the RPS protocol. This means that only one maintenance operation is required per ring-node. e. Minimize the signaling and routing information exchange during protection Information exchange during a protection switch is using the in-band RPS and OAM messages. No control plane interactions are required. 4. Shared Ring Protection Architecture @@ -249,23 +249,22 @@ 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. + The structure of the protection tunnels is 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 @@ -325,24 +324,24 @@ the next hop. The transit nodes on the working ring tunnel swap the ring tunnel labels and forward the packets to the next hop. When the packet arrives 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 the MPLS-TP shared ring protection mechanism. Assume that LSP1 enters the ring at Node A and exits from Node D, and the following label operations are executed. 1. Ingress node: Packets of LSP1 arrive 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]. + [LSP1] and are 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. Egress node: When the packet arrives at Node D (i.e. the egress node) with label stack [RcW_D(D)|LSP1], Node D pops RcW_D(D), and subsequently deals with the inner labels of LSP1. @@ -389,31 +388,33 @@ general, the description uses the clockwise working ring tunnel and the corresponding anti-clockwise protection ring tunnel as an example, but the mechanism is applicable in the same way to the anti- clockwise working and clockwise protection ring tunnels. In a ring network, each working ring tunnel is associated with a protection ring tunnel in the opposite direction, and every node MUST obtain the ring topology either by configuration or via a topology discovery mechanism. The ring topology and the connectivity (Intact or Severed) between two adjacent ring nodes form the ring map. Each - ring node maintains the ring map and use it to perform ring - protection. + ring node maintains the ring map and uses it to perform ring + protection switching. Taking the topology in Figure 4 as an example, LSP1 enters the ring at Node A and leaves the ring at Node D. 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](Payload) -> [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB) - -> [RCW_D(D)| LSP1](NodeC) -> [LSP1](Payload). Then at node D the - packet will be forwarded based on the label stack of LSP1. + -> [RCW_D(D)| LSP1](NodeC) -> [LSP1](Payload). + + Then at node D the packet will be forwarded based on the label stack + of LSP1. Three typical ring protection mechanisms are described in this section: wrapping, short wrapping and steering. All nodes on the same ring MUST use the same protection mechanism. Wrapping ring protection: the node which detects a failure or accepts a switch request switches the traffic impacted by the failure or the switch request 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 of the failure, then travels @@ -424,26 +425,26 @@ 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 of the traffic from working to the protection ring + impacted traffic, the ingress node (which adds traffic to the ring) + performs switching of the traffic from working to the protection ring tunnel, and the egress node will drop the traffic received from the protection ring tunnel. - The following sections describes these protection mechanisms in + The following sections describe 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 link failures and node failures. @@ -453,22 +454,22 @@ 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 the OAM mechanism; if it is a uni-directional failure, one of the two nodes would detect the failure via the OAM mechanism. In both cases the node at the other side of the detected failure will be determined by the ring-map and informed using 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) 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 + working ring tunnel (RcW_D). The payload 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](Payload) -> [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](Payload). +---+#####[RaP_D(F)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ @@ -494,21 +495,21 @@ As shown in Figure 6, 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 node at the other side of the failed node will be determined by the ring-map and informed using the Ring Protection Switch Protocol (RPS) specified in section 5. - The data traffic which enters the ring at Node A and exits at Node D + The payload 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](Payload)-> [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](Payload). 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 information is propagated to all the ring nodes, the wrapping protection mechanism may cause temporary traffic loop: node @@ -543,48 +544,49 @@ Figure 6. Wrapping for node failure 4.3.2. Short Wrapping With the 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 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. + With short wrapping protection, payload switching is executed only at + the node upstream to the failure, and payload 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 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. + protection ring tunnel is terminated 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 with wrapping 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. The protection switch at node D is based on the information - from its ring map and the information received via the RPS protocol. + protection ring tunnel at the 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 the short wrapping mechanism, + LSP1 will follow the path A->B->A->F->E->D when a link failure + between Node B and Node C happens. The protection switch at node D + is based on the information from its ring map and the information + received via the RPS protocol. +---+#####[RaP_D(F)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ #/* *\# [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) #/* *\# +---+ +---+ | E | | B | +---+ +---+ @@ -595,24 +597,24 @@ 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 node failure which happens on a non-egress node, short + For the node failure which happens on a non-egress node, the 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. + scenario of an 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 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 information is propagated to all the ring nodes using the RPS protocol, node C switches all the traffic on the working ring tunnel RcW_D to the protection ring tunnel RaP_D in the opposite direction based on the information in the ring map. When the traffic arrives @@ -644,37 +646,37 @@ 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 - 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. + With the steering protection mechanism, the ingress node (which adds + traffic to the ring) perform switching from the 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 and the ring-map information. When a ring node receives the - RPS message which identifies a failure, it can determine the location - of the fault by using the topology information of the ring map and - update the ring map accordingly, then it can determine whether the - LSPs entering the ring locally need to switchover or not. For LSPs - that need to switchover, it will switch the LSPs from the working - ring tunnels to its corresponding protection ring tunnels. The - transfer of the failure information by the RPS protocol will increase - the protection switch time. + using the OAM mechanism sends the failure information in the opposite + direction of the failure hop by hop along the ring using an RPS + request message and the ring-map information. When a ring node + receives the RPS message which identifies a failure, it can determine + the location of the fault by using the topology information of the + ring map and updates the ring map accordingly, then it can determine + whether the LSPs entering the ring locally need to switchover or not. + For LSPs that need to switchover, it will switch the LSPs from the + working ring tunnels to their corresponding protection ring tunnels. + The transfer of the failure information by the RPS protocol will + increase the protection switch time. 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)] @@ -699,29 +701,29 @@ 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 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](Payload) -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> [RcW_D(D)|LSP1](NodeC) -> [LSP1](Payload) . - LSP2 is carried by the clockwise working ring tunnel (RcW_D) throught + LSP2 is carried by the clockwise working ring tunnel (RcW_D) through the path B->C->D, the label operation is: [LSP2](Payload) -> [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](Payload) . 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 the link state of its ring topology, changing the link between C and - D from normal to fault. In the direction that opposite to the + D from normal to fault. In the direction that is opposite to the failure position, 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 accordingly, changing the link between C and D from normal to fault. In this way, the state report message is sent hop by hop in the clockwise direction. Similar to Node D, Node C will send the failure information in the anti- clockwise direction. When Node A receives the failure report message and updates the link state of its ring map, it is aware that there is a fault on the @@ -773,29 +775,29 @@ +-+-+-+-+-+-+-+ +-- | 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 + For a 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. + If the failure occurs at the egress node of the LSP, the ingress node + will update its ring map according to the received RPS messages, it + will also determine that the egress node is not reachable after the + failure, thus it will not send traffic to either the working or the + protection tunnel, and a traffic loop can be avoided. 4.4. Interconnected Ring Protection 4.4.1. Interconnected Ring Topology Interconnected ring topology is widely used in MPLS-TP networks. This document will discuss two typical interconnected ring topologies: 1. Single-node interconnected rings @@ -996,52 +998,52 @@ 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, 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. Node E in Ring1 will + 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 13, in normal state the service traffic LSP1 + As shown 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 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 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 + the fault location. 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 calculate the location of 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 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). @@ -1084,21 +1086,21 @@ both directions. +---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR) -------| A |-------------| B |-------------| C |------- (NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+ Figure 14. RPS communication between the ring nodes in case of no 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 + identified a failed link. 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 15. RPS communication between the ring nodes in case of @@ -1123,45 +1125,44 @@ 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 map (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. + code. The node receiving from both directions such an RPS request + (head end) MUST drop its protection switches. A protection switch MUST be initiated by one of the criteria 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 + switch request on the given link, and another protection switch is + required due to a failure on another link. 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 - ring, resulting the ring being segmented into two or more separate + ring, resulting in the ring being segmented into two or more separate segments. This may happen when several RPS requests of the same priority exist in the ring due to multiple failures or external switch commands. - Proper operation of the MSRP mechanism relies on all nodes having - knowledge of the state of the ring (nodes and spans) so that nodes do - not preempt existing RPS request unless they have a higher-priority - RPS request. In order to accommodate ring state knowledge, during a - protection switch the RPS requests MUST be sent in both directions. + Proper operation of the MSRP mechanism relies on all nodes using + their ring map to determine the state of the ring (nodes and links). + In order to accommodate ring state knowledge, during a protection + switch the RPS requests MUST be sent in both directions. 5.1.1. Transmission and Acceptance of RPS Requests A new RPS request MUST be transmitted immediately when a change in the transmitted status occurs. The first three RPS protocol messages carrying new RPS request SHOULD be transmitted as fast as possible. For fast protection switching within 50 ms, the interval of the first three RPS protocol messages SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted @@ -1189,32 +1190,32 @@ 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. o Protection Switching Mode (M): This 2-bit field indicates the - protection swithcing mode used by the sending node of the RPS + protection switching mode used by the sending node of the RPS message. This can be used to check that the ring nodes on the - same ring use the same protecion switching mechanism. The defined - values of the M field are listed as below: + sane ring use the same protection switching mechanism. The + defined values of the M field are listed as below: +------------------+-----------------------------+ | Bits (MSB-LSB) | Protecton Switching Mode | +------------------+-----------------------------+ - | 0 0 | Wrapping | - | 0 1 | Short Wrapping | - | 1 0 | Steering | - | 1 1 | Reserved | + | 0 0 | Reserved | + | 0 1 | Wrapping | + | 1 0 | Short Wrapping | + | 1 1 | Steering | +------------------+-----------------------------+ o RPS request code: A code consisting of eight bits as specified below: +------------------+-----------------------------+----------+ | Bits | Condition, State | Priority | | (MSB - LSB) | or external Request | | +------------------+-----------------------------+----------+ | 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest | @@ -1245,64 +1246,65 @@ 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 ring tunnels in both directions. 5.1.3.2. Switching State - A node in the switching state MUST source RPS request to adjacent + A node in the switching state MUST source RPS request to its adjacent node with its highest RPS request code in both directions when it detects a failure or receives an external command. A node in the switching state MUST terminate RPS requests flow in both directions. As soon as it receives an RPS request from the short path, the node to which it is addressed MUST acknowledge the RPS request by replying with the RR code on the short path, and with the received RPS request code on the long path. Accordingly, if RR code is received from the short path, then the RPS request sent by the same node over the long path SHOULD be ignored. Here the short path refers to the shorter - span on the ring between the source and destination node of the RPS - request, and the long path refers to the longer span on the ring + path on the ring between the source and destination node of the RPS + request, and the long path refers to the longer path on the ring between the source and destination node of the RPS request. This rule refers to the unidirectional failure detection: the RR SHOULD be issued only when the node does not detect the failure condition (i.e., the node is a head end), that is, it is not applicable when a bidirectional failure is detected, because, in this case, both nodes adjacent to the failure will send an RPS request for the failure on both paths (short and long). The following switches MUST be allowed to coexist: o LP and LP o FS and FS o SF and SF o FS and SF - When multiple MS RPS requests over different spans exist at the same - time, no switch SHOULD be executed and existing switches MUST be - dropped. The nodes MUST signal, anyway, the MS RPS request code. + When multiple MS RPS requests exist at the same time addressing + different links and there is no higher priority request on the ring, + no switch SHOULD be executed and existing switches MUST be dropped. + The nodes MUST signal, anyway, the MS RPS request code. Multiple EXER requests MUST be allowed to coexist in the ring. A node in a ring switching state that receives the external command - LP for the affected span MUST drop its switch and MUST signal NR for - the locked span if there is no other RPS request on another span. - Node still SHOULD signal relevant RPS request for another span. + LP for the affected link MUST drop its switch and MUST signal NR for + the locked link if there is no other RPS request on another link. + The node still SHOULD signal relevant RPS request for another link. 5.1.3.3. Pass-through State When a node is in a pass-through state, it MUST transfer the received RPS Request in the same direction. When a node is in a pass-through state, it MUST enable the traffic flow on protection ring tunnels in both directions. 5.1.4. RPS State Transitions @@ -1334,21 +1336,21 @@ Transition of a node from the idle state to the switching state MUST be triggered by one of the following conditions: o A valid RPS request change from the NR code to any code received on either the long or the short path and destined to this node o An externally initiated command for this node o The detection of an MPLS-TP section layer failure at this node - Actions taken at a node in the idle state upon transition to + Actions taken at a node in the idle state upon transition to the switching state are: o For all protection switch requests, except EXER and LP, the node MUST execute the switch o For EXER, and LP, the node MUST signal appropriate request but not execute the switch A node MUST revert from the switching state to the idle state when it detects NR codes received from both directions. @@ -1360,21 +1362,21 @@ o At the head end: Upon reception of the NR code, from both directions, the head-end node MUST drop its switch, transition to Idle State and signal the NR code in both directions. 5.1.4.3. Transitions Between Switching States When a node that is currently executing any protection switch receives a higher priority RPS request (due to a locally detected failure, an externally initiated command, or a ring protection switch - request destined to it) for the same span, it MUST update the + request destined to it) for the same link, it MUST update the priority of the switch it is executing to the priority of the received RPS request. When a failure condition clears at a node, the node MUST enter WTR condition and remain in it for the appropriate time-out interval, unless: o A different RPS request with a higher priority than WTR is received @@ -1385,21 +1387,21 @@ The node MUST send out a WTR code on both the long and short paths. When a node that is executing a switch in response to incoming SF RPS request (not due to a locally detected failure) receives a WTR code (unidirectional failure case), it MUST send out RR code on the short path and the WTR on the long path. 5.1.4.4. Transitions Between Switching and Pass-through States When a node that is currently executing a switch receives an RPS - request for a non-adjacent span of higher priority than the switch it + request for a non-adjacent link of higher priority than the switch it is executing, it MUST drop its switch immediately and enter the pass- through state. The transition of a node from pass-through to switching state MUST be triggered by: o An equal priority, a higher priority, or an allowed coexisting externally initiated command o The detection of an equal priority, a higher priority, or an @@ -1421,54 +1423,54 @@ 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 + entity for the link 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 + for the requested link, 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 + protection entity for the link 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. + link 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 + switching on the addressed link 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 + transported over the addressed link 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 + switch for this link 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 + link. 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: @@ -1578,91 +1580,91 @@ F (Switching - SF) - if there is a failure at this node B (Pass-through) - if there is a failure at another node WTR expires N/A EXER O ===================================================================== Initial state New request New state ------------- ----------- --------- D (Idle - LW) LP C (Switching - LP) - LW N/A - if on the same span + LW N/A - if on the same link D (Idle - LW) - if on another - span - FS O - if on the same span + link + FS O - if on the same link E (Switching - FS) - if on - another span - SF O - if on the addressed span + another link + SF O - if on the addressed link F (Switching - SF) - if on - another span + another link Recover from SF N/A - MS O - if on the same span + MS O - if on the same link G (Switching - MS) - if on - another span + another link Clear A (Idle) - if there is no - failure on addressed span + failure on addressed link F (Switching - SF) - if there - is a failure on this span + is a failure on this link WTR expires N/A EXER O ===================================================================== Initial state New request New state ------------- ----------- --------- E (Switching - FS) LP C (Switching - LP) - LW O - if on another span + LW O - if on another link D (Idle - LW) - if on the same - span - FS N/A - if on the same span + link + FS N/A - if on the same link E (Switching - FS) - if on - another span - SF O - if on the addressed span + another link + SF O - if on the addressed link E (Switching - FS) - if on - another span + another link Recover from SF N/A MS O Clear A (Idle) - if there is no failure in the ring F (Switching - SF) - if there is a failure at this node B (Pass-through) - if there is a failure at another node WTR expires N/A EXER O ===================================================================== Initial state New request New state ------------- ----------- --------- F (Switching - SF) LP C (Switching - LP) - LW O - if on another span + LW O - if on another link D (Idle - LW) - if on the same - span + link FS E (Switching - FS) - SF N/A - if on the same span + SF N/A - if on the same link F (Switching - SF) - if on - another span + another link Recover from SF H (Switching - WTR) MS O Clear N/A WTR expires N/A EXER O ===================================================================== Initial state New request New state ------------- ----------- --------- G (Switching - MS) LP C (Switching - LP) - LW O - if on another span + LW O - if on another link D (Idle - LW) - if on the same - span + link FS E (Switching - FS) SF F (Switching - SF) Recover from SF N/A - MS N/A - if on the same span + MS N/A - if on the same link G (Switching - MS) - if on - another span release the + another link release the switches but signal MS Clear A WTR expires N/A EXER O ===================================================================== Initial state New request New state ------------- ----------- --------- H (Switching - WTR) LP C (Switching - LP) LW D (Idle - W) FS E (Switching - FS) @@ -1676,21 +1678,21 @@ Initial state New request New state ------------- ----------- --------- I (Switching - EXER) LP C (Switching - LP) LW D (idle - W) FS E (Switching - FS) SF F (Switching - SF) Recover from SF N/A MS G (Switching - MS) Clear A WTR expires N/A - EXER N/A - if on the same span + EXER N/A - if on the same link I (Switching - EXER) ===================================================================== 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 @@ -1955,21 +1957,21 @@ ===================================================================== 5.3. RPS and PSC Comparison on Ring Topology This section provides comparison between RPS and PSC [RFC6378] [RFC6974] on ring topologies. This can be helpful to explain the reason of defining a new protocol for ring protection switching. The PSC protocol [RFC6378] is designed for point-to-point LSPs, on which the protection switching can only be performed on one or both - of the end points of the LSP. While RPS is designed for ring + of the end points of the LSP. The RPS protocol is designed for ring tunnels, which consist of multiple ring nodes, and the failure could happen on any segment of the ring, thus RPS SHOULD be capable of identifying and handling the different failures on the ring, and coordinating the protection switching behavior of all the nodes on the ring. As specified in section 5, this is achieved with the introduction of the "Pass-Through" state for the ring nodes, and the location of the protection request is identified via the Node IDs in the RPS Request message. Taking a ring topology with N nodes as example: @@ -1998,21 +2000,21 @@ IANA is requested to administer the assignment of new values defined in this document and listed in the sections below. 6.1. G-ACh Channel Type The Channel Types for the Generic Associated channel (GACh) are allocated from the IANA PW Associated Channel Type registry defined in [RFC4446] and updated by [RFC5586]. - IANA is requested to allocate a new GACH Channel Type as follows: + IANA is requested to allocate a new GACh Channel Type as follows: Value| Description | Reference ------+---------------------------+-------------- TBD | Ring Protection Switching |this document | Protocol (RPS) | ------+---------------------------+-------------- 6.2. RPS Request Codes IANA is requested to create a new sub-registry under the