tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 8227

Proposed STD
Pages: 56
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MPLS

MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology

Part 1 of 4, p. 1 to 11
None       Next Section

 


Top       ToC       Page 1 
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.

Top      ToC       Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
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.

Top      ToC       Page 5 
   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.

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
                                              +-------------
                                +-------------|
                  +-------------|             |
    ===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

Top      ToC       Page 8 
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

Top      ToC       Page 9 
                       +---+#############+---+
                       | 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

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
   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)

Next Section