--- 1/draft-ietf-mpls-tp-shared-ring-protection-02.txt 2016-10-01 07:16:36.273810965 -0700 +++ 2/draft-ietf-mpls-tp-shared-ring-protection-03.txt 2016-10-01 07:16:36.381813696 -0700 @@ -1,41 +1,32 @@ Network Working Group W. Cheng Internet-Draft L. Wang Intended status: Standards Track H. Li -Expires: December 17, 2016 China Mobile +Expires: April 2, 2017 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. - June 15, 2016 + September 29, 2016 - MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology - draft-ietf-mpls-tp-shared-ring-protection-02 + Shared-Ring protection (MSRP) mechanism for ring topology + draft-ietf-mpls-tp-shared-ring-protection-03 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. + 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. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -44,242 +35,223 @@ 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 December 17, 2016. + This Internet-Draft will expire on April 2, 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 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 5 - 2.3. Configuration Complexity . . . . . . . . . . . . . . . . 5 - 3. Terminology and Notation . . . . . . . . . . . . . . . . . . 5 + 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 + 3. MPLS-TP Ring Protection Criteria and Requirements . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 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 + 4.1.2. Label Assignment and Distribution . . . . . . . . . . 7 + 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 7 + 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 9 + 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 . . . . . . 19 + 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 + 5.1. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 23 + 5.1.1. Transmission and Acceptance of RPS Requests . . . . . 25 + 5.1.2. RPS PDU Format . . . . . . . . . . . . . . . . . . . 25 5.1.3. Ring Node RPS States . . . . . . . . . . . . . . . . 27 5.1.4. RPS State Transitions . . . . . . . . . . . . . . . . 29 5.2. RPS State Machine . . . . . . . . . . . . . . . . . . . . 31 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.2. Initial States . . . . . . . . . . . . . . . . . . . 32 + 5.2.3. State transitions When Local Request is Applied . . . 33 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 + 5.3. RPS and PSC Comparison on Ring Topology . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 - 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 44 - 6.2. RSP Request Codes . . . . . . . . . . . . . . . . . . . . 44 + 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 43 + 6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 44 7. Security Considerations . . . . . . . . . . . . . . . . . . . 44 - 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 + 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 44 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 45 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 1. Introduction - As described in section 2.5.6.1 of [RFC5654], Ring Protection of - MPLS-TP requirements, several service providers have expressed much + As described in [RFC5654], MPLS-TP requirements, section 2.5.6.1, + Ring Protection, 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 performance. - - The requirements for MPLS-TP [RFC5654] state that recovery mechanisms - which are optimized for ring topologies could be further developed if - it can provide the following features: - - a. Minimize the number of OAM entities for protection + using ring topologies. This calls for an efficient and optimized + ring protection mechanism to achieve simple operation and fast, sub + 50 ms, recovery performance. - b. Minimize the number of elements of recovery + 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]. - c. Minimize the required label number + The basic concept and architecture of 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. - d. Minimize the amount of control and management-plane transactions - during maintenance operation +2. Terminology and Notation - e. Minimize the impact on information exchange during protection if - a control plane is supported + Terminology: - This document specifies MPLS-TP Shared-Ring Protection mechanisms - that can meet all those requirements on ring protection listed in - [RFC5654]. + Ring Node: A ring node is a node in the ring topology that actively + participates in the ring protection. - The basic concepts and architecture of Shared-Ring protection - mechanism are specified in this document. This document focuses on - the solutions for point-to-point transport paths. While the basic - concepts may also apply to point-to-multipoint transport paths, the - solution for point-to-multipoint transport paths is under study and - will be presented in a separate document. + 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. -2. Requirements for MPLS-TP Ring Protection + 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. - The requirements for MPLS-TP ring protection are specified in - [RFC5654]. This document elaborates on the requirements in detail. + Notation: -2.1. Recovery of Multiple Failures + The following syntax will be used to describe the contents of the + label stack: - MPLS-TP is expected to be used in carrier grade metro networks and - backbone transport networks to provide mobile backhaul, business - services etc., in which the network survivability is very important. - According to R106 B in [RFC5654], MPLS-TP recovery mechanisms in a - ring SHOULD protect against multiple failures. The following text - provides some more detailed illustration about "multiple failures". - In metro and backbone networks, a single risk factor often affects - multiple links or nodes. Some examples of risk factors are given as - follows: + 1. The label stack will be enclosed in square brackets ("[]"). - o multiple links use fibers in one cable or pipeline + 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. - o Several nodes share one power supply system + 3. If the Label is assigned by Node X, the Node Name is enclosed in + bracket ("()") - o Weather sensitive micro-wave system +3. MPLS-TP Ring Protection Criteria and Requirements - Once one of the above risk factors happens, multiple links or nodes - failures may occur simultaneously and those failed links or nodes may - be located on a single ring as well as on interconnected rings. Ring - protection against multiple failures should cover both multiple - failures on a single ring and multiple failures on interconnected - rings, as long as the connectivity between the ingress and egress - node of the ring still exists. + 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: -2.2. Smooth Upgrade from Linear Protection to Ring Protection + a. The number of OAM entities needed to trigger protection - It is beneficial for service providers to upgrade the protection - scheme from linear protection to ring protection in their MPLS-TP - network without service interruption. In-service insertion and - removal of a node on the ring should also be supported. Therefore, - the MPLS-TP ring protection mechanism is supposed to be developed and - optimized for compliance with this smooth upgrading principle. + Each ring-node requires only one instance of the RPS protocol. The + OAM of the links connected to the adjacent ring-nodes has to be + forwarded to only this instance in order to trigger protection. -2.3. Configuration Complexity + b. The number of elements of recovery in the ring - Ring protection can reduce the dependency of configuration on the - quantity of services, thus will simplify the network protection - configuration and operation effort. This is because the ring - protection makes use of the characteristics of ring topology and - mechanisms on the section layer. While in the application scenarios - of deploying linear protection in ring topology MPLS-TP network, the - configuration of protection has a close relationship with the - quantities of services carried. Especially in some large metro - networks with more than ten thousands of services in the access - nodes, the LSP linear protection capabilities of the metro core nodes - needs to be large enough to meet the network planning requirements, - which also leads to the complexity of network protection - configurations and operations. + Each ring-node requires only one instance of the RPS protocol and is + independent of the number of LSPs that are protected. -3. Terminology and Notation + c. The required number of labels required for the protection paths - The following syntax will be used to describe the contents of the - label stack: + 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. - 1. The label stack will be enclosed in square brackets ("[]"). + d. The amount of control and management-plane transactions + Each ring-node requires only one instance of the RPS protocol this + means that only one maintenance operation is required per ring-node. - 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. + e. Minimize the signaling and routing information exchange during + protection - 3. If the Label is assigned by Node X, the Node Name is enclosed in - bracket ("()") + 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 4.1. Ring Tunnel This document introduces a new logical layer of the ring for shared ring protection in MPLS-TP networks. As shown in Figure 1, the new logical layer consists of ring tunnels which provides a server layer for the LSPs traverse the ring. Once a ring tunnel is established, - the configuration, management and protection of the ring are all - performed at the ring tunnel level. One port can carry multiple ring - tunnels, while one ring tunnel can carry multiple LSPs. + the forwarding and protection switching of the ring are all performed + at the ring tunnel level. A port can carry multiple ring tunnels, + and a ring tunnel can carry multiple LSPs. +------------- +-------------| +-------------| | =====PW1======| | | | | Ring | Physical =====PW2======| LSP | Tunnel | Port | | | =====PW3======| | | +-------------| | +-------------| +------------- Figure 1. The logical layers of the ring The label stack used in MPLS-TP Shared Ring Protection mechanism is - shown as below: + [Ring Tunnel Label|LSP Label|PW Label](Payload) as illustrated in + figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring tunnel Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 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: + have the same egress node on the ring and travels along the ring in + the same direction (clockwise or anticlockwise) share the same ring + tunnels. In other words, all the LSPs that traverse the ring in the + same direction 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 o one anticlockwise working ring tunnel, which is protected by the clockwise protection ring tunnel o one clockwise protection ring tunnel @@ -334,36 +306,37 @@ Figure 3. Ring tunnels in MSRP Through these working and protection ring tunnels, LSPs which enter the ring from any node can reach any egress nodes on the ring, and are protected from failures on the ring. 4.1.2. Label Assignment and Distribution The ring tunnel labels are downstream-assigned labels as defined in - [RFC3031]. The ring tunnel labels can be either configured - statically, provisioned by a controller, or distributed dynamically - via a control protocol. + [RFC3031]. The ring tunnel labels on each hop of the ring tunnel can + be either configured statically, provisioned by a controller, or + distributed dynamically via a control protocol. 4.1.3. Forwarding Operation When an MPLS-TP transport path, such as an LSP, enters the ring, the - ingress node on the ring pushes the working ring tunnel label - according to the egress node and sends the traffic to 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. + ingress node on the ring pushes the working ring tunnel label which + is used to reach the specific egress node and sends the traffic to + 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]. 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 @@ -393,113 +366,115 @@ Figure 4. Label operation of MSRP 4.2. Failure Detection The MPLS-TP section layer OAM is used to monitor the connectivity between each two adjacent nodes on the ring using the mechanisms defined in [RFC6371]. Protection switching is triggered by the failure detected on the ring by the OAM mechanisms. - Two end ports of a link form a Maintenance Entity Group (MEG), and an - MEG end point (MEP) function is installed in each ring port. CC OAM + Two ports of a link form a Maintenance Entity Group (MEG), and an MEG + end point (MEP) function is installed in each ring port. CC OAM packets are periodically exchanged between each pair of MEPs to - monitor the link health. Three consecutive CC packets losses will be + monitor the link health. Three consecutive lost CC packets will be interpreted as a link failure. A node failure is regarded as the failure of two links attached to that node. The two nodes adjacent to the failed node detect the 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. + 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 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 + 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 the adjacent ring nodes form the ring map. Each - ring node maintains the ring map and use it to peform ring + 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. - 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: + 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](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 the label stack of LSP1. + [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. - Three typical ring protection mechanisms are specified in this - section: wrapping, short wrapping and steering. + 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. - 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. + 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 + around the ring to the switching node downstream of the failure + through the protection ring tunnel, where it is switched back onto + the working ring tunnel to 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. + perform 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 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. + closed ring protection tunnel can protect both link failures and node + failures. 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) 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 + 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 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). + [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)]******+---+ #/* *\# [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) #/* *\# +---+ +---+ | E | | B | +---+ +---+ @@ -515,27 +490,30 @@ Figure 5.Wrapping for link failure 4.3.1.2. Wrapping for Node Failure 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 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) -> + [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](data traffic carried by 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 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 @@ -559,52 +537,54 @@ 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 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 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. - 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. + 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. 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. + 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. +---+#####[RaP_D(F)]######+---+ | F |---------------------| A | +-- LSP1 +---+*****[RcW_D(A)]******+---+ #/* *\# [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) #/* *\# +---+ +---+ | E | | B | +---+ +---+ @@ -625,30 +605,31 @@ 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 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, 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 + 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 + 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 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) @@ -671,27 +652,29 @@ 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. 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 + 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 needs to switchover, it will switch the LSPs from the working - ring tunnels to its corresponding protection ring tunnels. + 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. 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)] @@ -712,60 +695,59 @@ ----- 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 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) . + (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 - 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) . + 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 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 topology, it is aware that there is a fault on the + state of its ring map, 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). + path A->F->E->D, the label operation is: [LSP1](Payload) -> + [RaP_D(F)| LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> + [RaP_D(D)|LSP1](NodeE) -> [LSP1](Payload). 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). + [LSP2](Payload) -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) + -> [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> + [LSP2](Payload). 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 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 @@ -865,27 +847,27 @@ +---+ +---+ +---+ +---+ +---+ | 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 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 + independently. A failure that happens in one ring only triggers + protection switching in the ring itself and does not affect the other + ring, unless the failure is on the interconnection node. In 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 use seperate + The service LSPs that traverse the interconnected rings use separate 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 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 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 @@ -1061,23 +1043,27 @@ 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. + Ring Protection Switch protocol (RPS). The RPS processes in each of + the individual ring nodes that form the ring MUST communicate using + the G-ACh channel. The described RPS protocol uses the short- + wrapping mechanism described in section 4.3.2 as an example. + + All nodes in the same ring MUST use the same protection mechanism, + Wrapping, steering or short-wrapping. The RPS protocol MUST carry the ring status information and RPS 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 @@ -1115,37 +1101,37 @@ -------| A |-------------| B |----- X -----| C |------- (SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+ Figure 15. RPS communication between the ring nodes in case of failure between nodes B and C Note that in the case of a bidirectional failure such as a cable cut, 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 wrapping protection, each node detects the + failure or receives the RPS request as the destination node 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 short wrapping protection, each node + detects the failure or receives the RPS request as the destination + node MUST perform the switch only from the working ring tunnels to + the protection ring tunnels. 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 + 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. A protection switch MUST be initiated by one of the criteria specified in Section 5.2. A failure of the RPS protocol or @@ -1172,48 +1158,65 @@ 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 - with the interval of 5 seconds. + with the interval of 5 seconds. A ring node which is not the + destination of the received RPS message MUST forward it to the next + node along the ring immediately. 5.1.2. RPS PDU Format Figure 17 depicts the format of an RPS packet that is sent on the G-ACh. The Channel Type field is set to indicate that the message is an RPS message. The ACH MUST NOT include the ACH TLV Header [RFC5586] 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 | + | Dest Node ID | Src Node ID | Request | M | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 + 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 + 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: + + +------------------+-----------------------------+ + | Bits (MSB-LSB) | Protecton Switching Mode | + +------------------+-----------------------------+ + | 0 0 | Wrapping | + | 0 1 | Short Wrapping | + | 1 0 | Steering | + | 1 1 | Reserved | + +------------------+-----------------------------+ + 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 | | 0 0 0 0 1 1 0 1 | Forced Switch (FS) | | | 0 0 0 0 1 0 1 1 | Signal Fail (SF) | | @@ -1252,21 +1255,23 @@ A node in the switching state MUST source RPS request to adjacent node with its highest RPS request code in both directions when it detects a failure or receives an external command. A node in the switching state MUST terminate RPS requests flow in both directions. As soon as it receives an RPS request from the short path, the node to which it is addressed MUST acknowledge the RPS request by replying with the RR code on the short path, and with the received RPS request - code on the long path. Here the short path refers to the shorter + 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 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). @@ -1300,23 +1305,23 @@ 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 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 5.1.2, unless - the requests are allowed to coexist. + initiated command, or received RPS request shall preempt existing 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. @@ -1466,39 +1471,38 @@ 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. + the state during the WTR period unless it is preempted 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 | + | B | Pass-through | N/A | | | Working: no switch | | | | Protection: pass through | | +-----+-----------------------------+----------------+ | C | Switching - LP | LP | | | Working: no switch | | | | Protection: no switch | | +-----+-----------------------------+----------------+ | D | Idle - LW | NR | | | Working: no switch | | | | Protection: no switch | | @@ -1537,22 +1541,22 @@ FS E (Switching - FS) SF F (Switching - SF) Recover from SF N/A MS G (Switching - MS) Clear N/A WTR expires N/A EXER I (Switching - EXER) ===================================================================== Initial state New request New state ------------- ----------- --------- - B (Pass-trough) LP C (Switching - LP) - LW B (Pass-trough) + B (Pass-through) LP C (Switching - LP) + LW B (Pass-through) FS O - if current state is due to LP sent by another node E (Switching - FS) - otherwise SF O - if current state is due to LP sent by another node F (Switching - SF) - otherwise Recover from SF N/A MS O - if current state is due to LP, SF or FS sent by another node @@ -1566,21 +1570,21 @@ C (Switching - LP) LP N/A LW O FS O SF O Recover from SF N/A MS O Clear A (Idle) - if there is no failure in the ring F (Switching - SF) - if there is a failure at this node - B (Pass-trough) - if there is + 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 D (Idle - LW) - if on another span @@ -1612,30 +1616,29 @@ another span SF O - if on the addressed span E (Switching - FS) - if on another span Recover from SF N/A MS O Clear A (Idle) - if there is no failure in the ring F (Switching - SF) - if there is a failure at this node - B (Pass-trough) - if there is + 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 - D (Idle - LW) - if on the same span FS E (Switching - FS) SF N/A - if on the same span F (Switching - SF) - if on another span Recover from SF H (Switching - WTR) MS O Clear N/A WTR expires N/A @@ -1696,21 +1699,21 @@ FS E (Switching - FS) SF F (Switching - SF) MS G (Switching - MS) WTR N/A EXER I (Switching - EXER) RR N/A NR A (Idle) ===================================================================== Initial state New request New state ------------- ----------- --------- - B (Pass-trough) LP C (Switching - LP) + B (Pass-through) LP C (Switching - LP) FS N/A - cannot happen when there is LP request in the ring E (Switching - FS) - otherwise SF N/A - cannot happen when there is LP request in the ring F (Switching - SF) - otherwise MS N/A - cannot happen when there is LP, FS or SF request in the ring G (Switching - MS) - otherwise @@ -1817,97 +1821,97 @@ 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) - SF B (Pass-trough) - MS B (Pass-trough) - WTR B (Pass-trough) - EXER B (Pass-trough) + A (Idle) LP B (Pass-through) + FS B (Pass-through) + SF B (Pass-through) + MS B (Pass-through) + WTR B (Pass-through) + EXER B (Pass-through) RR N/A NR N/A ===================================================================== Initial state New request New state ------------- ----------- --------- - B (Pass-trough) LP B (Pass-trough) + B (Pass-through) LP B (Pass-through) FS N/A - cannot happen when there is LP request in the ring - B (Pass-trough) - otherwise + B (Pass-through) - otherwise SF N/A - cannot happen when there is LP request in the ring - B (Pass-trough) - otherwise + B (Pass-through) - otherwise MS N/A - cannot happen when there is LP, FS or SF request in the ring - B (Pass-trough) - otherwise + B (Pass-through) - otherwise WTR N/A - cannot happen when there is LP, FS, SF or MS request in the ring - B (Pass-trough) - otherwise + B (Pass-through) - otherwise EXER N/A - cannot happen when there is LP, FS, SF, MS or WTR request in the ring - B (Pass-trough) - otherwise + B (Pass-through) - otherwise RR N/A - NR B (Pass-trough) + NR N/A ===================================================================== Initial state New request New state ------------- ----------- --------- C (Switching - LP) LP C (Switching - LP) FS N/A - cannot happen when there is LP request in the ring SF N/A - cannot happen when there is LP request in the ring MS N/A - cannot happen when there is LP request in the ring WTR N/A - cannot happen when there is LP in the ring EXER N/A - cannot happen when there is LP request in the ring RR N/A NR N/A ===================================================================== Initial state New request New state ------------- ----------- --------- - D (Idle - LW) LP B (Pass-trough) - FS B (Pass-trough) - SF B (Pass-trough) - MS B (Pass-trough) - WTR B (Pass-trough) - EXER B (Pass-trough) + D (Idle - LW) LP B (Pass-through) + FS B (Pass-through) + SF B (Pass-through) + MS B (Pass-through) + WTR B (Pass-through) + EXER B (Pass-through) RR N/A NR N/A ===================================================================== Initial state New request New state ------------- ----------- --------- - E (Switching - FS) LP B (Pass-trough) + E (Switching - FS) LP B (Pass-through) FS E (Switching - FS) SF E (Switching - FS) MS N/A - cannot happen when there is FS request in the ring WTR N/A - cannot happen when there is FS request in the ring EXER N/A - cannot happen when there is FS request in the ring RR N/A NR N/A ===================================================================== Initial state New request New state ------------- ----------- --------- - F (Switching - SF) LP B (Pass-trough) + F (Switching - SF) LP B (Pass-through) FS F (Switching - SF) SF F (Switching - SF) MS N/A - cannot happen when there is SF request in the ring WTR N/A - cannot happen when there is SF request in the ring EXER N/A - cannot happen when there is SF request in the ring RR N/A NR N/A @@ -1904,52 +1908,53 @@ FS F (Switching - SF) SF F (Switching - SF) MS N/A - cannot happen when there is SF request in the ring WTR N/A - cannot happen when there is SF request in the ring EXER N/A - cannot happen when there is SF request in the ring RR N/A NR N/A + ===================================================================== Initial state New request New state ------------- ----------- --------- - G (Switching - MS) LP B (Pass-trough) - FS B (Pass-trough) - SF B (Pass-trough) + G (Switching - MS) LP B (Pass-through) + FS B (Pass-through) + SF B (Pass-through) MS G (Switching - MS) - release the switches but signal MS WTR N/A - cannot happen when there is MS request in the ring EXER N/A - cannot happen when there is MS request in the ring RR N/A NR N/A ===================================================================== Initial state New request New state ------------- ----------- --------- - H (Switching - WTR) LP B (Pass-trough) - FS B (Pass-trough) - SF B (Pass-trough) - MS B (Pass-trough) + H (Switching - WTR) LP B (Pass-through) + FS B (Pass-through) + SF B (Pass-through) + MS B (Pass-through) WTR N/A EXER N/A - cannot happen when there is WTR request in the ring RR N/A NR N/A ===================================================================== Initial state New request New state - I (Switching - EXER) LP B (Pass-trough) - FS B (Pass-trough) - SF B (Pass-trough) - MS B (Pass-trough) + I (Switching - EXER) LP B (Pass-through) + FS B (Pass-through) + SF B (Pass-through) + MS B (Pass-through) WTR N/A EXER I (Switching - EXER) RR N/A NR N/A ===================================================================== 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 @@ -1985,85 +1990,116 @@ this way, every ring-node only needs to be configured with 2 MEPs. As shown in the above example, RPS is designed for ring topologies and can achieve ring protection efficiently with minimum protection instances and OAM entities, which meets the requirements on topology specific recovery mechanisms as specified in [RFC5654]. 6. IANA Considerations IANA is requested to administer the assignment of new values defined - in this document and summarized in this section. + 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 + 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: Value| Description | Reference ------+---------------------------+-------------- TBD | Ring Protection Switching |this document | Protocol (RPS) | ------+---------------------------+-------------- -6.2. RSP Request Codes +6.2. RPS Request Codes IANA is requested to create a new sub-registry under the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry called the "MPLS RPS Request Code Registry". All code points within this registry shall be allocated according to the "Standards Action" procedure as specified in [RFC5226]. The RPS Request Field is 8 bits, the allocated values are as follows: Value Description Reference ------- --------------------------- --------------- 0 No Request (NR) this document 1 Reverse Request (RR) this document - 2 not assigned + 2 unassigned 3 Exercise (EXER) this document - 4 not assigned + 4 unassigned 5 Wait-To-Restore (WTR) this document 6 Manual Switch (MS) this document - 7-10 not assigned + 7-10 unassigned 11 Signal Fail (SF) this document - 12 not assigned + 12 unassigned 13 Forced Switch (FS) this document - 14 not assigned + 14 unassigned 15 Lockout of Protection (LP) this document - 16-255 not assigned + 16-254 unassigned + 255 Reserved 7. Security Considerations The RPS protocol defined in this document is carried in the G-ACh [RFC5586], which is a generalization of the Associated Channel defined in [RFC4385]. The security considerations specified in these documents apply to the proposed RPS mechanism. 8. Contributing Authors + Kai Liu + Huawei Technologies + Email: alex.liukai@huawei.com - Wen Ye, Minxue Wang, Sheng Liu (China Mobile) + Jia He + Huawei Technologies + Email: hejia@huawei.com - Guanghui Sun (Huawei) + Fang Li + China Academy of Telecommunication Research MIIT., China + Email: lifang@catr.cn + + Jian Yang + ZTE Corporation P.R.China + Email: yang.jian90@zte.com.cn + + Junfang Wang + Fiberhome Telecommunication Technologies Co., LTD. + Email: wjf@fiberhome.com.cn + + Wen Ye + China Mobile + Email: yewen@chinamobile.com + + Minxue Wang + China Mobile + Email: wangminxue@chinamobile.com + + Sheng Liu + China Mobile + Email: liusheng@chinamobile.com + + Guanghui Sun + Huawei Technologies + Email: sunguanghui@huawei.com 9. Acknowledgements The authors would like to thank Gregory Mirsky, Yimin Shen, Eric - Osborne and Spencer Jackson for their valuable comments and - suggestions. + Osborne, Spencer Jackson and Eric Gray for their valuable comments + and suggestions. 10. References - 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, @@ -2126,39 +2162,15 @@ Han Li China Mobile Email: lihan@chinamobile.com Huub van Helvoort Hai Gaoming BV Email: huubatwork@gmail.com - Kai Liu - Huawei Technologies - - Email: alex.liukai@huawei.com Jie Dong Huawei Technologies Email: jie.dong@huawei.com - - Jia He - Huawei Technologies - - Email: hejia@huawei.com - - Fang Li - China Academy of Telecommunication Research, MIIT., China - - Email: lifang@ritt.cn - - Jian Yang - ZTE Corporation P.R.China - - Email: yang.jian90@zte.com.cn - - Junfang Wang - Fiberhome Telecommunication Technologies Co., LTD. - - Email: wjf@fiberhome.com.cn