doc: Add RFC documents

1 files changed, 1683 insertions, 0 deletions

diff --git a/doc/rfc/rfc6974.txt b/doc/rfc/rfc6974.txt
new file mode 100644
index 0000000..1bc2857
--- /dev/null
+++ b/doc/rfc/rfc6974.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                     Y. Weingarten
+Request for Comments: 6974
+Category: Informational                                        S. Bryant
+ISSN: 2070-1721                                            Cisco Systems
+                                                           D. Ceccarelli
+                                                             D. Caviglia
+                                                             F. Fondelli
+                                                                Ericsson
+                                                                M. Corsi
+                                                                  Altran
+                                                                   B. Wu
+                                                         ZTE Corporation
+                                                                  X. Dai
+                                                               July 2013
+
+
+      Applicability of MPLS Transport Profile for Ring Topologies
+
+Abstract
+
+   This document presents an applicability of existing MPLS protection
+   mechanisms, both local and end-to-end, to the MPLS Transport Profile
+   (MPLS-TP) in ring topologies.  This document does not propose any new
+   mechanisms or protocols.  Requirements for MPLS-TP protection
+   especially for protection in ring topologies are discussed in
+   "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS
+   Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372).
+   This document discusses how most of the requirements are met by
+   applying linear protection as defined in RFC 6378 in a ring topology.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   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/rfc6974.
+
+
+
+
+
+
+Weingarten, et al.            Informational                     [Page 1]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Problem Statement  . . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Scope of the Document  . . . . . . . . . . . . . . . . . .  4
+     1.3.  Terminology and Notation . . . . . . . . . . . . . . . . .  5
+   2.  Point-to-Point (P2P) Ring Protection . . . . . . . . . . . . .  6
+     2.1.  Wrapping . . . . . . . . . . . . . . . . . . . . . . . . .  6
+     2.2.  Steering . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     2.3.  SPME for P2P Protection of a Ring Topology . . . . . . . . 10
+       2.3.1.  Path SPME for Steering . . . . . . . . . . . . . . . . 11
+       2.3.2.  Wrapping Link Protection with Segment-Based SPME . . . 12
+       2.3.3.  Wrapping Node Protection . . . . . . . . . . . . . . . 13
+       2.3.4.  Wrapping for Link and Node Protection  . . . . . . . . 14
+     2.4.  Analysis of P2P Protection . . . . . . . . . . . . . . . . 15
+       2.4.1.  Recommendations for Protection of P2P Paths
+               Traversing a Ring  . . . . . . . . . . . . . . . . . . 16
+   3.  Point-to-Multipoint Protection . . . . . . . . . . . . . . . . 17
+     3.1.  Wrapping for P2MP LSPs . . . . . . . . . . . . . . . . . . 17
+       3.1.1.  Comparison of Wrapping and ROM-Wrapping  . . . . . . . 19
+       3.1.2.  Multiple Failures Comparison . . . . . . . . . . . . . 20
+     3.2.  Steering for P2MP Paths  . . . . . . . . . . . . . . . . . 21
+       3.2.1.  Context Labels . . . . . . . . . . . . . . . . . . . . 21
+       3.2.2.  Walk-Through Using Context Labels  . . . . . . . . . . 23
+   4.  Coordination Protocol  . . . . . . . . . . . . . . . . . . . . 26
+   5.  Conclusions and Recommendations  . . . . . . . . . . . . . . . 26
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 27
+   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 29
+   Appendix B.  Contributors  . . . . . . . . . . . . . . . . . . . . 29
+
+
+
+
+Weingarten, et al.            Informational                     [Page 2]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+1.  Introduction
+
+   The MPLS Transport Profile (MPLS-TP) has been standardized as part of
+   a joint effort between the Internet Engineering Task Force (IETF) and
+   the International Telecommunications Union Telecommunications
+   Standardization Sector (ITU-T).  These specifications are based on
+   the requirements that were generated from this joint effort.
+
+   The MPLS-TP requirement document [RFC5654] includes a requirement to
+   support a network that may include subnetworks that constitute an
+   MPLS-TP ring as defined in the document.  However, the document does
+   not identify any protection requirements specific to a ring topology.
+   The requirements state that specific protection mechanisms applying
+   to ring topologies may be developed if these allow the network to
+   minimize:
+
+   o  the number of OAM entities needed to trigger the protection
+
+   o  the number of elements of recovery needed
+
+   o  the number of labels required
+
+   o  the number of control- and management-plane transactions during a
+      maintenance operation
+
+   o  the impact of signaling and routing information exchanged during
+      protection, in the presence of a control plane
+
+   This document describes how applying a set of basic MPLS-TP linear
+   protection mechanisms defined in [RFC6378] can be used to provide
+   protection of the data flows that traverse an MPLS-TP ring.  These
+   mechanisms provide data flow protection due to any switching trigger
+   within a reasonable time frame and optimize the criteria set out in
+   [RFC5654], as summarized above.  This document does not define any
+   new protocol mechanisms or procedures.
+
+   A related topic in [RFC5654] addresses the required support for
+   interconnected rings.  This topic involves various scenarios that
+   require further study and will be addressed in a separate document,
+   based on the principles outlined in this document.
+
+1.1.  Problem Statement
+
+   Ring topologies, as defined in [RFC5654], are used in transport
+   networks.  When designing a protection mechanism for a single ring
+   topology, there is a need to address both of the following cases.
+
+
+
+
+
+Weingarten, et al.            Informational                     [Page 3]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   1.  A point-to-point transport path that originates at a ring node or
+       enters an MPLS-TP-capable ring at a single ingress node, and
+       exits the ring at a single egress node, and possibly continues
+       beyond the ring.
+
+   2.  Where the ring is being used as a branching point for a point-to-
+       multipoint transport path, i.e., the transport path originates at
+       or enters the MPLS-TP-capable ring at the ingress node and exits
+       through a number of egress nodes, possibly continuing beyond the
+       ring.
+
+   In either of these two situations, there is a need to address the
+   following different cases.
+
+   1.  One of the ring links causes a fault condition.  This could be
+       either a unidirectional or bidirectional fault, and it should be
+       detected by the neighboring nodes.
+
+   2.  One of the ring nodes causes a fault condition.  This condition
+       is invariably a bidirectional fault (although in rare cases of
+       misconfiguration, this could be detected as a unidirectional
+       fault), and it should be detected by the two neighboring ring
+       nodes.
+
+   3.  An operator command is issued to a specific ring node; it either
+       changes the operational state of a node or a link or explicitly
+       triggers a protection action.  An operator command changes the
+       operational state of a node or a link, or specifically triggers a
+       protection action is issued to a specific ring node.  A
+       description of the different operator commands is found in
+       Section 4.13 of [RFC4427].  Examples of these commands include
+       Manual Switch, Forced Switch, and Clear operations.
+
+   The protection domain addressed in this document is limited to the
+   traffic that traverses on the ring.  Protection triggers on the
+   transport path prior to the ingress node of the ring or beyond the
+   egress nodes may be protected by some other mechanism.
+
+1.2.  Scope of the Document
+
+   This document addresses the requirements that appear in Section
+   2.5.6.1 of [RFC5654] on ring protection, based on the application of
+   the linear protection as defined in [RFC6378].  Requirement R93
+   regarding the support of interconnected rings and protection of
+   faults in the interconnection nodes and links is for further study.
+
+
+
+
+
+
+Weingarten, et al.            Informational                     [Page 4]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   In addition, requirement R105 requiring the support of lockout of
+   specific nodes or spans is only supported to the degree that it is
+   supported by the linear protection mechanism.
+
+1.3.  Terminology and Notation
+
+   The terminology used in this document is based on the terminology
+   defined in the MPLS-TP framework documents:
+
+   o  MPLS-TP framework [RFC5921]
+
+   o  MPLS-TP OAM framework [RFC6371]
+
+   o  MPLS-TP survivability framework [RFC6372]
+
+   The MPLS-TP framework document [RFC5921] defines a Sub-Path
+   Maintenance Entity (SPME) construct that can be defined between any
+   two Label Switching Routers (LSRs) of an MPLS-TP Label Switched Path
+   (LSP).  This SPME may be configured as a co-routed bidirectional
+   path.  The SPME is defined to allow management and monitoring of any
+   segment of a transport path.  This concept will be used extensively
+   throughout the document to support protection of the traffic that
+   traverses an MPLS-TP ring.
+
+   In addition, we describe the use of the label stack in connection
+   with the redirecting of data packets by the protection mechanism.
+   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
+       levels; however, we only present the levels that are germane to
+       the protection mechanism.
+
+   3.  When applicable, the S bit (signifying that a given label is the
+       bottom of the label stack) will be denoted by the string '+S'
+       within the label.  If a label is not shown with '+S' , that label
+       may or may not be the bottom label in the stack. '+S' is only
+       shown when it is important to illustrate that a given label is
+       definitely the last one in the label stack.
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                     [Page 5]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   4.  The label of the LSP at the ingress node of the ring will be
+       denoted by the string "LI", and the label of the LSP that is
+       expected at the egress point from the ring will be denoted by the
+       string "LE".  "LSE" will denote the label expected at the exit
+       LSR of a SPME (if it is different from the egress point from the
+       ring, for example, as described in Section 2.3).
+
+   5.  The label Pxi(y) in the stack denotes the label that LSR-x would
+       use to transport the packet to LSR-y over the SPME whose index is
+       i.
+
+   For example:
+
+   o  The label stack [LI] denotes the label stack received at the
+      ingress node of the ring.  There may be additional labels after
+      LI, e.g., a PW label; however, this is irrelevant to the
+      discussion of the protection scenario.
+
+   o  [PB1(G) | LE] denotes a stack whose top label is the SPME-1 label
+      for LSR-B to transmit the data packet to LSR-G, and the second
+      label is the label that would be used by the egress LSR to
+      continue to transmit the packet on the original LSP.
+
+   o  If "LE" were the bottom label in the stack, then the label stack
+      would be shown as [PB1(G) | LE+S].
+
+2.  Point-to-Point (P2P) Ring Protection
+
+   There are two protection architecture mechanisms -- "Wrapping" and
+   "Steering" -- that have historically been applied to ring topologies,
+   based on Synchronous Digital Hierarchy (SDH) specifications [G.841],
+   and have been proposed in various forums to perform recovery of a
+   topological ring network.  The following subsections examine these
+   two mechanisms, as applied to an MPLS transport network.
+
+2.1.  Wrapping
+
+   Wrapping is defined as a local protection architecture.  This
+   mechanism is local to the nodes that are neighbors to the detected
+   fault.  When a fault is detected (either a link or node failure), the
+   neighboring node can identify that the fault would prevent forwarding
+   of the data along the data path.  Therefore, in order to continue to
+   transmit the data along the path, there is a need to "wrap" all data
+   traffic around the ring, on an alternate data path, until the arrives
+   at the node that is on the opposite side of the fault.  When this
+   far-side node also detects that there is a fault condition on the
+   working path, it can identify that the data traffic that is arriving
+   on the alternate (protecting) data path is intended for the "broken"
+
+
+
+Weingarten, et al.            Informational                     [Page 6]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   data path.  Therefore, again making a local decision, the far-side
+   node can wrap the data back onto the normal working path until the
+   egress from the ring segment.
+
+   Wrapping behavior is similar to MPLS-TE Fast Reroute, as defined in
+   [RFC4090], which uses either bypass or detour tunnels.  Applying Fast
+   Reroute to MPLS, it is possible to wrap all LSPs using a bypass
+   tunnel and a single label, or to wrap the traffic of each LSP around
+   the failed links via a detour tunnel using a different label for each
+   LSP.
+
+                       ___ ######## ___ ######## ___
+               ======>/LSR\********/LSR\***XX***/LSR\
+                      \_B_/@@@@@@@@\_A_/        \_F_/
+                        *@                       #*@
+                        *@                       #*@
+                        *@                       #*@
+                       _*@          ___          #*@
+                      /LSR\********/LSR\********/LSR\======>
+                      \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
+
+                 ===> connected LSP  *** physical link
+                 ###  working path   @@@ wrapped data path
+
+                Figure 1: Wrapping Protection for P2P Path
+
+   Consider the LSP that is shown in Figure 1 that enters the ring of
+   LSRs at LSR-B and exits at LSR-E.  The normal working path LSP
+   follows through LSRs B-A-F-E.  If a fault is detected on the link
+   A<->F, then the wrapping mechanism decides that LSR-A would wrap the
+   traffic around the ring, on a wrapped data path A-B-C-D-E-F, to
+   arrive at LSR-F (on the far side of the failed link).  LSR-F would
+   then wrap the data packets back onto the working path F->E to the
+   egress node.  In this protection scheme, the traffic will follow the
+   path B-A-B-C-D-E-F-E.
+
+   This protection scheme is simple in the sense that there is no need
+   for coordination between the different LSRs in the ring -- only the
+   LSRs that detect the fault must wrap the traffic, either onto the
+   wrapped data path (at the near end) or back to the working path (at
+   the far end).  However, coordination of the switchover to the
+   protection path would be needed to maintain the traffic on a co-
+   routed bidirectional LSP even in cases of a unidirectional fault
+   condition.
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                     [Page 7]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   The following considerations should be taken into account when
+   considering use of wrapping protection:
+
+   o  Detection of mis-connectivity or loss of continuity should be
+      performed at the link level and/or per LSR when using node-level
+      protection.  Configuration of the protection being performed
+      (i.e., link protection or node protection) needs to be performed a
+      priori, since the configuration of the proper protection path is
+      dependent upon this decision.
+
+   o  There is a need to define a data path that traverses the alternate
+      path around the ring to connect between the two neighbors of the
+      detected fault.  If protecting both the links and the nodes of an
+      LSP, then, for a ring with N nodes, there is a need for O(2N)
+      alternate paths.
+
+   o  When wrapping, the data is transmitted over some of the links
+      twice, once in each direction.  For example, in the figure above
+      the traffic is transmitted both B->A and then A->B, and later it
+      is transmitted E->F and F->E.  This means that there is additional
+      bandwidth needed for this protection.
+
+   o  If a double-fault situation occurs in the ring, then wrapping will
+      not be able to deliver any packets except between the ingress and
+      the first fault location encountered on the working path.  This is
+      based on the need for wrapping to connect between the neighbors of
+      the fault location, and this is not possible in the segmented
+      ring.
+
+   o  The resource pre-allocation for all of the alternate paths could
+      be problematic (causing massive over subscription of the available
+      resources).  However, since most of these alternate paths will not
+      be used simultaneously, there is the possibility of allocating
+      zero resources and depending on the Network Management System
+      (NMS) to allocate the proper resources around the ring, based on
+      actual traffic usage.
+
+   o  Wrapping also involves a small increase in traffic latency in
+      delivering the packets, as a result of traversing the entire ring,
+      during protection.
+
+2.2.  Steering
+
+   The second common scheme for ring protection, steering, takes
+   advantage of the ring topology by defining two paths from the ingress
+   node of the ring to the egress point going in opposite directions
+   around the ring.  This is illustrated in Figure 2, where if we assume
+   that the traffic needs to enter the ring from node B and exit through
+
+
+
+Weingarten, et al.            Informational                     [Page 8]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   node F, we could define a primary path through nodes B-A-F, and an
+   alternate path through the nodes B-C-D-E-F.  In steering, the
+   switching is always performed by the ingress node (node B in
+   Figure 2).  If a fault condition is detected anywhere on the working
+   path (B-A-F), then the traffic would be redirected by B to the
+   alternate path (i.e., B-C-D-E-F).
+
+                       ___          ___          ___
+               ======>/LSR\********/LSR\********/LSR\======>
+                      \_B_/########\_A_/########\_F_/
+                        *@                       @*
+                        *@                       @*
+                        *@                       @*
+                       _*@          ___          @*_
+                      /LSR\********/LSR\********/LSR\
+                      \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
+
+                ===> connected LSP     *** physical link
+                ###  working path      @@@ protection path
+
+             Figure 2: Steering Protection in an MPLS-TP Ring
+
+   This mechanism bears similarities to linear 1:1 protection [RFC6372].
+   The two paths around the ring act as the working and protection
+   paths.  This requires that the ingress node be informed of the need
+   to switch over to the protection path, and also that the ingress and
+   egress nodes coordinate the switchover.  There is need to communicate
+   to the ingress node the need to switch over to the protection path
+   and there is a need to coordinate the switchover between the two
+   endpoints of the protected domain.
+
+   The following considerations must be taken into account regarding the
+   steering architecture:
+
+   o  Steering relies on a failure detection method that is able to
+      notify the ingress node of the fault condition.  This may involve
+      OAM functionality described in [RFC6371], e.g., Remote Defect
+      Indication, alarm reporting.
+
+   o  The process of notifying the ingress node adds to the latency of
+      the protection-switching process, after the detection of the fault
+      condition.
+
+   o  While there is no need for double bandwidth for the data path,
+      there is the necessity for the ring to maintain enough capacity
+      for all of the data in both directions around the ring.
+
+
+
+
+
+Weingarten, et al.            Informational                     [Page 9]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+2.3.  SPME for P2P Protection of a Ring Topology
+
+   The SPME concept was introduced by [RFC5921] to support management
+   and monitoring an arbitrary segment of a transport.  However, an SPME
+   is essentially a valid LSP that may be used to aggregate all LSP
+   traffic that traverses the sub-path delineated by the SPME.  An SPME
+   may be monitored using the OAM mechanisms as described in the MPLS-TP
+   OAM framework document [RFC6371].
+
+   When defining an MPLS-TP ring as a protection domain, there is a need
+   to design a protection mechanism that protects all the LSPs that
+   cross the MPLS-TP ring.  For this purpose, we associate a (working)
+   SPME with the segment of the transport path that traverses the ring.
+   In addition, we configure an alternate (protecting) SPME that
+   traverses the ring in the opposite direction around the ring.  The
+   exact selection of the SPMEs is dependent on the types of transport
+   path and protection that are being implemented.  This will be
+   detailed in the following subsections.
+
+   Based on this architectural configuration for protection of ring
+   topologies, it is possible to limit the number of alternate paths
+   needed to protect the data traversing the ring.  In addition, since
+   we will perform all of the OAM functionality on the SPME configured
+   for the traffic, we can minimize the number of OAM sessions needed to
+   monitor the data traffic of the ring, rather than monitoring each
+   individual LSP.
+
+   In all of the following subsections, we use 1:1 linear protection
+   [RFC6372] [RFC6378] to perform protection switching and coordination
+   when a signal fault is detected.  The actual configuration of the
+   SPMEs used may change depending upon the choice of methodology, and
+   this will be detailed in the following sections.  However, in all of
+   these configurations, the mechanism will be to transmit the data
+   traffic on the primary SPME, while applying OAM functionality over
+   both the primary and the secondary SPME to detect signal fault
+   conditions on either path.  If a signal fault is detected on the
+   primary SPME, then the mechanism described in [RFC6378] shall be used
+   to coordinate a switchover of data traffic to the secondary SPME.
+
+   Assuming that the SPME is implemented as an hierarchical LSP, packets
+   that arrive at LSR-B with a label stack [LI] will have the SPME label
+   pushed at LSR-B, and the LSP label will be swapped for the label that
+   is expected by the egress LSR (i.e., the packet will arrive at LSR-A
+   with a label stack of [PA1(B) | LE] and arrive at LSR-F with [PE1(F)
+   | LE]).  The SPME label will be popped by LSR-F, and the LSP label
+   will be treated appropriately at LSR-F and forwarded along the LSP,
+   outside the ring.  This scenario is true for all LSPs that are
+   aggregated by this primary SPME.
+
+
+
+Weingarten, et al.            Informational                    [Page 10]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+2.3.1.  Path SPME for Steering
+
+   A P2P SPME that traverses part of a ring has two Maintenance Entity
+   Group End Points (MEPs), each one acts as the ingress and egress in
+   one direction of the bidirectional SPME.  Since the SPME is
+   traversing a ring, we can take advantage of another characteristic of
+   a ring -- there is always an alternative path between the two MEPs,
+   i.e., traversing the ring in the opposite direction.  This
+   alternative SPME can be defined as the protection path for the
+   working path that is configured as part of the LSP and defined as a
+   SPME.
+
+   For each pair of SPMEs that are defined in this way, it is possible
+   to verify the connectivity and continuity by applying the MPLS-TP OAM
+   functionality to both the working and protection SPME.  If a
+   discontinuity or mis-connectivity is detected, then the MEPs will
+   become aware of this condition and could perform a protection switch
+   of all LSPs to the alternate, protection SPME.
+
+   The following figure shows an MPLS-TP ring that is part of a larger
+   MPLS-TP network.  The ring could be used as a network segment that
+   may be traversed by numerous LSPs.  In particular, the figure shows
+   that for all LSPs that connect to the ring at LSR-B and exit the ring
+   from LSR-F, we configure two SPMEs through the ring (the first SPME
+   traverses B-A-F, and the second SPME traverses B-C-D-E-F).
+
+                       ___          ___          ___
+                =====>/LSR\********/LSR\********/LSR\======>
+                      \_B_/########\_A_/########\_F_/
+                        *@                       @*
+                        *@                       @*
+                        *@                       @*
+                       _*@          ___          @*_
+                      /LSR\********/LSR\********/LSR\
+                      \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
+
+                 ===> connected LSP    *** physical link
+                 ###  primary SPME     @@@ secondary SPME
+
+                         Figure 3: An MPLS-TP Ring
+
+   This protection mechanism is identical to the application of 1:1
+   linear protection [RFC6372] [RFC6378] to the pair of SPMEs.  Under
+   normal conditions, all LSP data traffic will be transmitted on the
+   working SPME.  If the linear protection is triggered by the OAM
+   indication, another fault indication trigger, or an operator command,
+   then the MEPs will select the protection SPME to transmit all LSP
+   data packets.
+
+
+
+Weingarten, et al.            Informational                    [Page 11]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   The protection SPME will continue to transmit the data packets until
+   the stable recovery of the fault condition.  Upon recovery, i.e., the
+   fault condition has cleared and the network is stabilized, the
+   ingress LSR could switch traffic back to the working SPME, if the
+   protection domain is configured for revertive behavior.
+
+   The control of the protection switching, especially for cases of
+   operator commands, would be covered by the protocol defined in
+   [RFC6378].
+
+2.3.2.  Wrapping Link Protection with Segment-Based SPME
+
+   It is possible to use the SPME mechanism to perform segment-based
+   protection.  For each link in the ring, we define two SPMEs -- the
+   first is a SPME between the two LSRs that are connected by the link,
+   and the second SPME is between those same two LSRs but traverses the
+   entire ring (except the link that connects the LSRs).  In Figure 4,
+   we show the primary SPME that connects LSR-A and LSR-F over a segment
+   connection, and the secondary SPME that connects these same LSRs by
+   traversing the ring in the opposite direction.
+
+                        ___          ___          ___
+                       /LSR\********/LSR\********/LSR\
+                       \_B_/@@@@@@@@\_A_/########\_F_/
+                         *@                        *@
+                         *@                        *@
+                         *@                        *@
+                        _*@          ___          _*@
+                       /LSR\********/LSR\********/LSR\
+                       \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
+
+                  *** physical link
+                  ### primary SPME      @@@ secondary SPME
+
+                          Figure 4: Segment SPMEs
+
+   By applying OAM monitoring of these two SPMEs (at each LSR), it is
+   possible to effect a wrapping protection mechanism for the LSP
+   traffic that traverses the ring.  The LSR on either side of the
+   segment would identify that there is a fault condition on the link
+   and redirect all LSP traffic to the secondary SPME.  The traffic
+   would traverse the ring until arriving at the neighboring (relative
+   to the segment) LSR.  At this point, the LSP traffic would be
+   redirected onto the original LSP, quite likely over the neighboring
+   SPME.
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 12]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   Following the progression of the label stack through this switching
+   operation (for a LSP that enters the ring at LSR-B and exits the ring
+   at LSR-E):
+
+   1.  The data packet arrives at LSR-A with label stack [L1+S] (i.e.,
+       the top label from the LSP and bottom-of-stack indicator)
+
+   2.  In the normal case (no protection switching), LSR-A forwards the
+       packet with label stack [PA1(F) | LSE+S] (i.e., swaps the label
+       for the LSP, to be acceptable to the SPME egress, and pushes the
+       label for the primary SPME from LSR-A to LSR-F).
+
+   3.  When protection switching is in effect, LSR-A forwards the packet
+       with label stack [PA2(B) | LSE+S] (i.e., LSR-A pushes the label
+       for the secondary SPME from LSR-A to LSR-F, after swapping the
+       label of the lower-level LSP).  This will be transmitted along
+       the secondary SPME until LSR-E forwards it to LSR-F with label
+       stack [PE2(F) | LSE+S].
+
+   4.  When the packet arrives at LSR-F, it pops the SPME label, process
+       the LSP label, and forwards the packet to the next point,
+       possibly pushing a SPME label if the next segment is likewise
+       protected.
+
+2.3.3.  Wrapping Node Protection
+
+   Implementation of protection at the node level would be similar to
+   the mechanism described in the previous subsection.  The difference
+   would be in the SPMEs that are used.  For node protection, the
+   primary SPME would be configured between the two LSRs that are
+   connected to the node that is being protected (see the SPME between
+   LSR-A and LSR-E through LSR-F in Figure 5), and the secondary SPME
+   would be configured between these same nodes, going around the ring
+   (see the secondary SPME in Figure 5).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 13]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+                        ___          ___          ___
+                       /LSR\********/LSR\********/LSR\
+                       \_B_/@@@@@@@@\_A_/########\_F_/
+                         *@                        *#
+                         *@                        *#
+                         *@                        *#
+                        _*@          ___          _*#
+                       /LSR\********/LSR\********/LSR\
+                       \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
+
+                  *** physical link
+                  ### primary SPME      @@@ secondary SPME
+
+                      Figure 5: Node-Protection SPMEs
+
+   The protection mechanism would work similarly -- it would be based on
+   1:1 linear protection [RFC6372] and be triggered by OAM functions on
+   both SPMEs.  It would wrap the data packets onto the secondary SPME
+   at the ingress MEP (e.g., LSR-A in the figure) of the SPME and back
+   onto the continuation of the LSP at the egress MEP (e.g., LSR-E in
+   the figure) of the SPME.
+
+2.3.4.  Wrapping for Link and Node Protection
+
+   In the different types of wrapping presented in Section 2.3.2 and
+   Section 2.3.3, there is a limitation that the protection mechanism
+   must a priori decide whether it is protecting against link or node
+   failure.  In addition, the neighboring LSR, that detects the fault,
+   cannot readily differentiate between a link failure or a node
+   failure.
+
+   It would be possible to configure extra SPMEs to protect both for
+   link and node failures, arriving at a configuration of the ring that
+   is shown in Figure 6.  Here, there are three protection SPMEs
+   configured:
+
+   o  Secondary node#1 would be used to divert traffic as a result of an
+      indication that LSR-F is not available; it redirects the traffic
+      to the path between LSR-A and LSR-E.
+
+   o  Secondary node#2 would be used to divert traffic as a result of an
+      indication that LSR-A is not available; it redirects the traffic
+      to the path between LSR-F and LSR-B.
+
+   o  Secondary segment would be used to divert traffic as a result of
+      an indication that the segment between LSR-A and LSR-F is not
+      available; it redirects the traffic to the path between LSR-A and
+      LSR-F on the long circuit of the ring.
+
+
+
+Weingarten, et al.            Informational                    [Page 14]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   However, choosing the SPME to use for the wrapping would then involve
+   considerable effort and could result in the protected traffic not
+   sharing the same protection path in both directions.
+
+                          ___ ++++++++ ___          ___
+                         /LSR\********/LSR\********/LSR\
+                         \_B_/@@@@@@@@\_A_/########\_F_/
+                         $+*@                       +*$
+                         $+*@                       +*$
+                         $+*@                       +*$
+                         $+*@ ++++++++ ___ ++++++++ +*$
+                         /LSR\********/LSR\********/LSR\
+                         \_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
+                              $$$$$$$$     $$$$$$$$
+
+           *** physical link
+           ### primary SPME            @@@ secondary node#1 SPME
+           $$$ secondary node#2 SPME   +++ secondary segment SPME
+
+             Figure 6: SPMEs for Protecting Segments and Node
+
+2.4.  Analysis of P2P Protection
+
+   Analyzing steering SPME protection (Section 2.3.1) and wrapping based
+   on SPME (Sections 2.3.2 or 2.3.3), we can make the following
+   observations (based on a ring with N nodes, where N is not more than
+   16):
+
+   o  Number of SPMEs that need to be configured
+
+         For steering: O(2N^2).  There are two SPMEs from each ingress
+         LSR to each of the other nodes in the ring.
+
+         For wrapping: O(2N).  (However, the operator must decide a
+         priori whether to protect for link failures or node failures at
+         each point.)
+
+   o  Number of OAM sessions at each node
+
+         For steering: O(2N)
+
+         For wrapping: 3
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 15]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   o  Bandwidth requirements
+
+         For steering: single bandwidth at each link
+
+         For wrapping: double bandwidth at links that are between
+         ingress and wrapping node and between second wrapping node and
+         egress.
+
+   o  Special considerations
+
+         For steering: latency of OAM detection of fault condition by
+         ingress MEP.  (Using alarm reporting could optimize over using
+         CC-V only.)
+
+         For wrapping: each node must decide a priori whether it is
+         protecting for link or node failures.  To protect for both node
+         and link failures would increase the complexity of deciding
+         which protection path to use, as well as violate the co-
+         routedness of the protected traffic.
+
+   Based on this analysis, using steering as described in Section 2.3.1
+   would be the recommended protection mechanism due to its simplicity.
+   It should be pointed out that the number of SPMEs involved in this
+   protection could be reduced by eliminating each SPME between a pair
+   of LSRs that is not used as an ingress and egress pair.
+
+2.4.1.  Recommendations for Protection of P2P Paths Traversing a Ring
+
+   Based on the analysis presented, while applying linear protection to
+   effect wrapping protection in a ring topology is possible as
+   demonstrated, there are certain limitations in addressing some of the
+   required behavior.  The limitations include:
+
+   o  the need to configure a priori whether link or node protection
+      will be provided
+
+   o  the higher number of SPMEs that need to be defined
+
+   o  the difficulty in addressing cases of multiple failures in the
+      ring
+
+   Application of linear protection, based on the use of SPMEs within
+   the ring, to implement a steering methodology to protect a ring
+   topology is rather straightforward, overcomes the limitations listed
+   above, and scales very well.  For this and other reasons listed
+   previously, the authors recommend the use of steering to provide
+   protection of P2P paths that traverse a ring topology.
+
+
+
+
+Weingarten, et al.            Informational                    [Page 16]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+3.  Point-to-Multipoint Protection
+
+   [RFC5654] requires that ring protection must provide protection for
+   unidirectional point-to-multipoint paths through the ring.  Ring
+   topologies provide a ready platform for supporting such data paths.
+   A point-to-multipoint (P2MP) LSP in an MPLS-TP ring would be
+   characterized by a single ingress LSR and multiple egress LSRs.  The
+   following subsections will present methods to address the protection
+   of the ring-based sections of these LSPs.
+
+3.1.  Wrapping for P2MP LSPs
+
+   When protecting a P2MP ring data path using the wrapping
+   architecture, the basic operation is similar to the description
+   given, as the traffic has been wrapped back onto the normal working
+   path on the far side of the detected fault and will continue to be
+   transported to all of the egress points.
+
+   It is possible to optimize the performance of the wrapping mechanism
+   when applied to P2MP LSPs by exploiting the topology of ring
+   networks.
+
+   This improved mechanism, which we call Ring Optimized Multipoint
+   Wrapping (ROM-Wrapping), behaves much the same as classical wrapping.
+   However, ROM-Wrapping configures a protection P2MP LSP, relative to
+   each node that is considered a failure risk.  The protection P2MP LSP
+   will be routed between the failure risk node's upstream neighbor to
+   all of the egress nodes (for the particular LSP) that are downstream
+   of the failure risk node.
+
+   Referring to Figure 7, it is possible to identify the protected
+   (working) LSP (A-B-{C}-{D}-E-{F}) and one possible backup
+   (protection) LSP.  (Note: the egress nodes are indicated by the curly
+   braces.)  This protection LSP will be used to wrap the data back
+   around the ring to protect against a failure on link B-C.  This
+   protection LSP is also a P2MP LSP that is configured with egress
+   points (at nodes F, D, and C) complementary to the broken working
+   data path.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 17]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+                                  |
+                                  |
+                                  V  Ingress
+               ___               _V_                ___
+              /LSR\             /LSR\**************/LSR\
+           <@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
+               @ *                                    *
+               @ *                                    *
+               @ *                                  XXXX Failure
+               @ *                                    *
+               @_*               ___                __*
+              /LSR\*************/LSR\**************/LSR\
+              \_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
+                                 @                  @
+                                 @                  @
+                                 V                  V
+
+
+               ***  working LSP      @@@ protection LSP
+
+                        Figure 7: P2MP ROM-Wrapping
+
+   Using this mechanism, there is a need to configure a particular
+   protection LSP for each node on the working LSP.  In the table below,
+   "X's Backup" is the backup path activated by node X as a consequence
+   of a failure affecting node Y (downstream node with respect to X) or
+   link X-Y.  (Note: Braces in the path indicate egress nodes.)
+
+                   Protected LSP: A->B->{C}->{D}->E->{F}
+
+                        -- LINK/NODE PROTECTION --
+
+              A's Backup:              A->{F}->E->{D}->{C}
+              B's Backup:              B->A->{F}->E->{D}->{C}
+              C's Backup:              C->B->A->{F}->E->{D}
+              D's Backup:              D->C->B->A->{F}
+              E's Backup:              E->D->C->B->A->{F}
+
+   It should be noted that ROM-Wrapping is an LSP-based protection
+   mechanism, as opposed to the SPME-based protection mechanisms that
+   are presented in other sections of this document.  While this may
+   seem to be limited in scope, the mechanism may be very efficient for
+   many applications that are based on P2MP distribution schemes.  While
+   ROM-Wrapping can be applied to any network topology, it is
+   particularly efficient for interconnected ring topologies.
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 18]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+3.1.1.  Comparison of Wrapping and ROM-Wrapping
+
+   It is possible to compare the wrapping and the ROM-Wrapping
+   mechanisms in various aspects and show some improvements offered by
+   ROM-Wrapping.
+
+   When configuring the protection LSP for wrapping, it is necessary to
+   configure for a specific failure: link protection or node protection.
+   If the protection method is configured to protect against node
+   failures, but the actual failure affects a link, this could result in
+   failing to deliver traffic to the node, when it should be possible to
+   do so.
+
+   ROM-Wrapping, however, does not have this limitation because there is
+   no distinction between node and link protection.  Whether link B-C or
+   node C fails, the rerouting will attempt to reach C. If the failure
+   is on the link, the traffic will be delivered to C; if the failure is
+   at node C, the traffic will be rerouted correctly until node D, and
+   will be blocked at this point.  However, all egress nodes up to the
+   failure will be able to deliver the traffic properly.
+
+   A second aspect is the number of hops needed to properly deliver the
+   traffic.  Referring to the example shown in Figure 7, where a failure
+   is detected on link B-C, the following table lists the set of nodes
+   traversed by the data in the protection:
+
+                              Basic Wrapping:
+
+   A-B                   B-A-F-E-D-C              {C}-{D}-E-{F}
+   "Upstream" segment    backup path              "Downstream" segment
+   with respect to the                            with respect to the
+   failure                                        failure
+
+                               ROM-Wrapping:
+
+   A-B                  B-A-{F}-E-{D}-{C}        ..
+   "Upstream" segment   backup path
+   with respect to the
+   failure
+
+   Comparing the two lists of nodes, it is possible to see that in this
+   particular case the number of hops crossed when basic wrapping is
+   used is significantly higher than the number of hops crossed by the
+   traffic when ROM-Wrapping is used.  Generally, the number of hops for
+   basic wrapping is always greater than or equal to that for ROM-
+   Wrapping.  This implies a certain waste of bandwidth on all links
+   that are crossed in both directions.
+
+
+
+
+Weingarten, et al.            Informational                    [Page 19]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   Considering the ring network in Figure 7, it is possible to consider
+   the bandwidth utilization.  The protected LSP is set up from A to F
+   clockwise and an M Mbps bandwidth is reserved along the path.  All
+   the protection LSPs are pre-provisioned counterclockwise, each of
+   them may also have reserved bandwidth M.  These LSPs share the same
+   bandwidth in a SE (Shared Explicit) style, as described in [RFC2205].
+
+   The bandwidth reserved counterclockwise is not used when the
+   protected LSP is properly working and, in theory, could be used for
+   extra traffic [RFC4427].  However, it should be noted that [RFC5654]
+   does not require support of such extra traffic.
+
+   The two recovery mechanisms require different protection bandwidths.
+   In the case of wrapping, the bandwidth used is M in both directions
+   on many of the links.  While in the case of ROM-Wrapping, only the
+   links from the ingress node to the node performing the actual
+   wrapping utilize M bandwidth in both directions, while all other
+   links utilize M bandwidth only in the counterclockwise direction.
+
+   Consider the case of a failure detected on link B-C as shown in
+   Figure 7.  The following table lists the bandwidth utilization on
+   each link (in units equal to M), for each recovery mechanism and for
+   each direction (CW=clockwise, CCW=counterclockwise).
+
+                  +----------+----------+--------------+
+                  |          | Wrapping | ROM-Wrapping |
+                  +----------+----------+--------------+
+                  | Link A-B |  CW+CCW  | CW+CCW       |
+                  | Link A-F |    CCW   | CCW          |
+                  | Link F-E |  CW+CCW  | CCW          |
+                  | Link E-D |  CW+CCW  | CCW          |
+                  | Link D-C |  CW+CCW  | CCW          |
+                  +----------+----------+--------------+
+
+3.1.2.  Multiple Failures Comparison
+
+   A further comparison of wrapping and ROM-Wrapping can be done with
+   respect to their ability to react to multiple failures.  The wrapping
+   recovery mechanism does not have the ability to recover from multiple
+   failures on a ring network, while ROM-Wrapping is able to recover
+   from some multiple failures.
+
+   Consider, for example, a double link failure affecting links B-C and
+   C-D shown in Figure 7.  The wrapping mechanism is not able to recover
+   from the failure because B, upon detecting the failure, has no
+   alternative paths to reach C.  All the P2MP traffic is lost.  The
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 20]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   ROM-Wrapping mechanism is able to partially recover from the failure,
+   because the backup P2MP LSP to F and D is correctly set up and
+   continues delivering traffic.
+
+3.2.  Steering for P2MP Paths
+
+   When protecting P2MP traffic that uses an MPLS-TP ring as its
+   branching point (i.e., the traffic enters the ring at a head-end node
+   and exits the ring at multiple nodes), we can employ a steering
+   mechanism based on 1+1 linear protection [RFC6372].  We can configure
+   two P2MP unidirectional SPMEs from each node on the ring; they
+   traverse the ring in both directions.  These SPMEs will be configured
+   with an egress at each ring node.  In order to be able to direct the
+   LSP traffic to the proper egress point for that particular LSP, we
+   need to employ context labeling as defined in [RFC5331].  The method
+   for using these labels is expanded upon in Section 3.2.1.
+
+   For every LSP that enters the ring at a given node, the traffic will
+   be sent through both of these SPMEs, each with its own context label
+   and the context-specific label for the particular LSP.  The egress
+   nodes should select the traffic that is arriving on the working SPME.
+   When a failure condition is identified, the egress nodes should
+   select the traffic from whichever of the two SPMEs whose traffic
+   arrives at that node, i.e., since one of the two (presumably the
+   working SPME) will be blocked by the failure.  In this way, all
+   egress nodes are able to receive the data traffic.  While each node
+   detects that there is connectivity from the ingress node of the ring,
+   it continues to select the data that is coming from the working SPME.
+   If a particular node stops receiving the connectivity messages from
+   the working SPME, it identifies that it must select to read the data
+   packets from the protection SPME.
+
+3.2.1.  Context Labels
+
+   Figure 8 shows the two unidirectional P2MP SPMEs that are configured
+   from LSR-A with egress points at all of the nodes on the ring.  The
+   clockwise SPME (i.e., A-B-C-D-E-F) is configured as the working SPME
+   that will aggregate all traffic for P2MP LSPs that enter the ring at
+   LSR-A and must be sent out of the ring at any subset of the ring
+   nodes.  The counter-clockwise SPME (i.e., A-F-E-D-C-B) is configured
+   as the protection SPME.
+
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 21]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+                          ^            ^            ^
+                         _|_          _|_          _|_
+                  ----->/LSR\********/LSR\********/LSR\
+                        \_A_/========\_B_/========\_C_/
+                         +*              <+++++++++*||
+                         +*                       +*||
+                         +*                       +*||
+                         +*                       +*||
+                         +*_ ++++++++ ___ +++++++++*||
+                        /LSR\********/LSR\********/LSR\
+                        \_F_/<=======\_E_/========\_D_/
+                          |            |            |
+                          V            V            V
+
+
+                ---> connected LSP      *** physical link
+                ===  working SPME       +++ protection SPME
+
+                           Figure 8: P2MP SPMEs
+
+   [RFC5331] defines the concept of context labels.  A context-
+   identifying label defines a context label space that is used to
+   interpret the context-specific labels (found directly below the
+   context-identifying label) for a specific tunnel.  The SPME label is
+   a context-identifying label.  This means that at each hop the node
+   that receives the SPME label uses it to point not directly to a
+   forwarding table, but to a Label Information Base (LIB).  As a node
+   receives an SPME label, it examines it, discovers that it is a
+   context label, pops off the SPME label, and looks up the next label
+   down in the stack in the LIB indicated by the context label.
+
+   The label below this context-identifying label should be used by the
+   forwarding function of the node to decide the actions to take for
+   this packet.  In MPLS-TP protection of ring topologies, there are two
+   context LIBs.  One is the context LIB for the working SPME, and the
+   other is the context LIB for the protection SPME.  All context LIBs
+   have a behavior defined for the end-to-end LSP label, but the
+   behavior at each node may be different in the context of each SPME.
+
+   For example, using the ring that is shown in Figure 8, the working
+   SPME is configured to have a context-identifying label of CW at each
+   node on the ring, and the protection SPME is configured to have a
+   context-identifying label of CP at each node.  For the specific LSP,
+   we will designate the context-specific label used on the working SPME
+   as WL(x-y), where it's the label used as node-x forwards the packet
+   to node-y.  Similarly, a context-specific label on the protection
+   SPME would be designated PL(x-y).  An explicit example of label
+   values appears in the next subsection.
+
+
+
+Weingarten, et al.            Informational                    [Page 22]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   Assume we are applying 1+1 linear protection, as outlined above, for
+   a P2MP LSP that enters the ring at LSR-A and has egress points from
+   the ring at LSR-C and LSR-E using the two SPMEs shown in Figure 8.  A
+   packet that arrives at LSR-A with a label stack [LI+S] will be
+   forwarded on the working SPME with a label stack [CW | WL(A-B)].  The
+   packet should then be forwarded to LSR-C arriving with a label [CW |
+   WL(B-C)], where WL(B-C) should instruct the forwarding function to
+   egress the packet with [LE(C)] and forward a copy to LSR-D with label
+   stack [CW | WL(C-D)].
+
+   If a fault condition is detected (for example, on the link C-D), then
+   the nodes that are beyond the fault point (in this example, nodes
+   LSR-D, LSR-E, and LSR-F), will cease to receive the data packets from
+   the clockwise (working) SPME.  Each of these LSRs should then begin
+   to switch its "selector bridge" and accept the data packets from the
+   protection (counter-clockwise) SPME.  At the ingress point (LSR-A),
+   all data packets will have been transmitted on both the working SPME
+   and the protection SPME.  Continuing the example, LSR-A will transmit
+   one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy
+   to LSR-F with stack [CP | PL(A-F)].  The packet will arrive at LSR-C
+   from the working SPME and egress from the ring.  LSR-E will receive
+   the packet from the protection SPME with stack [CP | PL(F-E)], and
+   the context-sensitive label PL(F-E) will instruct the forwarding
+   function to send a copy out of the ring with label LE(E) and a second
+   copy to LSR-D with stack [CP | PL(E-D)].  In this way, each of the
+   egress points receives the packet from the SPME that is available at
+   that point.
+
+   This architecture has the added advantages that there is no need for
+   the ingress node to identify the existence of the mis-connectivity,
+   and there is no need for a return path from the egress points to the
+   ingress.
+
+3.2.2.  Walk-Through Using Context Labels
+
+   In order to better demonstrate the use of the context labels, we
+   present a walk-through of an example application of the P2MP
+   protection presented in this section.  Referring to Figure 9, there
+   is a P2MP LSP that traverses the ring, entering the ring at LSR-B and
+   branching off at LSR-D, LSR-E, and LSR-H, and it does not continue
+   beyond LSR-H.  For purposes of protection, two P2MP unidirectional
+   SPMEs are configured on the ring starting from LSR-B.  One of the
+   SPMEs, the working SPME, is configured with egress points at each of
+   the LSRs -- C, D, E, F, G, H, J, K, A. The second SPME, the
+   protection SPME, is configured with egress points at each of the LSRs
+   -- A, K, J, H, G, F, E, D, C.
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 23]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+                            ^            ^           ^           ^
+                            ^            ^           ^           ^
+              ___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_
+       xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
+             \_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/
+               *+             <+++++++++    +++++++     ++++++++*||x
+               *+                                              +*||x
+               *+                                              +*||x
+               *+                                              +*||x
+              _*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x
+             /LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
+             \_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/
+               +            +            +           +Xxxxxxxxxx +
+               v            v            v           v           v
+               v            v            v           v           v
+
+       xxx P2MP LSP (X LSP egress)     *** physical link
+       === working SPME                +++ protection SPME
+                                       +>> protection SPME egress
+
+                           Figure 9: P2MP SPMEs
+
+   For this example, we suppose that the LSP traffic enters the ring at
+   LSR-B with the label stack [99], and leaves the ring:
+
+   o  at LSR-D with stack [199]
+
+   o  at LSR-E with stack [299]
+
+   o  at LSR-H with stack [399]
+
+   While it is possible for the context-identifying label for the SPME
+   to be configured as a different value at each LSR, for the sake of
+   this example, we will suppose a configuration of 200 as the context-
+   identifying label for the working SPME at each of the LSRs in the
+   ring, and 400 as the context-identifying label for the protection
+   SPME at each LSR.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 24]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   For the specific connected LSP, we configure the following context-
+   specific labels:
+
+   +------+-----------------------------+------------------------------+
+   | node | W-context(200)              | P-context(400)               |
+   +------+-----------------------------+------------------------------+
+   |   A  | 65 {drop packet}            | 165 {fwd w/ [400 | 190]}     |
+   |   C  | 90 {fwd w/ [200 | 80]}      | 190 {drop packet}            |
+   |   D  | 80 {fwd w/ [200 | 75] +     | 180 {egress w/ [199]}        |
+   |      | egress w/ [199]}            |                              |
+   |   E  | 75 {fwd w/ [200 | 65] +     | 175 {fwd w/ [400 | 180] +    |
+   |      | egress w/ [299]}            | egress w/ [299]}             |
+   |   F  | 65 {fwd w/ [200 | 55]}      | 165 {fwd w/ [400 | 175]}     |
+   |   G  | 55 {fwd w/ [200 | 45]}      | 155 {fwd w/ [400 | 165]}     |
+   |   H  | 45 {egress w/ [399]}        | 145 {fwd w/ [400 | 155] +    |
+   |      |                             | egress w/ [399]}             |
+   |   J  | 65 {drop packet}            | 165 {fwd w/ [400 | 145]}     |
+   |   K  | 65 {drop packet}            | 190 {fwd w/ [400 | 165]}     |
+   +------+-----------------------------+------------------------------+
+
+   When a packet arrives on the LSP to LSR-B with stack [99], the
+   forwarding function determines that it is necessary to forward the
+   packet to both the working SPME with stack [200 | 90] and the
+   protection SPME with stack [400 | 165].  Each LSR on the SPME will
+   identify the top label, i.e., 200 or 400, to be the context-
+   identifying label and use the next label in the stack to select the
+   forwarding action from the specific context table.
+
+   Therefore, at LSR-C, the packet on the working SPME will arrive with
+   stack [200 | 90], and the 200 will point to the middle column of the
+   table above.  After popping the 200, the next label, i.e., 90, will
+   select the forwarding action "fwd w/ [200 | 80]", and the packet will
+   be forwarded to LSR-D with stack [200 | 80].  In this manner, the
+   packet will be forwarded along both SPMEs according to the configured
+   behavior in the context tables.  However, the egress points at LSR-D,
+   LSR-E, and LSR-H will each be configured with a selector bridge so
+   they will use only the input from the working SPME.  If any of these
+   egress points identifies that there is a connection fault on the
+   working SPME, then the selector bridge will cause the LSR to read the
+   input from the protection SPME.
+
+
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 25]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+4.  Coordination Protocol
+
+   The survivability framework [RFC6372] indicates that there is a need
+   to coordinate protection switching between the endpoints of a
+   protected bidirectional domain.  The coordination is necessary for
+   particular cases, in order to maintain the co-routed nature of the
+   bidirectional transport path.  The particular cases where this
+   becomes necessary include when unidirectional fault detection or
+   operator commands are used.
+
+   By using the same mechanisms defined in [RFC6378] for linear
+   protection to protect a single ring topology, we are able to gain a
+   consistent solution for this coordination between the endpoints of
+   the protection domain.  The Protection State Coordination Protocol
+   that is specified in [RFC6378] provides coverage for all the
+   coordination cases, including support for operator commands, e.g.,
+   Forced Switch.
+
+5.  Conclusions and Recommendations
+
+   Ring topologies are prevalent in traditional transport networks and
+   will continue to be used for various reasons.  Protection for
+   transport paths that traverse a ring within an MPLS network can be
+   provided by applying an appropriate instance of linear protection, as
+   defined in [RFC6372].  This document has shown that for each of the
+   traditional ring-protection architectures there is an application of
+   linear protection that provides efficient coverage, based on the use
+   of the Sub-Path Maintenance Entity (SPME), defined in [RFC5921] and
+   [RFC6371].  For example:
+
+   o  P2P steering - Configuration of two SPMEs, from the ingress node
+      of the ring to the egress node of the ring, and 1:1 linear
+      protection.
+
+   o  P2P Wrapping for link protection - Configuration of two SPMEs, one
+      for the protected link and the second for the long route between
+      the two neighboring nodes, and 1:1 linear protection.
+
+   o  P2P wrapping for node protection - Configuration of two SPMEs, one
+      between the two neighbors of the protected node and the second
+      between these two nodes on the long route, and 1:1 linear
+      protection.
+
+   o  P2MP wrapping - it is possible to optimize the performance of the
+      wrapping by configuring the proper protection path to egress the
+      data at the proper branching nodes.
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 26]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   o  P2MP steering - by combining 1+1 linear protection and
+      configuration of the SPME based on context-sensitive labeling of
+      the protection path.
+
+   This document shows that use of the protection architecture and
+   mechanisms suggested provides the optimizations needed to justify
+   ring-specific protection as defined in [RFC5654].
+
+   Protection of traffic over a ring topology based on the steering
+   architecture using basic 1:1 linear protection is a very efficient
+   implementation for sections of a P2P transport path that traverses a
+   ring.  Steering should be the preferred mechanism for P2P protection
+   in a ring topology since it reduces the extra bandwidth required when
+   traffic doubles through wrapped protection, and it provides the
+   ability to protect both against link and node failures without
+   complicating the fault detection or requiring that multiple
+   protection paths be configured.  While this is true, it's possible to
+   support either wrapping or steering while depending upon the OAM
+   functionality (outlined in [RFC6371] and specified in various
+   documents) and the coordination protocol specified for linear
+   protection in [RFC6378].
+
+6.  Security Considerations
+
+   This document does not add any security risks to the network.  Any
+   security considerations are defined in [RFC6378], and their
+   applicability to the information contained in this document follows
+   naturally from the applicability of the mechanism defined in that
+   document.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC6378]  Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
+              A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
+              Protection", RFC 6378, October 2011.
+
+7.2.  Informative References
+
+   [G.841]    ITU, "Types and characteristics of SDH network protection
+              architectures", ITU-T G.841, October 1998.
+
+   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
+              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+              Functional Specification", RFC 2205, September 1997.
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 27]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   [RFC4090]  Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+              Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+              May 2005.
+
+   [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery (Protection and
+              Restoration) Terminology for Generalized Multi-Protocol
+              Label Switching (GMPLS)", RFC 4427, March 2006.
+
+   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
+              Label Assignment and Context-Specific Label Space",
+              RFC 5331, August 2008.
+
+   [RFC5654]  Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
+              and S. Ueno, "Requirements of an MPLS Transport Profile",
+              RFC 5654, September 2009.
+
+   [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
+              Berger, "A Framework for MPLS in Transport Networks",
+              RFC 5921, July 2010.
+
+   [RFC6371]  Busi, I. and D. Allan, "Operations, Administration, and
+              Maintenance Framework for MPLS-Based Transport Networks",
+              RFC 6371, September 2011.
+
+   [RFC6372]  Sprecher, N. and A. Farrel, "MPLS Transport Profile
+              (MPLS-TP) Survivability Framework", RFC 6372,
+              September 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 28]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+Appendix A.  Acknowledgements
+
+   The authors would like to acknowledge the strong contributions from
+   all the people who commented on this document and made suggestions
+   for improvements.
+
+Appendix B.  Contributors
+
+   The authors would like to acknowledge the following individuals that
+   contributed their insights and advice to this work:
+
+   Nurit Sprecher (NSN)
+
+   Akira Sakurai (NEC)
+
+   Rolf Winter (NEC)
+
+   Eric Osborne (Cisco)
+
+Authors' Addresses
+
+   Yaacov Weingarten
+   34 Hagefen St.
+   Karnei Shomron,   4485500
+   Israel
+
+   Phone:
+   EMail: wyaacov@gmail.com
+
+
+   Stewart Bryant
+   Cisco Systems
+   10 New Square, Bedfont Lakes
+   Feltham, Middlesex,
+   TW18 8HA
+   UK
+
+   EMail: stbryant@cisco.com
+
+
+   Danielle Ceccarelli
+   Ericsson
+   Via A. Negrone 1/A
+   Genova, Sestri Ponente
+   Italy
+
+   EMail: daniele.ceccarelli@ericsson.com
+
+
+
+
+Weingarten, et al.            Informational                    [Page 29]
+
+RFC 6974                       MPLS-TP RP                      July 2013
+
+
+   Diego Caviglia
+   Ericsson
+   Via A. Negrone 1/A
+   Genova, Sestri Ponente
+   Italy
+
+   EMail: diego.caviglia@ericsson.com
+
+
+   Francesco Fondelli
+   Ericsson
+   Via A. Negrone 1/A
+   Genova, Sestri Ponente
+   Italy
+
+   EMail: francesco.fondelli@ericsson.com
+
+
+   Marco Corsi
+   Altran
+   Via A. Negrone 1/A
+   Genova, Sestri Ponente
+   Italy
+
+   EMail: corsi.marco@gmail.com
+
+
+   Bo Wu
+   ZTE Corporation
+   4F, RD Building 2, Zijinghua Road
+   Nanjing, Yuhuatai District
+   P.R. China
+
+   EMail: wu.bo@zte.com.cn
+
+
+   Xuehui Dai
+
+   EMail: xuehuiwfsy@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+Weingarten, et al.            Informational                    [Page 30]
+