RFC 8227
MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology
Pages: 56
Proposed Standard
Proposed Standard
Part 1 of 4 – Pages 1 to 11
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 TopologyAbstract
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.
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.
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
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.
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.
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.
+------------- +-------------| +-------------| | ===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
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
+---+#############+---+ | 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
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 MSRP4.2. Failure Detection
The MPLS-TP section-layer OAM is used to monitor the connectivity between each two adjacent nodes on the ring using the mechanisms defined in [RFC6371]. Protection switching is triggered by the failure detected on the ring by the OAM mechanisms.
Two 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.
(page 11 continued on part 2)