summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8227.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8227.txt')
-rw-r--r--doc/rfc/rfc8227.txt3139
1 files changed, 3139 insertions, 0 deletions
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<d><p><X> where <d> = c (clockwise) or a
+ (anticlockwise), <p> = W (working) or P (protecting), and <X> =
+ 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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+ Label Switching Architecture", RFC 3031,
+ DOI 10.17487/RFC3031, January 2001,
+ <https://www.rfc-editor.org/info/rfc3031>.
+
+ [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, <https://www.rfc-editor.org/info/rfc4385>.
+
+ [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+ Emulation (PWE3)", BCP 116, RFC 4446,
+ DOI 10.17487/RFC4446, April 2006,
+ <https://www.rfc-editor.org/info/rfc4446>.
+
+ [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
+ "MPLS Generic Associated Channel", RFC 5586,
+ DOI 10.17487/RFC5586, June 2009,
+ <https://www.rfc-editor.org/info/rfc5586>.
+
+
+
+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, <https://www.rfc-editor.org/info/rfc5654>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2. Informative References
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+ Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
+ <https://www.rfc-editor.org/info/rfc5920>.
+
+ [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, <https://www.rfc-editor.org/info/rfc6371>.
+
+ [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, <https://www.rfc-editor.org/info/rfc6378>.
+
+ [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, <https://www.rfc-editor.org/info/rfc6941>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc6974>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+
+
+
+
+
+
+
+
+
+
+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]
+