From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8227.txt | 3139 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3139 insertions(+) create mode 100644 doc/rfc/rfc8227.txt (limited to 'doc/rfc/rfc8227.txt') diff --git a/doc/rfc/rfc8227.txt b/doc/rfc/rfc8227.txt new file mode 100644 index 0000000..470de70 --- /dev/null +++ b/doc/rfc/rfc8227.txt @@ -0,0 +1,3139 @@ + + + + + + +Internet Engineering Task Force (IETF) W. Cheng +Request for Comments: 8227 L. Wang +Category: Standards Track H. Li +ISSN: 2070-1721 China Mobile + H. van Helvoort + Hai Gaoming BV + J. Dong + Huawei Technologies + August 2017 + + + MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology + +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 Switching (RPS) protocol that is used to + coordinate the protection behavior of the nodes on an MPLS ring. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8227. + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 1] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 2] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4 + 3. MPLS-TP Ring Protection Criteria and Requirements . . . . . . 5 + 4. Shared-Ring Protection Architecture . . . . . . . . . . . . . 6 + 4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1.1. Establishment of the Ring Tunnel . . . . . . . . . . 8 + 4.1.2. Label Assignment and Distribution . . . . . . . . . . 9 + 4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 9 + 4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 10 + 4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 11 + 4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 12 + 4.3.2. Short-Wrapping . . . . . . . . . . . . . . . . . . . 14 + 4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 17 + 4.4. Interconnected Ring Protection . . . . . . . . . . . . . 21 + 4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 21 + 4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 22 + 4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 23 + 4.4.4. Interconnected Ring-Switching Procedure . . . . . . . 25 + 4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 26 + 5. Ring Protection Coordination Protocol . . . . . . . . . . . . 27 + 5.1. RPS and PSC Comparison on Ring Topology . . . . . . . . . 27 + 5.2. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 28 + 5.2.1. Transmission and Acceptance of RPS Requests . . . . . 30 + 5.2.2. RPS Protocol Data Unit (PDU) Format . . . . . . . . . 31 + 5.2.3. Ring Node RPS States . . . . . . . . . . . . . . . . 32 + 5.2.4. RPS State Transitions . . . . . . . . . . . . . . . . 34 + 5.3. RPS State Machine . . . . . . . . . . . . . . . . . . . . 36 + 5.3.1. Switch Initiation Criteria . . . . . . . . . . . . . 36 + 5.3.2. Initial States . . . . . . . . . . . . . . . . . . . 39 + 5.3.3. State Transitions When Local Request Is Applied . . . 40 + 5.3.4. State Transitions When Remote Request is Applied . . 44 + 5.3.5. State Transitions When Request Addresses to Another + Node is Received . . . . . . . . . . . . . . . . . . 47 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 + 6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 51 + 6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 51 + 7. Operational Considerations . . . . . . . . . . . . . . . . . 52 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 52 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 53 + 9.2. Informative References . . . . . . . . . . . . . . . . . 54 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55 + Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 55 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 + + + + +Cheng, et al. Standards Track [Page 3] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +1. Introduction + + As described in Section 2.5.6.1 of [RFC5654], several service + providers have expressed much interest in operating an MPLS Transport + Profile (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 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 mechanism + 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 the MPLS-TP 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. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. Terminology and Notation + + Terminology: + + 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 Label + Switched Paths (LSPs) 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. + + + + + + + + + +Cheng, et al. Standards Track [Page 4] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + 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). The ring map is used by + every ring node to determine the switchover behavior of the ring + tunnels. + + Notation: + + The following syntax will be used to describe the contents of the + label stack: + + 1. The label stack will be enclosed in square brackets ("[]"). + + 2. Each level in the stack will be separated by the '|' character. + It should be noted that the label stack may contain additional + layers. However, we only present the layers that are related to + the protection mechanism. + + 3. If the label is assigned by Node X, the Node Name is enclosed in + 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 Operations, Administration, and Maintenance (OAM) + entities needed to trigger protection + + Each ring node requires only one instance of the RPS protocol per + ring. The OAM of the links connected to the adjacent ring nodes + has to be forwarded to only this instance in order to trigger + protection. For detailed information, see Section 5.2. + + b. The number of elements of recovery in the ring + + Each ring node requires only one instance of the RPS protocol and + is independent of the number of LSPs that are protected. For + detailed information, see Section 5.2. + + + + + + + + + +Cheng, et al. Standards Track [Page 5] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + 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. For detailed information, see Section 4.1.2. + + d. The amount of control and management-plane transactions + + Each ring node requires only one instance of the RPS protocol per + ring. This means that only one maintenance operation is required + per ring node. For detailed information, see Section 5.2. + + 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. For detailed information, see Section 5.2. + +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 that provide a server layer + for the LSPs traversing the ring. Once a ring tunnel is established, + 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. + + + + + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 6] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + +------------- + +-------------| + +-------------| | + ===Service1===| | | + ===Service2===| LSP1 | | + +-------------| | + |Ring-Tunnel1 | + +-------------| | + ===Service3===| | | + ===Service4===| LSP2 | | + +-------------| | + +-------------| Physical + +-------------| + +-------------| | Port + ===Service5===| | | + ===Service6===| LSP3 | | + +-------------| | + |Ring-Tunnel2 | + +-------------| | + ===Service7===| | | + ===Service8===| LSP4 | | + +-------------| | + +-------------| + +------------- + + Figure 1: The Logical Layers of the Ring + + The label stack used in the MPLS-TP Shared-Ring Protection mechanism + is [Ring Tunnel Label|LSP Label|Service Label](Payload) as + illustrated in Figure 2. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Ring Tunnel Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LSP Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Service Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Label Stack Used in MPLS-TP Shared-Ring Protection + + + + + + + + + +Cheng, et al. Standards Track [Page 7] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +4.1.1. Establishment of the Ring Tunnel + + The Ring tunnels are established based on the egress nodes. The + egress node is the node where traffic leaves the ring. LSPs that + have the same egress node on the ring and travel 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 + + 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 anticlockwise working ring tunnel (RaW_D) via + C->B->A->F->E->D and its clockwise protection ring tunnel (RcP_D) via + D->E->F->A->B->C->D are established. For simplicity, Figure 3 only + shows RcW_D and RaP_D. A similar provisioning should be applied for + any other node on the ring. In summary, for each node in Figure 3, + when acting as an egress node, the ring tunnels are created as + follows: + + o To Node A: RcW_A, RaW_A, RcP_A, RaP_A + + o To Node B: RcW_B, RaW_B, RcP_B, RaP_B + + o To Node C: RcW_C, RaW_C, RcP_C, RaP_C + + o To Node D: RcW_D, RaW_D, RcP_D, RaP_D + + o To Node E: RcW_E, RaW_E, RcP_E, RaP_E + + o To Node F: RcW_F, RaW_F, RcP_F, RaP_F + + + +Cheng, et al. Standards Track [Page 8] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + +---+#############+---+ + | F |-------------| A | +-- LSP2 + +---+*************+---+ + #/* *\# + #/* *\# + #/* *\# + +---+ +---+ + LSP1 --+ | E | | B |+-- LSP3 + +---+ +---+ + #\ */# + #\ */# + #\ */# + +---+*************+---+ + LSP1 +--| D |-------------| C | + LSP2 +---+#############+---+ + LSP3 + + ----- Physical Links + ***** RcW_D + ##### RaP_D + + Figure 3: Ring Tunnels in MSRP + + Through these working and protection ring tunnels, LSPs that 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 on each hop of the ring tunnel can + be either configured statically, provisioned by a controller, or + distributed dynamically via a control protocol. For an LSP that + traverses the ring tunnel, the ingress ring node and the egress ring + node are considered adjacent at the LSP layer, and LSP label needs to + be allocated at these two ring nodes. The control plane for label + distribution is outside the scope of this document. + +4.1.3. Forwarding Operation + + When an MPLS-TP transport path, i.e., an LSP, enters the ring, the + ingress node on the ring pushes the working ring tunnel label that 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 + + + + +Cheng, et al. Standards Track [Page 9] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + and service 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 are supposed to be forwarded in the clockwise + direction of the ring. The label of the clockwise working ring + tunnel 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, Nodes B and 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. + + +---+#####[RaP_D(F)]######+---+ + | F |---------------------| A | +-- LSP1 + +---+*****[RcW_D(A)]******+---+ + #/* *\# + [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)] + #/* *\# + +---+ +---+ + | E | | B | + +---+ +---+ + #\ */# + [RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)] + #\ */# + +---+*****[RcW_D(D)]****+---+ + LSP1 +-- | D |-------------------| C | + +---+#####[RaP_D(C)]####+---+ + + ----- Physical Links + ***** RcW_D + ##### RaP_D + + Figure 4: Label Operation of MSRP + +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. + + + + +Cheng, et al. Standards Track [Page 10] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + Two ports of a link form a Maintenance Entity Group (MEG), and a MEG + End Point (MEP) function is installed in each ring port. Continuity + Check (CC) OAM packets are periodically exchanged between each pair + of MEPs to monitor the link health. Three consecutive lost CC + packets MUST 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 anticlockwise protection ring tunnel as an example, + but the mechanism is applicable in the same way to the anticlockwise + 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 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. + + 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. If the RPS + protocol in any node detects an RPS message with a protection- + switching mode that was not provisioned in that node, a failure of + protocol will be reported, and the protection mechanism will not be + activated. + + Wrapping ring protection: the node that 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 + + + +Cheng, et al. Standards Track [Page 11] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + this way, the impacted traffic is switched to the protection ring + tunnel by the switching node upstream of the failure, then it 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 leaves 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 + 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 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. Wrapping can be applicable for the protection of + Point-to-Multipoint (P2MP) LSPs on the ring; the details of which are + outside the scope of this document. + +4.3.1.1. Wrapping for Link Failure + + When a link failure between Nodes B and C occurs, if it is a + bidirectional failure, both Nodes B and C can detect the failure via + the OAM mechanism; if it is a unidirectional 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 RPS protocol, 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 the anticlockwise protection ring tunnel + (RaP_D) back to the clockwise working ring tunnel (RcW_D). The + + + + +Cheng, et al. Standards Track [Page 12] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + payload that 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)]******+---+ + #/* *\# + [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) + #/* *\# + +---+ +---+ + | E | | B | + +---+ +---+ + #\ *x# + [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) + #\ *x# + +---+*****[RcW_D(D)]****+---+ + LSP1 +-- | D |-------------------| C | + +---+#####[RaP_D(C)]####+---+ + + ----- Physical Links xxxxx Failure Links + ***** RcW_D ##### RaP_D + + 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 working 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 RPS protocol + specified in Section 5. + + The payload that 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). + + + + + +Cheng, et al. Standards Track [Page 13] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + In one special case where Node D fails, all the ring tunnels with + Node D as the egress will become unusable. The ingress node will + update its ring map according to received RPS messages and determine + that the egress node is not reachable; thus, it will not send traffic + to either the working or the protection tunnel. However, before the + failure location information is propagated to all the ring nodes, the + wrapping protection mechanism may cause a temporary traffic loop: + Node C detects the failure and switches the traffic from the + clockwise working ring tunnel (RcW_D) to the anticlockwise protection + ring tunnel (RaP_D); Node E also detects the failure and switches the + traffic from the anticlockwise protection ring tunnel (RaP_D) back to + the clockwise working ring tunnel (RcW_D). A possible mechanism to + mitigate the temporary loop problem is: the TTL of the ring tunnel + label is set to 2*N by the ingress ring node of the traffic, where N + is the number of nodes on the ring. + + +---+#####[RaP_D(F)]######+---+ + | F |---------------------| A | +-- LSP1 + +---+*****[RcW_D(A)]******+---+ + #/* *\# + [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) + #/* *\# + +---+ xxxxx + | E | x B x + +---+ xxxxx + #\ */# + [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) + #\ */# + +---+*****[RcW_D(D)]****+---+ + LSP1 +-- | D |-------------------| C | + +---+#####[RaP_D(C)]####+---+ + + ----- Physical Links xxxxx Failure Nodes + ***** RcW_D ##### RaP_D + + 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. + + + + + + + +Cheng, et al. Standards Track [Page 14] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + With short-wrapping protection, protection switching is executed only + at the node upstream to the failure, and the packet 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. However, the two directions of a + protected bidirectional LSP are no longer co-routed under the + protection-switching conditions. + + In the traditional wrapping solution, the protection ring tunnel is + configured as a closed ring, while in the short-wrapping solution, + the protection ring tunnel is configured as 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 Nodes B and 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 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. + + + + + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 15] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + +---+#####[RaP_D(F)]######+---+ + | F |---------------------| A | +-- LSP1 + +---+*****[RcW_D(A)]******+---+ + #/* *\# + [RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A) + #/* *\# + +---+ +---+ + | E | | B | + +---+ +---+ + #\ *x# + [RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B) + #\ *x# + +---+*****[RcW_D(D)]****+---+ + LSP1 +-- | D |-------------------| C | + +---+ +---+ + + ----- Physical Links xxxxx Failure Links + ***** RcW_D ##### RaP_D + + Figure 7: Short-Wrapping for Link Failure + +4.3.2.2. Short-Wrapping for Node Failure + + For the node failure that 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 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, the traffic of LSP1 cannot be protected by any ring tunnels + that use Node D as the egress node. The ingress node will update its + ring map according to received RPS messages and determine that the + egress node is not reachable; thus, it will not send traffic to + either the working or the protection tunnel. 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 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. With the 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 that + is already carried on the protection ring tunnel back to the working + + + + + +Cheng, et al. Standards Track [Page 16] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + 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) + #/* *\# + +---+ +---+ + | E | | B | + +---+ +---+ + #\ */# + [RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B) + #\ */# + xxxxx*****[RcW_D(D)]****+---+ + LSP1 +-- x D x-------------------| C | + xxxxx +---+ + + ----- Physical Links xxxxx Failure Nodes + ***** RcW_D ##### RaP_D + + Figure 8: Short-Wrapping for Egress Node Failure + +4.3.3. Steering + + With the steering protection mechanism, the ingress node (which adds + traffic to the ring) performs 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 that detects the failure + with an 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 that identifies a failure, it can determine + the location of the fault by using the topology information of the + ring map and updating the ring map accordingly; then, it can + determine whether the LSPs entering the ring locally need to switch + over or not. For LSPs that need to switch over, it will switch the + LSPs from the working ring tunnels to their corresponding protection + ring tunnels. + + + + + + +Cheng, et al. Standards Track [Page 17] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +4.3.3.1. Steering for Link Failure + + Ring Map of F +--LSP1 + +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+ + |F|A|B|C|D|E|F| | F | ---------------- | A | |A|B|C|D|E|F|A| + +-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]*** +---+ +-+-+-+-+-+-+-+ + |I|I|I|S|I|I| #/* *\# |I|I|S|I|I|I| + +-+-+-+-+-+-+ #/* *\# +-+-+-+-+-+-+ + [RaP_D(E)] #/* [RcW_D(B)] *\# [RaP_D(A)] + #/* [RcW_D(F)] *\# + +-+-+-+-+-+-+-+ #/* *\# + |E|F|A|B|C|D|E| +---+ +---+ +-- LSP2 + +-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+ + |I|I|I|I|S|I| +---+ +---+ |B|C|D|E|F|A|B| + +-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ + #\* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I| + [RaP_D(D)] #\* */# +-+-+-+-+-+-+ + #\* */# [RaP_D(B)] + +-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+ + |D|E|F|A|B|C|D| +-- | D | xxxxxxxxxxxxxxxxx | C | |C|D|E|F|A|B|C| + +-+-+-+-+-+-+-+ LSP1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+ + |I|I|I|I|I|S| LSP2 |S|I|I|I|I|I| + +-+-+-+-+-+-+ +-+-+-+-+-+-+ + + ----- Physical Links + ***** RcW_D + ##### RaP_D + I: Intact + S: Severed + + Figure 9: Steering Operation and Protection Switching + When Link C-D Fails + + 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, which is Node D. + + In normal state, LSP1 is carried by the clockwise working ring tunnel + (RcW_D) through the path A->B->C->D, and 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) through + the path B->C->D, and the label operation is: [LSP2](Payload) -> + [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](Payload). + + + + + + +Cheng, et al. Standards Track [Page 18] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + 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 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 anticlockwise + 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 + 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, and 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](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 Nodes 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 determines + that the working ring tunnel for LSP2 still works fine, and it will + not perform the switchover. + + + + + + + + +Cheng, et al. Standards Track [Page 19] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + /+-- LSP1 ++-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+ +|F|A|B|C|D|E|F| | F | ----------------- | A | |A|B|C|D|E|F|A| ++-+-+-+-+-+-+-+ +---+ ***[RcW_D(A)]**** +---+ +-+-+-+-+-+-+-+ + |I|S|I|I|I|I| #/* x |S|I|I|I|I|I| + +-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ + [RaP_D(E)] #/*[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] + #/* x /+-- LSP2 ++-+-+-+-+-+-+-+ +---+ +---/ +-+-+-+-+-+-+-+ +|E|F|A|B|C|D|E| | E | | B | |B|C|D|E|F|A|B| ++-+-+-+-+-+-+-+ +---+ +---+ +-+-+-+-+-+-+-+ + |I|I|S|I|I|I| #\* */# |I|I|I|I|I|S| + +-+-+-+-+-+-+ #\*[RcW_D(E)] [RcW_D(C)] */# +-+-+-+-+-+-+ + [RaP_D(D)] #\* */# [RaP_D(B)] ++-+-+-+-+-+-+-+ #\* */# +-+-+-+-+-+-+-+ +|D|E|F|A|B|C|D| +---+ ***[RcW_D(D)]*** +---+ |C|D|E|F|A|B|C| ++-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+ + |I|I|I|S|I|I| LSP1 +---+ ###[RaP_D(C)]### +---+ |I|I|I|I|S|I| + +-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+ + + ----- Physical Links + ***** RcW_D + ##### RaP_D + + Figure 10: Steering Operation and Protection Switching + When Link A-B Fails + +4.3.3.2. Steering for Node Failure + + For a node failure that 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, 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. + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 20] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +4.4. Interconnected Ring Protection + +4.4.1. Interconnected Ring Topology + + Interconnected ring topology is widely used in MPLS-TP networks. For + a given ring, the interconnection node acts as the egress node for + that ring, meaning that all LSPs using the interconnection node as an + egress from one specific ring to another will use the same group of + ring tunnels within the ring. This document will discuss two typical + interconnected ring topologies: + + 1. Single-node interconnected rings + + In single-node interconnected rings, the connection between + the two rings is through a single node. Because the + interconnection node is in fact a single point of failure, + this topology should be avoided in real transport networks. + + Figure 11 shows the topology of single-node interconnected + rings. Node C is the interconnection node between Ring1 and + Ring2. + + +---+ +---+ +---+ +---+ + | A |------| B |----- -----| G |------| H | + +---+ +---+ \ / +---+ +---+ + | \ / | + | \ +---+ / | + | Ring1 | C | Ring2 | + | / +---+ \ | + | / \ | + +---+ +---+ / \ +---+ +---+ + | F |------| E |----- -----| J |------| I | + +---+ +---+ +---+ +---+ + + Figure 11: Single-Node Interconnected Rings + + 2. Dual-node interconnected rings + + In dual-node interconnected rings, the connection between the + two rings is through two nodes. The two interconnection nodes + belong to both interconnected rings. This topology can + recover from one interconnection node failure. + + Figure 12 shows the topology of dual-node interconnected + rings. Nodes C and D are the interconnection nodes between + Ring1 and Ring2. + + + + + +Cheng, et al. Standards Track [Page 21] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + +---+ +---+ +---+ +---+ +---+ + | A |------| B |------| C |------| G |------| H | + +---+ +---+ +---+ +---+ +---+ + | | | + | | | + | Ring1 | Ring2 | + | | | + | | | + +---+ +---+ +---+ +---+ +---+ + | 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. The + RPS protocol operates on each ring 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 the ring + tunnels in each ring; within a given ring, the tunnel is selected + using normal ring-selection procedures. The traversing LSPs are + stitched on 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 + interconnection node group. In addition, on both nodes in the + virtual interconnection node group, the same LSP label is assigned + for each traversed LSP. This way, any interconnection node in the + virtual node group can terminate the working or protection ring + tunnels targeted to the virtual node group and stitch the service LSP + from the source ring tunnel to the destination ring tunnel. + + When the service LSP passes through the interconnected rings, the + direction of the working ring tunnels used on both rings SHOULD be + the same. In dual-node interconnected rings, this ensures that in + normal state the traffic passes only one of the two interconnection + nodes and does not pass the link between the two interconnection + + + + +Cheng, et al. Standards Track [Page 22] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + nodes. The traffic will then only be switched to the protection path + if the interconnection node that is in working path fails. For + example, if the service LSP uses the clockwise working ring tunnel on + Ring1, when the service LSP leaves Ring1 and enters Ring2, the + working ring tunnel used on Ring2 should also follow the clockwise + direction. + +4.4.3. Ring Tunnels in Interconnected Rings + + The same ring tunnels as described in Section 4.1 are used in each + ring of the interconnected rings. In addition, ring tunnels to the + virtual interconnection node group are established on each ring of + the interconnected rings, that is: + + o one clockwise working ring tunnel to the virtual interconnection + node group + + o one anticlockwise protection ring tunnel to the virtual + interconnection node group + + o one anticlockwise working ring tunnel to the virtual + interconnection node group + + o one clockwise protection ring tunnel to the virtual + interconnection node group + + The ring tunnels to the virtual interconnection node group are shared + by all LSPs that need to be forwarded to other rings. These ring + tunnels can terminate at any node in the virtual interconnection node + group. + + For example, all the ring tunnels on Ring1 in Figure 13 are + provisioned as follows: + + o To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A + + o To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B + + o To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C + + o To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D + + o To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E + + o To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F + + o To the virtual interconnection node group (including Nodes F and + A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A + + + +Cheng, et al. Standards Track [Page 23] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + All the ring tunnels on Ring2 in Figure 13 are provisioned as + follows: + + o To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A + + o To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F + + o To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G + + o To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H + + o To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I + + o To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J + + o To the virtual interconnection node group (including Nodes F and + A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 24] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + +---+ccccccccccccc+---+ + | H |-------------| I |--->LSP1 + +---+ +---+ + c/a a\ + c/a a\ + c/a a\ + +---+ +---+ + | G | Ring2 | J | + +---+ +---+ + c\a a/c + c\a a/c + c\a aaaaaaaaaaaaa a/c + +---+ccccccccccccc+---+ + | F |-------------| A | + +---+ccccccccccccc+---+ + c/aaaaaaaaaaaaaaaaaaa a\ + c/ a\ + c/ a\ + +---+ +---+ + | E | Ring1 | B | + +---+ +---+ + c\a a/c + c\a a/c + c\a a/c + +---+aaaaaaaaaaaaa+---+ + LSP1--->| D |-------------| C | + +---+ccccccccccccc+---+ + + Ring1: + ccccccccccc R1cW_F&A + aaaaaaaaaaa R1aP_F&A + + Ring2: + ccccccccccc R2cW_I + aaaaaaaaaaa R2aP_I + + Figure 13: Ring Tunnels for the Interconnected Rings + +4.4.4. Interconnected Ring-Switching Procedure + + As shown in Figure 13, for the service LSP1 that enters Ring1 at Node + D and leaves Ring1 at Node F and continues to enter Ring2 at Node F + and leaves Ring2 at Node I, the short-wrapping protection scheme is + described as below. + + + + + + + +Cheng, et al. Standards Track [Page 25] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + In normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. + At the interconnection Node F, the label used for the working ring + tunnel R1cW_F&A in Ring1 is popped, the LSP label is swapped, and the + label used for the working ring tunnel R2cW_I in Ring2 will be pushed + based on the inner LSP label lookup. The working path that the + service LSP1 follows is: LSP1->R1cW_F&A + (D->E->F)->R2cW_I(F->G->H->I)->LSP1. + + In case of link failure, for example, when a failure occurs on the + link between Nodes F and E, Node E will detect the failure and + execute protection switching as described in Section 4.3.2. The path + that the service LSP1 follows after switching change to: LSP1->R1cW_F + &A(D->E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1. + + In case of a non-interconnection node failure, for example, when the + failure occurs at Node E in Ring1, Node D will detect the failure and + execute protection switching as described in Section 4.3.2. The path + that the service LSP1 follows after switching becomes: + LSP1->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 + detect the failure and execute protection switching as described in + Section 4.3.2. Node A in Ring2 will also detect the failure and + execute protection switching as described in Section 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 shown in Figure 13, in normal state, the service traffic LSP1 + traverses D->E->F in Ring1 and F->G->H->I in Ring2. Nodes A and F + are the interconnection nodes. When both links between Nodes F and G + and between Nodes F and 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 the ring map + and the fault location. The ring map can be obtained from the + Network Management System (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 + + + +Cheng, et al. Standards Track [Page 26] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + 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 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 the ring tunnel (R2aW_I). + +5. Ring Protection Coordination Protocol + +5.1. RPS and PSC Comparison on Ring Topology + + This section provides comparison between RPS and Protection State + Coordination (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 endpoints 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 is 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 will be specified in the following sections, 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 an example: + + With the mechanism specified in [RFC6974], on every ring node, a + linear protection configuration has to be provisioned with every + other node in the ring, i.e., with (N-1) other nodes. This means + that on every ring node there will be (N-1) instances of the PSC + protocol. And in order to detect faults and to transport the PSC + message, each instance shall have a MEP on the working path and a MEP + on the protection path, respectively. This means that every node on + the ring needs to be configured with (N-1) * 2 MEPs. + + + + + +Cheng, et al. Standards Track [Page 27] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + With the mechanism defined in this document, on every ring node there + will only be a single instance of the RPS protocol. In order to + detect faults and to transport the RPS message, each node only needs + to have a MEP on the section to its adjacent nodes, respectively. In + 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]. + +5.2. RPS Protocol + + The RPS protocol defined in this section is used to coordinate the + protection-switching action of all the ring nodes in the same ring. + + The protection operation of the ring tunnels is controlled with the + help of the RPS protocol. The RPS processes in each of the + individual ring nodes that form the ring MUST communicate using the + Generic Associated Channel (G-ACh). The RPS protocol is applicable + to all the three ring protection modes. This section takes the + short-wrapping mechanism described in Section 4.3.2 as an example. + + The RPS protocol is used to distribute the ring status information + and RPS requests to all the ring nodes. Changes in the ring status + information and RPS requests can be initiated automatically based on + link status or caused by external commands. + + Each node on the ring is 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 identify the source and destination + nodes of each RPS request. + + Every node obtains the ring topology either by configuration or via + some topology discovery mechanism. The ring map consists of the ring + topology information, and connectivity status (Intact or Severed) + between the adjacent ring nodes, which is determined via the OAM + message exchanged between the adjacent nodes. The ring map is used + by every ring node to determine the switchover behavior of the ring + tunnels. + + + + + + + + + +Cheng, et al. Standards Track [Page 28] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + As shown in Figure 14, when no protection switching is active on the + ring, each node MUST send RPS requests with No Request (NR) to its + two adjacent nodes periodically. The transmission interval of RPS + requests is specified in Section 5.2.1. + + +---+ 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 + + As shown in Figure 15, when a node detects a failure and determines + that protection switching is required, it MUST send the appropriate + RPS request in both directions to the destination node. The + destination node is the other node that is adjacent to the identified + failure. 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 RPS protocol communication in + the ring. The RPS request MUST be terminated by the destination node + of the message. If an RPS request with the node itself set as the + source node is received, this message MUST be dropped and not be + forwarded to the next node. + + +---+ 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 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, 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, 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. + + + + + +Cheng, et al. Standards Track [Page 29] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + 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 MUST 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 that generate the RPS requests MUST drop their + respective switches and MUST generate an RPS request carrying the NR + code. The node receiving such an RPS request from both directions + MUST drop its protection switches. + + A protection switch MUST be initiated by one of the criteria + specified in Section 5.3. 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 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. + + The MPLS-TP Shared-Ring Protection mechanism supports multiple + protection switches in the 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 using + their ring map to determine the state of the ring (nodes and links). + In order to accommodate ring state knowledge, the RPS requests MUST + be sent in both directions during a protection switch. + +5.2.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 a new RPS request MUST + 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. A ring node that is not the + destination of the received RPS message MUST forward it to the next + node along the ring immediately. + + + +Cheng, et al. Standards Track [Page 30] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +5.2.2. RPS Protocol Data Unit (PDU) Format + + Figure 16 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. + + 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|Version| Reserved | RPS Channel Type (0x002A) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 + the 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-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 protection-switching mechanism. The + defined values of the M field are listed as below: + + +------------------+-----------------------------+ + | Bits (MSB - LSB) | Protection-Switching Mode | + +------------------+-----------------------------+ + | 0 0 | Reserved | + | 0 1 | Wrapping | + | 1 0 | Short-Wrapping | + | 1 1 | Steering | + +------------------+-----------------------------+ + + Note: + MSB = most significant bit + LSB = least significant bit + + + + + + +Cheng, et al. Standards Track [Page 31] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + o RPS Request Code: A code consisting of 8 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) | | + | 0 0 0 0 0 1 1 0 | Manual Switch (MS) | | + | 0 0 0 0 0 1 0 1 | Wait-to-Restore (WTR) | | + | 0 0 0 0 0 0 1 1 | Exercise (EXER) | | + | 0 0 0 0 0 0 0 1 | Reverse Request (RR) | | + | 0 0 0 0 0 0 0 0 | No Request (NR) | lowest | + +------------------+-----------------------------+----------+ + +5.2.3. Ring Node RPS States + + Idle state: A node is in the idle state when it has no RPS request + and is sending and receiving an NR code to/from both directions. + + Switching state: A node not in the idle or pass-through states is in + the switching state. + + Pass-through state: A node is in the pass-through state when its + highest priority RPS request is a request not destined to it or + generated by it. The pass-through is bidirectional. + +5.2.3.1. Idle State + + A node in the idle state MUST generate the NR request in both + directions. + + A node in the idle state MUST terminate RPS requests that flow in + both directions. + + A node in the idle state MUST block the traffic flow on protection + ring tunnels in both directions. + +5.2.3.2. Switching State + + A node in the switching state MUST generate an 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. + + + + + + + +Cheng, et al. Standards Track [Page 32] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + In a bidirectional failure condition, both of the nodes adjacent to + the failure detect the failure and send the RPS request in both + directions with the destination set to each other; while each node + can only receive the RPS request via the long path, the message sent + via the short path will get lost due to the bidirectional failure. + Here, the short path refers to the shorter 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. Upon receipt of the RPS request + on the long path, the destination node of the RPS request MUST send + an RPS request with its highest request code periodically along the + long path to the other node adjacent to the failure. + + In a unidirectional failure condition, the node that detects the + failure MUST send the RPS request in both directions with the + destination node set to the other node adjacent to the failure. The + destination node of the RPS request cannot detect the failure itself + but will receive an RPS request from both the short path and the long + path. The destination node MUST acknowledge the received RPS + requests by replying with an RPS request with the RR code on the + short path and an RPS request with the received RPS request code on + the long path. Accordingly, when the node that detects the failure + receives the RPS request with RR code on the short path, then the RPS + request received from the same node along the long path SHOULD be + ignored. + + A node in the switching state MUST terminate the received RPS + requests in both directions and not forward it further along the + ring. + + The following switches as defined in Section 5.3.1 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 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 still signal an RPS request with the MS code. + + Multiple EXER requests MUST be allowed to coexist in the ring. + + + + +Cheng, et al. Standards Track [Page 33] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + A node in a ring-switching state that receives the external command + 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 a relevant RPS request for another link. + +5.2.3.3. Pass-Through State + + When a node is in a pass-through state, it MUST transfer the received + RPS request unchanged 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.2.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 a received RPS request shall preempt existing + RPS requests in the prioritized order given in Section 5.2.2, unless + the requests are allowed to coexist. + +5.2.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. + + A node MUST revert from pass-through state to the idle state when an + RPS request with an NR code is received in both directions. Then + both directions revert simultaneously from the pass-through state to + the idle state. + +5.2.4.2. Transitions between Idle and Switching States + + 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 is destined to this node + + o An externally initiated command for this node + + + + +Cheng, et al. Standards Track [Page 34] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + 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 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 the appropriate request but + not execute the switch + + In one of the following conditions, transition from the switching + state to the idle state MUST be triggered: + + o On the node that triggers the protection switching, when the WTR + time expires or an externally initiated command is cleared, the + node MUST transit from switching state to Idle State and signal + the NR code using RPS message in both directions. + + o On the node that enters the switching state due to the received + RPS request: 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.2.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 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 + + o Another failure is detected + + o An externally initiated command becomes active + + The node MUST send out a WTR code on both the long and short paths. + + + + + + +Cheng, et al. Standards Track [Page 35] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + When a node that is executing a switch in response to an incoming SF + RPS request (not due to a locally detected failure) receives a WTR + code (unidirectional failure case), it MUST send out the RR code on + the short path and the WTR on the long path. + +5.2.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 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 + allowed coexisting automatic initiated command + + o The receipt of an equal, a higher priority, or an allowed + coexisting RPS request destined to this node + +5.3. RPS State Machine + +5.3.1. Switch Initiation Criteria + +5.3.1.1. Administrative Commands + + Administrative commands can be initiated by the network operator + through the Network Management System (NMS). The operator command + may be transmitted to the appropriate node via the MPLS-TP RPS + message. + + The following commands can be transferred by the RPS message: + + o Lockout of Protection (LP): This command prevents any protection + activity and prevents using ring switches anywhere in the ring. + If any ring switches exist in the ring, this command causes the + switches to drop. + + + + + + + + + + +Cheng, et al. Standards Track [Page 36] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + o Forced Switch (FS) to protection: This command performs the ring + switch of normal traffic from the working entity to 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 switch occurs regardless of the state of the MPLS-TP section + for the requested link, unless a higher-priority switch request + exists. + + o Manual Switch (MS) to protection: This command performs the ring + switch of the normal traffic from the working entity to 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 + link is not satisfying an equal or higher priority switch request. + + o Exercise (EXER): This command exercises ring protection switching + on the addressed link without completing the actual switch. The + command is issued and the responses (RRs) 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 WTR + timer 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 NR code. + + o Lockout of Working (LW): This command prevents the normal traffic + transported over the addressed link from being switched to the + protection entity by disabling the node's capability of requesting + a 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 + NR code is transmitted. This command has no impact on any other + 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.3.1.2. Automatically Initiated Commands + + Automatically initiated commands can be initiated based on MPLS-TP + section-layer OAM indication and the received switch requests. + + The node can initiate the following switch requests automatically: + + o Signal Fail (SF): This command is issued when the MPLS-TP section- + layer OAM detects a signal failure condition. + + + +Cheng, et al. Standards Track [Page 37] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + o Wait-to-Restore (WTR): This command is issued when the MPLS-TP + section detects that the SF condition has cleared. It is used to + maintain 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 38] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +5.3.2. Initial States + + This section describes the possible states of a ring node, the + corresponding action of the working and protection ring tunnels on + the node, and the RPS request that should be generated in that state. + + +-----------------------------------+----------------+ + | State | Signaled RPS | + +-----------------------------------+----------------+ + | A | Idle | NR | + | | Working: no switch | | + | | Protection: no switch | | + +-----+-----------------------------+----------------+ + | 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 | | + +-----+-----------------------------+----------------+ + | E | Switching - FS | FS | + | | Working: switched | | + | | Protection: switched | | + +-----+-----------------------------+----------------+ + | F | Switching - SF | SF | + | | Working: switched | | + | | Protection: switched | | + +-----+-----------------------------+----------------+ + | G | Switching - MS | MS | + | | Working: switched | | + | | Protection: switched | | + +-----+-----------------------------+----------------+ + | H | Switching - WTR | WTR | + | | Working: switched | | + | | Protection: switched | | + +-----+-----------------------------+----------------+ + | I | Switching - EXER | EXER | + | | Working: no switch | | + | | Protection: no switch | | + +-----+-----------------------------+----------------+ + + + + + + +Cheng, et al. Standards Track [Page 39] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +5.3.3. State Transitions When Local Request Is Applied + + In the state description below, 'O' means that a new local request + will be rejected because of an existing request. + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + A (Idle) LP C (Switching - LP) + LW D (Idle - LW) + 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-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 + G (Switching - MS) - otherwise + Clear N/A + WTR expires N/A + EXER O + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 40] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + 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-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 link + D (Idle - LW) - if on another + link + FS O - if on the same link + E (Switching - FS) - if on + another link + SF O - if on the addressed link + F (Switching - SF) - if on + another link + Recover from SF N/A + MS O - if on the same link + G (Switching - MS) - if on + another link + Clear A (Idle) - if there is no + failure on addressed link + F (Switching - SF) - if there + is a failure on this link + WTR expires N/A + EXER O + + + + + + + + + + + +Cheng, et al. Standards Track [Page 41] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + E (Switching - FS) LP C (Switching - LP) + LW O - if on another link + D (Idle - LW) - if on the same + link + FS N/A - if on the same link + E (Switching - FS) - if on + another link + SF O - if on the addressed link + E (Switching - FS) - if on + 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 link + D (Idle - LW) - if on the same + link + FS E (Switching - FS) + SF N/A - if on the same link + F (Switching - SF) - if on + another link + Recover from SF H (Switching - WTR) + MS O + Clear N/A + WTR expires N/A + EXER O + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 42] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + G (Switching - MS) LP C (Switching - LP) + LW O - if on another link + D (Idle - LW) - if on the same + link + FS E (Switching - FS) + SF F (Switching - SF) + Recover from SF N/A + MS N/A - if on the same link + G (Switching - MS) - if on + 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) + SF F (Switching - SF) + Recover from SF N/A + MS G (Switching - MS) + Clear A + WTR expires A + EXER O + ===================================================================== + 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 link + I (Switching - EXER) + ===================================================================== + + + + + + + + +Cheng, et al. Standards Track [Page 43] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +5.3.4. State Transitions When Remote Request is Applied + + The priority of a remote request does not depend on the side from + which the request is received. + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + A (Idle) LP C (Switching - LP) + FS E (Switching - FS) + SF F (Switching - SF) + 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-through) LP C (Switching - LP) + FS N/A - cannot happen when there + is an LP request in the + ring + E (Switching - FS) - otherwise + SF N/A - cannot happen when there + is an LP request in the + ring + F (Switching - SF) - otherwise + MS N/A - cannot happen when there + is an LP, FS, or SF + request in the ring + G (Switching - MS) - otherwise + WTR N/A - cannot happen when there + is an LP, FS, SF, or MS + request in the ring + EXER N/A - cannot happen when there + is an LP, FS, SF, MS, or + a WTR request in the + ring + I (Switching - EXER) - + otherwise + RR N/A + NR A (Idle) - if received from + both sides + + + + + + + +Cheng, et al. Standards Track [Page 44] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + C (Switching - LP) LP C (Switching - LP) + + FS N/A - cannot happen when there + is an LP request in the + ring + SF N/A - cannot happen when there + is an LP request in the + ring + MS N/A - cannot happen when there + is an LP request in the + ring + WTR N/A + EXER N/A - cannot happen when there + is an LP request in the + ring + RR C (Switching - LP) + NR N/A + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + D (Idle - LW) LP C (Switching - LP) + FS E (Switching - FS) + SF F (Switching - SF) + MS G (Switching - MS) + WTR N/A + EXER I (Switching - EXER) + RR N/A + NR D (Idle - LW) + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + E (Switching - FS) LP C (Switching - LP) + FS E (Switching - FS) + SF E (Switching - FS) + MS N/A - cannot happen when there + is an FS request in the + ring + WTR N/A + EXER N/A - cannot happen when there + is an FS request in the + ring + RR E (Switching - FS) + NR N/A + + + + + +Cheng, et al. Standards Track [Page 45] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + F (Switching - SF) LP C (Switching - LP) + FS F (Switching - SF) + SF F (Switching - SF) + MS N/A - cannot happen when there + is an SF request in the + ring + WTR N/A + EXER N/A - cannot happen when there + is an SF request in the + ring + RR F (Switching - SF) + NR N/A + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + G (Switching - MS) LP C (Switching - LP) + FS E (Switching - FS) + SF F (Switching - SF) + MS G (Switching - MS) - release + the switches but signal MS + WTR N/A + EXER N/A - cannot happen when there + is an MS request in the + ring + RR G (Switching - MS) + NR N/A + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + H (Switching - WTR) LP C (Switching - LP) + FS E (Switching - FS) + SF F (Switching - SF) + MS G (Switching - MS) + WTR H (Switching - WTR) + EXER N/A - cannot happen when there + is a WTR request in the + ring + RR H (Switching - WTR) + NR N/A + + + + + + + + + +Cheng, et al. Standards Track [Page 46] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + I (Switching - EXER) LP C (Switching - LP) + FS E (Switching - FS) + SF F (Switching - SF) + MS G (Switching - MS) + WTR N/A + EXER I (Switching - EXER) + RR I (Switching - EXER) + NR N/A + ===================================================================== + + +5.3.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-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 + + + + + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 47] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + B (Pass-through) LP B (Pass-through) + FS N/A - cannot happen when there + is an LP request in the + ring + B (Pass-through) - otherwise + SF N/A - cannot happen when there + is an LP request in the + ring + B (Pass-through) - otherwise + MS N/A - cannot happen when there + is an LP, FS, or SF + request in the ring + B (Pass-through) - otherwise + WTR N/A - cannot happen when there + is an LP, FS, SF, or MS + request in the ring + B (Pass-through) - otherwise + EXER N/A - cannot happen when there + is an LP, FS, SF, MS, or + a WTR request in the + ring + B (Pass-through) - otherwise + RR N/A + NR N/A + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + C (Switching - LP) LP C (Switching - LP) + FS N/A - cannot happen when there + is an LP request in the + ring + SF N/A - cannot happen when there + is an LP request in the + ring + MS N/A - cannot happen when there + is an LP request in the + ring + WTR N/A - cannot happen when there + is an LP request in the + ring + EXER N/A - cannot happen when there + is an LP request in the + ring + RR N/A + NR N/A + + + +Cheng, et al. Standards Track [Page 48] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + 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-through) + FS E (Switching - FS) + SF E (Switching - FS) + MS N/A - cannot happen when there + is an FS request in the + ring + WTR N/A - cannot happen when there + is an FS request in the + ring + EXER N/A - cannot happen when there + is an FS request in the + ring + RR N/A + NR N/A + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + F (Switching - SF) LP B (Pass-through) + FS F (Switching - SF) + SF F (Switching - SF) + MS N/A - cannot happen when there + is an SF request in the + ring + WTR N/A - cannot happen when there + is an SF request in the + ring + EXER N/A - cannot happen when there + is an SF request in the + ring + RR N/A + NR N/A + + + + + + +Cheng, et al. Standards Track [Page 49] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + 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 an MS request in the + ring + EXER N/A - cannot happen when there + is an MS request in the + ring + RR N/A + NR N/A + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + 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 a WTR request in the + ring + RR N/A + NR N/A + ===================================================================== + Initial state New request New state + ------------- ----------- --------- + 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 + ===================================================================== + + + + + + + + + + +Cheng, et al. Standards Track [Page 50] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +6. IANA Considerations + + IANA has assigned the values listed in the sections below. + +6.1. G-ACh Channel Type + + The Channel Types for G-ACh are allocated from the PW Associated + Channel Type registry defined in [RFC4446] and updated by [RFC5586]. + + IANA has allocated the following new G-ACh Channel Type in the "MPLS + Generalized Associated Channel (G-ACh) Types (including Pseudowire + Associated Channel Types)" registry: + + Value | Description | Reference + -------+---------------------------------+-------------- + 0x002A | Ring Protection Switching (RPS) | this document + | Protocol | + -------+---------------------------------+-------------- + +6.2. RPS Request Codes + + IANA has created the subregistry "MPLS RPS Request Code Registry" + under the "Generic Associated Channel (G-ACh) Parameters" registry. + All code points within this registry shall be allocated according to + the "Specification Required" procedure as specified in [RFC8126]. + + 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 Unassigned + 3 Exercise (EXER) this document + 4 Unassigned + 5 Wait-to-Restore (WTR) this document + 6 Manual Switch (MS) this document + 7-10 Unassigned + 11 Signal Fail (SF) this document + 12 Unassigned + 13 Forced Switch (FS) this document + 14 Unassigned + 15 Lockout of Protection (LP) this document + 16-254 Unassigned + 255 Reserved + + + + + + +Cheng, et al. Standards Track [Page 51] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +7. Operational Considerations + + This document describes three protection modes of the RPS protocol. + Operators could choose the appropriate protection mode according to + their network and service requirement. + + Wrapping mode provides a ring protection mechanism in which the + protected traffic will reach every node of the ring and is applicable + to protect both the point-to-point LSPs and LSPs that need to be + dropped in several ring nodes, i.e., the point-to-multipoint + applications. When protection is inactive, the protected traffic is + switched (wrapped) to/from the protection ring tunnel at both sides + of the defective link/node. Due to the wrapping, the additional + propagation delay and bandwidth consumption of the protection tunnel + are considerable. For bidirectional LSPs, the protected traffic in + both directions is co-routed. + + Short-wrapping mode provides a ring protection mechanism that can be + used to protect only point-to-point LSPs. When protection is + inactive, the protected traffic is wrapped to the protection ring + tunnel at the defective link/node and leaves the ring when the + protection ring tunnel reaches the egress node. Compared with the + wrapping mode, short-wrapping can reduce the propagation latency and + bandwidth consumption of the protection tunnel. However, the two + directions of a protected bidirectional LSP are not totally co- + routed. + + Steering mode provides a ring protection mechanism that can be used + to protect only point-to-point LSPs. When protection is inactive, + the protected traffic is switched to the protection ring tunnel at + the ingress node and leaves the ring when the protection ring tunnel + reaches the egress node. The steering mode has the least propagation + delay and bandwidth consumption of the three modes, and the two + directions of a protected bidirectional LSP can be kept co-routed. + + Note that only one protection mode can be provisioned in the whole + ring for all protected traffic. + +8. Security Considerations + + MPLS-TP is a subset of MPLS, thus it builds upon many of the aspects + of the security model of MPLS. Please refer to [RFC5920] for generic + MPLS security issues and methods for securing traffic privacy and + integrity. + + The RPS message defined in this document is used for protection + coordination on the ring; if it is injected or modified by an + attacker, the ring nodes might not agree on the protection action, + + + +Cheng, et al. Standards Track [Page 52] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + and the improper protection-switching action may cause a temporary + break to services traversing the ring. It is important that the RPS + message is used within a trusted MPLS-TP network domain as described + in [RFC6941]. + + The RPS message is carried in the G-ACh [RFC5586], so it is dependent + on the security of the G-ACh itself. The G-ACh is a generalization + of the Associated Channel defined in [RFC4385]. Thus, this document + relies on the security mechanisms provided for the Associated Channel + as described in those two documents. + + As described in the security considerations of [RFC6378], the G-ACh + is essentially connection oriented, so injection or modification of + control messages requires the subversion of a transit node. Such + subversion is generally considered hard in connection-oriented MPLS + networks and impossible to protect against at the protocol level. + Management-level techniques are more appropriate. The procedures and + protocol extensions defined in this document do not affect the + security model of MPLS-TP linear protection as defined in [RFC6378]. + +9. References + +9.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, + . + + [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, + "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for + Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, + February 2006, . + + [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge + Emulation (PWE3)", BCP 116, RFC 4446, + DOI 10.17487/RFC4446, April 2006, + . + + [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., + "MPLS Generic Associated Channel", RFC 5586, + DOI 10.17487/RFC5586, June 2009, + . + + + +Cheng, et al. Standards Track [Page 53] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + + [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., + Sprecher, N., and S. Ueno, "Requirements of an MPLS + Transport Profile", RFC 5654, DOI 10.17487/RFC5654, + September 2009, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + +9.2. Informative References + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + . + + [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, + Administration, and Maintenance Framework for MPLS-Based + Transport Networks", RFC 6371, DOI 10.17487/RFC6371, + September 2011, . + + [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, + N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- + TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, + October 2011, . + + [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., + and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) + Security Framework", RFC 6941, DOI 10.17487/RFC6941, April + 2013, . + + [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., + Fondelli, F., Corsi, M., Wu, B., and X. Dai, + "Applicability of MPLS Transport Profile for Ring + Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013, + . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + + + + + + + + + + +Cheng, et al. Standards Track [Page 54] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +Acknowledgements + + The authors would like to thank Gregory Mirsky, Yimin Shen, Eric + Osborne, Spencer Jackson, and Eric Gray for their valuable comments + and suggestions. + +Contributors + + The following people contributed significantly to the content of this + document and should be considered co-authors: + + Kai Liu + Huawei Technologies + Email: alex.liukai@huawei.com + + Jia He + Huawei Technologies + Email: hejia@huawei.com + + Fang Li + China Academy of Telecommunication Research MIIT + China + Email: lifang@catr.cn + + Jian Yang + ZTE Corporation + 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 + + + +Cheng, et al. Standards Track [Page 55] + +RFC 8227 MSRP Protection Mechanism for Ring Topology August 2017 + + +Authors' Addresses + + Weiqiang Cheng + China Mobile + + Email: chengweiqiang@chinamobile.com + + + Lei Wang + China Mobile + + Email: wangleiyj@chinamobile.com + + + Han Li + China Mobile + + Email: lihan@chinamobile.com + + + Huub van Helvoort + Hai Gaoming BV + + Email: huubatwork@gmail.com + + + Jie Dong + Huawei Technologies + + Email: jie.dong@huawei.com + + + + + + + + + + + + + + + + + + + + + +Cheng, et al. Standards Track [Page 56] + -- cgit v1.2.3