[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 draft-ietf-mpls-tp-ring-protection

Network Working Group                                 Y. Weingarten, Ed.
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                                 S. Bryant
Expires: July 2, 2010                                              Cisco
                                                             N. Sprecher
                                                  Nokia Siemens Networks
                                                      D. Ceccarelli, Ed.
                                                             D. Caviglia
                                                             F. Fondelli
                                                                Ericsson
                                                                M. Corsi
                                                                  Altran
                                                                   B. Wu
                                                                  X. Dai
                                                         ZTE Corporation
                                                       December 29, 2009


                        MPLS-TP Ring Protection
            draft-weingarten-mpls-tp-ring-protection-02.txt

Abstract

   This document presents an applicability statement to address the
   requirements for protection of ring topologies for Multi-Protocol
   Label Switching Transport Profile (MPLS-TP) Label Switched Paths
   (LSP) on multiple layers.  The MPLS-TP Requirements document [TPReqs]
   specifies specific criteria for justification of dedicated protection
   mechanism for particular topologies, including optimizing the number
   of OAM entities needed, minimizing the number of labels for
   protection paths, minimzing the number of recovery elements in the
   network, and minimizing the number of control and management
   transactions necessary.  The document proposes a methodology for ring
   protection based on existing MPLS-TP survivability mechanisms,
   without the need of specification of new constructs or protocols.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network as
   defined by the ITU-T.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.




Weingarten, et al.        Expires July 2, 2010                  [Page 1]


Internet-Draft                 MPLS-TP LP                  December 2009


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 2, 2010.

Copyright Notice

   Copyright (c) 2009 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 BSD License.



















Weingarten, et al.        Expires July 2, 2010                  [Page 2]


Internet-Draft                 MPLS-TP LP                  December 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Problem statement  . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology and Notation . . . . . . . . . . . . . . . . .  5
     1.3.  Contributing Authors . . . . . . . . . . . . . . . . . . .  6
   2.  P2P Ring Protection  . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Wrapping . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Steering . . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.3.  P2P ring protection with PST . . . . . . . . . . . . . . .  9
       2.3.1.  Path PST for Steering  . . . . . . . . . . . . . . . . 11
       2.3.2.  Wrapping with segment based PST  . . . . . . . . . . . 11
       2.3.3.  Wrapping node protection . . . . . . . . . . . . . . . 13
       2.3.4.  Wrapping for link and node protection  . . . . . . . . 14
     2.4.  Analysis of p2p protection . . . . . . . . . . . . . . . . 15
   3.  P2MP protection  . . . . . . . . . . . . . . . . . . . . . . . 15
     3.1.  Wrapping for p2mp LSP  . . . . . . . . . . . . . . . . . . 15
       3.1.1.  Comparison of Wrapping and ROM-Wrapping  . . . . . . . 17
       3.1.2.  Multiple Failures Comparison . . . . . . . . . . . . . 19
     3.2.  Steering for p2mp paths  . . . . . . . . . . . . . . . . . 19
   4.  Coordination protocol  . . . . . . . . . . . . . . . . . . . . 21
   5.  Interconnected rings . . . . . . . . . . . . . . . . . . . . . 21
   6.  Conclusions and Recommendations  . . . . . . . . . . . . . . . 23
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   10. Informative References . . . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25























Weingarten, et al.        Expires July 2, 2010                  [Page 3]


Internet-Draft                 MPLS-TP LP                  December 2009


1.  Introduction

   Multi-Protocol Label Switching Transport Profile (MPLS-TP) is being
   standardized as part of a joint effort between the Internet
   Engineering Task Force (IETF) and the International Telecommunication
   Union Standardization (ITU-T).  These specifications are based on the
   requirements that were generated from this joint effort.

   The requirements for MPLS-TP [TPReqs] indicates a requirement to
   support a network that may include sub-networks that constitute a
   MPLS-TP ring as defined in the requirements.  There were no
   requirements specific to a ring topology indicated in the
   requirements document.  However, the requirements state that specific
   protection mechanisms aimed at ring topologies may be developed if
   these allow the network to optimize:

   o  Number of OAM entities needed to trigger the protection

   o  Number of recovery objects needed

   o  Number of labels required

   o  Number of control and management plane transactions during a
      recovery operation

   o  Impact of signaling and routing information exchanged, in presence
      of control plane

   This document will propose a set of basic mechanisms that could be
   used for the protection of the data flows that traverse a MPLS-TP
   ring.  The mechanism is based on existing MPLS and MPLS-TP protection
   mechanisms.  We show that this mechanism provides the ability to
   protect all of the basic conditions within a reasonable time frame
   and does optimize the criteria set out in [TPReqs] as summarized
   above.

1.1.  Problem statement

   Ring topologies, as definied in [TPReqs], are used in transport
   networks due to their ability to easily support both p2p and p2mp
   transport paths.  When designing a protection mechanism for a ring
   topology, there is a need to address both

   1.  the simple case of a transport path that enters a MPLS-TP capable
       ring at one node, the ingress node, and exits the ring at a
       single egress node possibly continuing beyond the ring.





Weingarten, et al.        Expires July 2, 2010                  [Page 4]


Internet-Draft                 MPLS-TP LP                  December 2009


   2.  the case where the ring is being used as a branching point, i.e.
       the transport path enters the MPLS-TP capable ring at the ingress
       node and exits through a number of egress nodes, possibly
       continuing beyond the ring.

   Within the ring segment of the transport path there is the 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 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 should be detected by the two neighboring ring nodes.

   3.  administrator command is issued to a specific ring node.  These
       commands include a Manual Switch, Forced Switch, or Clear
       operation.

   The protection domain that will be addressed in this document is
   limited to the traffic that is traversing the ring.  Traffic on the
   transport path prior to the ring ingress node or beyond the egress
   nodes may be protected by some other mechanism.

1.2.  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[TPFwk]

   o  MPLS-TP OAM Framework[OAMFwk]

   o  MPLS-TP Survivability Framework[SurvivFwk]

   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

   3.  The bottom of the stack will be denoted by the string "BOS"




Weingarten, et al.        Expires July 2, 2010                  [Page 5]


Internet-Draft                 MPLS-TP LP                  December 2009


   4.  The label of an ingress LSP will be denoted by the string "LI"
       and the label of the egress LSP will be denoted by the string
       "LE"

   5.  The label for a PST will be denoted by Px(y) where x and y are
       LSR identifiers and the intention is to the label for LSR-x to
       transmit to LSR-y over the PST.

   For example - the label stack [PB(G)|LI|BOS] denotes a stack whose
   top-label is the PST label for LSR-B to transmit the data packet to
   LSR-G, the packet originated from a LSP that arrived at the ring with
   label LI.

1.3.  Contributing Authors

   Akira Sakurai (NEC), Rolf Winter (NEC)


2.  P2P Ring Protection

   Classically there are two protection architecture mechanisms for ring
   topologies, based on SDH specifications [G.841], that have been
   proposed in various forums to perform recovery of a topological ring
   network - "wrapping" and "steering".  The following sub-sections will
   examine these two mechanisms.

2.1.  Wrapping

   Wrapping is defined as a "local" protection architecture.  This
   mechanism is local to the LSRs that are neighbors to the detected
   fault.  When a fault is detected (either a link or node failure), the
   neighboring LSR can identify that the fault would prevent forwarding
   of the data along the data path.  Therefore, in order to continue the
   data along the path, there is need to "wrap" all data traffic around
   the ring, on an alternate data path, until arriving at the LSR that
   is on the opposite side of the fault.  When this LSR also detects
   that there is a fault condition on the LSP, it can identify that the
   data traffic that is arriving on the alternate (protecting) data path
   is intended for the "broken" LSP.  Therefore, again taking a local
   decision can wrap the data back onto the normal working path until
   the egress from the ring segment.










Weingarten, et al.        Expires July 2, 2010                  [Page 6]


Internet-Draft                 MPLS-TP LP                  December 2009


                                        ____
                              =========>/ LSR\
                                      * \__B_/ *
                                     * @@@@@@@# *
                                    * @       @# *
                                ___* @         @# *___
                               /LSR\ @          @#/LSR\
                               \_C_/ @           #\_A_/
                                 *  @             # *
                                 *  @              XX
                                _*_ @              #*_
                               /LSR\@             /LSR\
                               \_D_/@            @\_F_/
                                   * @          @#*
                                    * @       @@#*
                                     * @@____@##*
                                       */ LSR\*
                                        \__E_/========>

                   ===> connected LSP  *** physical link
                   ###  working path   @@@ wrapped data path

                Figure 1: Wrapping protection for p2p path

   In this figure we have a ring with a LSP that enters the ring at
   LSR-B and exits at LSR-E.  The normal working path follows through
   B-A-F-E.  If a signal 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 LSR 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).  Coordination would only be needed to maintain co-
   routed bidirectional traffic even in cases of a unidirectional fault
   condition.

   The following considerations should be taken into account when
   considering use of wrapping protection:

   o  Detection of loss-of-continutiy or misconnectivity, should be
      performed at the link level and/or per LSR when using node-level
      protection.  The configuration of the protection being performed



Weingarten, et al.        Expires July 2, 2010                  [Page 7]


Internet-Draft                 MPLS-TP LP                  December 2009


      (either link protection or node protection) needs to be configured
      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 a
      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, later it is
      transmitted E-->F and F-->E. This means that there is additional
      bandwith needed for this protection.

   o  The resource allocation for the alternate-paths could be
      problematic, since most of these alternate paths will not be used
      simultaneously.  One possibility could be to allocate '0'
      resources and depend on the NMS to allocate the proper resources
      around the ring.

   o  Wrapping also involves greater latency in delivering the packets,
      as a result of traversing the entire ring.  This could be very
      restrictive for large rings.

2.2.  Steering

   The second common scheme for ring protection redirects the traffic
   from the ingress point to the alternate route around the ring to the
   egress point.  This is illustrated in Figure 2, where if a Signal
   Fault is detected 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).

   This mechanism is similar to linear 1:1 protection [SurvivFwk].  The
   two paths around the ring act as the working and recovery paths.
   There is need to communicate to the ingress node the need to switch
   over to the recovery path and there is a need to coordinate the
   switchover between the two end-points of the protected domain.

   The following considerations must be taken into account regarding the
   steering architecture:

   o  It is necessary for the ingress node to be "informed" of the fault
      condition in order to perform the protection switching.

   o  The process of "informing" the ingress node adds to the latency of
      the protection switching process, after the detection of the fault



Weingarten, et al.        Expires July 2, 2010                  [Page 8]


Internet-Draft                 MPLS-TP LP                  December 2009


      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.

2.3.  P2P ring protection with PST

   The MPLS-TP Framework document [TPFwk] defines a Path Segment Tunnel
   (PST) construct that can be defined between any two LSRs of a MPLS-TP
   LSP.  For MPLS-TP purposes, such a PST may be configured as a
   bidirectional co-routed path.  A PST may be used to aggregate all LSP
   traffic that traverses the segment (from ingress LSR to egress LSR)
   that is delineated by the PST.  This PST may be monitored using the
   OAM mechanisms as specified in the MPLS-TP OAM Framework document
   [OAMFwk].

   When defining a 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)
   PST with the segment of the transport path that traverses the ring.
   In addition, we configure an alternate (protecting) PST that
   traverses the ring in the opposite direction around the ring.  The
   exact selection of the two PSTs is dependent on the type of transport
   path and protection that is being implemented and will be detailed in
   the following sections.

   Based on this architectural configuration for ring protection, it is
   possible to restrict the number of alternate paths needed to protect
   the data traversing the ring.  Similarly, we can minimize the number
   of OAM sessions needed to monitor the data traffic of the ring - by
   monitoring the PSTs, rather than monitoring each individual LSP.

   The following figure shows a 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 PST through the ring (the first PST
   traverses along B-A-F, and the second PST traverses B-C-D-E-F).












Weingarten, et al.        Expires July 2, 2010                  [Page 9]


Internet-Draft                 MPLS-TP LP                  December 2009


                                  ____
                       =========>/ LSR\
                               * \__B_/ *
                              * @      # *
                             * @        # *
                          __* @          # *___
                        /LSR\ @           #/LSR\
                        \_C_/ @           #\_A_/
                          *  @             # *
                          *  @              #*
                         _*_ @              #*_
                        /LSR\@             /LSR\========>
                        \_D_/@             \_F_/
                            * @           @*
                             * @         @*
                              * @@____@@*
                                */ LSR\*
                                 \__E_/


           ===> connected LSP    *** physical link
           ###  primary PST      @@@ secondary PST

                         Figure 2: A MPLS-TP ring

   In all of the following subsections, we use 1:1 linear protection
   [SurvivFwk] [LinProtect] to perform protection switching and
   coordination when a signal fault is detected.  The actual
   configuration of the PSTs used may change dependent 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 PST, while using OAM
   functionlity to detect signal fault conditions on either the primary
   or the secondary PST.  If a signal fault is detected on the primary
   PST, then the mechanism described in [LinProtect] shall be used to
   coordinate a switch-over of data traffic to the secondary PST.

   Assuming that the PST is implemented as an hierarchial LSP, packets
   that arrive at LSR-B with a label stack [L1|BOS] will have the PST
   label pushed at LSR-B (i.e. the packet will arrive at LSR-A with a
   label stack of [PA(F)|L1|BOS], arrive at LSR-F with [PF(F)|L1|BOS]).
   The PST label will be popped by LSR-F and the LSP label will be
   treated appropriately at LSR-F and forwarded along the LSP.  This
   scenario is true for all LSP that are aggregated by this primary PST.







Weingarten, et al.        Expires July 2, 2010                 [Page 10]


Internet-Draft                 MPLS-TP LP                  December 2009


2.3.1.  Path PST for Steering

   A p2p PST 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 PST.  Since the PST is traversing
   a ring we can take advantage of another characteristic of a ring -
   there is always an alternative path between the two MEPs, traversing
   the ring in the opposite direction.  This alternative PST can be
   defined as the protection path for the working path that is
   configured as part of the LSP and defined as a PST.

   For each pair of PSTs 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 recovery PST.  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, recovery PST.

   This protection mechanism is identical to application of 1:1 linear
   protection[SurvivFwk] [LinProtect]to the pair of PSTs.  Under normal
   conditions, all LSP data traffic will be transmitted on the working
   PST.  If the linear protection is triggered, by either the OAM
   indication, an other fault indication trigger, or an administrative
   command, then the MEPs will select the recovery PST to transmit all
   LSP data packets.

   The recovery PST will continue to transmit the data packets until the
   stable recovery of the fault condition.  Upon recovery, the ingress
   LSR could switch traffic back to the working PST, if the protection
   domain is configured for revertive behavior.

   The control of the protection switching, especially for cases of
   administrative commands, would be covered by the protocol defined in
   [LinProtect].

2.3.2.  Wrapping with segment based PST

   It is possible to use the PST mechanism to perform segment-based
   protection.  For each link in the ring, we define two PST - the first
   is a PST between the two LSRs that are connected by the link, and the
   second PST between these same two LSRs but traversing the entire ring
   (except the link that connects the LSRs).  In Figure 3 we show the
   primary PST that connects LSR-A & LSR-F over a segment connection,
   and the secondary PST that connects these same LSRs by traversing the
   ring in the opposite direction.






Weingarten, et al.        Expires July 2, 2010                 [Page 11]


Internet-Draft                 MPLS-TP LP                  December 2009


                                  ____
                                 / LSR\
                               * \__B_/ *
                              * @      @ *
                             * @        @ *
                          __* @          @ *___
                        /LSR\ @           @/LSR\
                        \_C_/ @            \_A_/
                          *  @              #*
                          *  @              #*
                         _*_ @              #*_
                        /LSR\@             /LSR\
                        \_D_/@             \_F_/
                            * @           @*
                             * @         @*
                              * @@____@@*
                                */ LSR\*
                                 \__E_/


                       *** physical link
           ###  primary PST      @@@ secondary PST

                          Figure 3: Segment PSTs

   By applying OAM monitoring of these two PST (at each LSR), it is
   possible to affect 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 PST.  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 PST.

   Following the progression of the label stack through this switching
   operation:

   1.  The data packet arrives at LSR-A with label stack [LI|BOS] (i.e.
       top label from the LSP and bottom-of-stack indicator)

   2.  In the normal case (no switching), LSR-A forwards the packet with
       label stack [PA1(F)|LI|BOS] (i.e. push the label for the primary
       PST from LSR-A to LSR-F).

   3.  When switching is in-effect, LSR-A forwards the packet with label
       stack [PA2(F)|LI|BOS] (i.e.  LSR-A pushed the label for the
       secondary PST from LSR-A to LSR-F).




Weingarten, et al.        Expires July 2, 2010                 [Page 12]


Internet-Draft                 MPLS-TP LP                  December 2009


   4.  When the packet arrives at LSR-F, it will pop the PST label,
       process the LSP label, and forward the packet to the next point,
       possibly pushing a PST 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 sub-section.  The difference
   would be in the PSTs that are used.  For node protection, the primary
   PST would be configured between the two LSR that are connected to the
   node that is being protected (see PST between LSR-A and LSR-E through
   LSR-F in Figure 4), and the secondary PST would be configured between
   these same nodes, going around the ring (see secondary PST in
   Figure 4).

                                  ____
                                 / LSR\
                               * \__B_/ *
                              * @      @ *
                             * @        @ *
                          __* @          @ *___
                        /LSR\ @           @/LSR\
                        \_C_/ @            \_A_/
                          *  @              #*
                          *  @              #*
                         _*_ @              #*_
                        /LSR\@             /LSR\
                        \_D_/@             \_F_/
                            * @           # *
                             * @         # *
                              * @@____  # *
                                */ LSR\#*
                                 \__E_/


                     *** physical link
           ###  primary PST      @@@ secondary PST

                      Figure 4: Node-protection PSTs

   The protection mechanism would work similarly - based on 1:1 linear
   protection [SurvivFwk], triggered by OAM functions on both PSTs, and
   wrapping the data packets onto the secondary PST at the ingress MEP
   (e.g.  LSR-A in the figure) of the PST and back onto the continuation
   of the LSP at the egress MEP (e.g.  LSR-E in the figure) of the PST.





Weingarten, et al.        Expires July 2, 2010                 [Page 13]


Internet-Draft                 MPLS-TP LP                  December 2009


2.3.4.  Wrapping for link and node protection

   In the different types of wrapping presented in sections 2.3.2 and
   2.3.3, there is a limitation that the protection mechanism must a
   priori decide whether it is protecting for 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 is possible to combine the link protection mechanism presented in
   section 2.3.2 with the protection mechanism of section 2.3.3 to give
   more complete coverage.  For each segment, we configure both a
   secondary link protection PST as well as a two secondary node
   protection PST [one for each direction of the bidirectional segment
   PST] (see Figure 5).  When a protection switch is triggered, the
   ingress LSR of the segment will examine the packet ring destination.
   Only if this destination is for the LSR connected to the secondary
   link PST, then the packets will be wrapped onto this secondary PST.
   For all other cases, the data packets will be wrapped onto the
   secondary node PST.  In all cases the egress LSR for the secondary
   PST will wrap the data traffic back onto the working LSP/PST.

                                  ____
                                 / LSR\
                               * \__B_/ *
                              * @+$   +@ *
                             * @+$     +@ *
                          __* @+$       +@ *___
                        /LSR\ @+$        +@/LSR\
                        \_C_/ @+$          \_A_/
                          *  @+$            #*
                          *  @+$            #*
                         _*_ @+$            #*_
                        /LSR\@+$           /LSR\
                        \_D_/@+$           \_F_/
                            * @+$          $+*
                             * @+$       $+*
                              * @++$+$+$+*
                                */ LSR\*
                                 \__E_/


                        *** physical link
           ###  primary PST           @@@ secondary node#1 PST
           $$$  secondary node#2 PST  +++ secondary segment PST

                 Figure 5: Segment & Node protection PSTs





Weingarten, et al.        Expires July 2, 2010                 [Page 14]


Internet-Draft                 MPLS-TP LP                  December 2009


2.4.  Analysis of p2p protection

   Analyzing the mechanisms described in the above subsections we can
   point to the following observations (based on a ring with N nodes):

   o  Number of PST that need to be configured - for path PST (sec
      2.3.1) = O(2N^2) [two PST from each ingress LSR to each other node
      in the ring], for segment PST (sec 2.3.4) = O(4N) [four PST for
      each link in the ring]

   o  Number of OAM sessions at each node - for path PST = O(2N), for
      segment PST = 4

   o  Bandwidth requirements - for path PST: single bandwidth at each
      link, for segment PST: double bandwidth at links that are between
      ingress and wrapping node and between second wrapping node and
      egress.

   o  Special considerations - for path PST: latency of OAM detection of
      fault condition by ingress MEP [using Alarm-reporting could
      optimize over using CC-V only], for segment PST: need to examine
      data packet ring destination before selecting bypass PST.


3.  P2MP protection

   [TPReqs] 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 p2mp LSP in an MPLS-TP ring would be characterized by a single
   ingress LSR and multiple egress LSRs.  The following sub-sections
   will present methods to address the protection of the ring-based
   sections of these LSP.

3.1.  Wrapping for p2mp LSP

   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 Multicast
   Wrapping (ROM-Wrapping), behaves much the same as classical wrapping.



Weingarten, et al.        Expires July 2, 2010                 [Page 15]


Internet-Draft                 MPLS-TP LP                  December 2009


   There is one difference - rather than configuring the recovery LSP
   between the end nodes of a failed link (link protection) or between
   the upstream and downstream node of a failed node (node protection),
   the improved mechanism configures a recovery p2mp LSP from the
   upstream (with respect to the failure) node and all egress nodes (for
   the particular LSP) downstream from the failure.

   Referring to Figure 6, it is possible to identify the protected
   (working) LSP (A-B-[C]-[D]-E-[F]) and one possible backup
   (protection) LSP.  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, & C) complimentary to the broken working data
   path.

                                          |
                                          |
                                          V  Ingress
                       ___               _V_                ___
                      /LSR\             /LSR\**************/LSR\
                   <@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
                       @ *                                    *
                       @ *                                    *
                       @ *                                  XXXX Failure
                       @ *                                    *
                       @_*               ___                __*
                      /LSR\*************/LSR\**************/LSR\
                      \_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
                                         @                  @
                                         @                  @
                                         V                  V


                       ***  working LSP      @@@ protection LSP

                        Figure 6: 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, and square brackets, in the path,indicate egress nodes.









Weingarten, et al.        Expires July 2, 2010                 [Page 16]


Internet-Draft                 MPLS-TP LP                  December 2009


                   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 PST based protection mechanisms that are
   presented in other sections of this draft.  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.

3.1.1.  Comparison of Wrapping and ROM-Wrapping

   It is possible to compare the Wrapping and the ROM-Wrapping
   mechanisms in different 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 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.

   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 fail, in both cases the rerouting will attempt to reach C. If
   the failure is on the link, the traffic will be delivered to C, while
   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 upto 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 6, where a failure
   is detected on link B-C, the following table lists the set of nodes
   traversed by the data in the protection:









Weingarten, et al.        Expires July 2, 2010                 [Page 17]


Internet-Draft                 MPLS-TP LP                  December 2009


                              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 using the simple Wrapping
   is significantly higher than the number of hops crossed by the
   traffic when ROM-Wrapping is used.  Generally, the number of hops is
   always higher or at least equal for basic Wrapping as compared to
   ROM-Wrapping.  This implies a certain waste of bandwidth on all links
   that are crossed in both directions.

   Considering the ring network previously seen, it is possible to do
   some bandwidth utilization considerations.  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 preprovisioned
   counterclockwise, each of them may also have reserved bandwidth M.
   These LSPs share the same bandwidth in a SE (Shared Explicit) [RSVP]
   style.

   The bandwidth reserved counterclockwise is not used when the
   protected LSP is properly working and could, in theory, be used for
   extra traffic [RFC4427].  However, it should be noted that [TPReqs]
   does not require support of such extra traffic.

   The two recovery mechanism require different protection bandwidths.
   In the case of Wrapping, the bandwidth used is M in both directions
   of many of the links.  While in 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 6.  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).





Weingarten, et al.        Expires July 2, 2010                 [Page 18]


Internet-Draft                 MPLS-TP LP                  December 2009


                  +----------+----------+--------------+
                  |          | 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 between 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 multiple failures.

   Consider, for example, a double link failure affecting links B-C and
   C-D shown in Figure 6.  The Wrapping mechanism is not able to recover
   from the failure because B, upon detecting the failure, has no
   alternative paths to reach C. The whole P2MP traffic is lost.  The
   ROM-Wrapping mechanism is able to partially recover from the failure,
   because the backup P2MP LSP to node F and node D is correctly set up
   and continues delivering traffic.

3.2.  Steering for p2mp paths

   To take advantage of the ring topology in protecting the data traffic
   over p2mp LSPs, we can configure two p2mp unidirectional PST from
   each node on the ring that traverse the ring in both directions.
   These PST will be configured with an egress at each ring node.  For
   every LSP that enters the ring at a given node the traffic will be
   sent through one of these PST (the working PST) - pushing the PST
   label onto the packet label stack.  Each LSR on the ring will forward
   a copy of the packet along the PST, but check the packet by popping
   the PST label and examining the underlying LSP label.  If this LSR is
   an egress point for the LSP it will treat the data packet
   appropriately.  If the LSR is not an egress point for the LSP, the
   packet will be silently dropped.











Weingarten, et al.        Expires July 2, 2010                 [Page 19]


Internet-Draft                 MPLS-TP LP                  December 2009


                               ^            ^            ^
                              _|_          _|_          _|_
                       ----->/LSR\********/LSR\********/LSR\
                             \_A_/========\_B_/========\_C_/
                              +*              <+++++++++*||
                              +*                       +*||
                              +*                       +*||
                              +*                       +*||
                              +*_ ++++++++     +++++++++*||
                             /LSR\********/LSR\********/LSR\
                             \_F_/<=======\_E_/========\_D_/
                               |            |            |
                               V            V            V

           ---> connected LSP    *** physical link
           ===  primary p2mp PST +++ secondary p2mp PST

                            Figure 7: P2MP PSTs

   Using this PST architecture, we define a 1+1 linear protection
   mechanism [SurvivFwk] for all protected data traffic traversing the
   MPLS-TP ring.  The data for a particular p2mp LSP is transmitted on
   both the working and recovery PST, using a permanent bridge.  While
   each node detects that there is connectivity from the ingress point,
   it continues to select the data that is coming from the working path.
   If a particular node stops receiving the connectivity messages from
   the working path PST, it identifies that it must switch its selector
   to read the data packets from the recovery PST.

   Figure 7 shows the two unidirectional p2mp PST that are configured
   from LSR-A with egress points at all of the nodes on the ring.  The
   clockwise PST (i.e.  A-B-C-D-E-F) is configured as the working PST,
   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 PST (i.e.  A-F-E-D-C-B) is configured
   as the recovery PST.  Applying 1+1 linear protection to these two PST
   - a packet that arrives at LSR-A with a label stack [LI|BOS] will be
   forwarded on the clockwise PST with a label stack [PA1(F)|LI|BOS] and
   concurrently on the counter-clockwise PST with a label stack [PA2(B)|
   LI|BOS].

   Assume that the LSP "LI" has egress points at LSR-C & LSR-E.  When
   the packet arrives at LSR-B, LSR-D, and LSR-F, the LSR will forward
   the data packet to continue along the PST, e.g. at LSR-D the packet
   will be forwarded with label stack [PD1(F)|LI|BOS].  But in addition
   LSR-D will retain a copy of the packet, pop the PST label and examine
   the underlying LSP label.  Since LSR-D is not an egress point for
   LSP-LI, the packet will be dropped.  At LSR-C the data packet will be



Weingarten, et al.        Expires July 2, 2010                 [Page 20]


Internet-Draft                 MPLS-TP LP                  December 2009


   forwarded along the PST (with label stack [PC1(F)|LI|BOS], but when
   the retained copy is examined (after popping the PST label) it will
   determine that the packet is intended for this LSR as an egress point
   and switch the LSP label forwarding this packet with the label stack
   [LE|BOS].

   If a fault condition is detected, then some of the nodes will cease
   to receive the packets from the clockwise (working) PST.  These LSR
   should then begin to switch their selector bridge to accept the data
   packets from the counter-clockwise PST (i.e.  A-F-E-D-C-B), using a
   similar logic to that presented in the previous paragraph.

   This architecture has the added advantages that there is no need for
   the ingress node to identify the existence of the misconnectivity,
   and there is no need for a return path from the egress points to the
   ingress.


4.  Coordination protocol

   The Survivability Framework [SurvivFwk] indicates that there is a
   need to coordinate protection switching between the end-points of the
   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 cases of unidirectional fault detection and
   use of administrative operator commands.

   By using the same mechanisms defined in [LinProtect], for linear
   protection, to apply for ring protection we are able to gain a
   consistent solution for this coordination between the end-points of
   the protection domain.  The Protection State Coordination Protocol
   that is specified in [LinProtect] provides coverage for all the
   coordination cases, including support for administrative commands,
   e.g.  Forced-Switch.


5.  Interconnected rings

   The Requirements document [TPReqs] states that the ring protection
   must support a single ring that may be interconnected to other rings.
   In addition, traffic that traverses a number of rings within a
   network of interconnected rings must be protected even if the
   interconnection nodes and links fail.

   When interconnecting rings in a network there are two common
   interconnection schemes:




Weingarten, et al.        Expires July 2, 2010                 [Page 21]


Internet-Draft                 MPLS-TP LP                  December 2009


   o  Dual-node interconnect - when the interconnected rings are
      interconnected by two nodes from each ring (see Figure 8)

   o  Single-node interconnect - when the connection between the
      interconnected rings are through a single node (see Figure 9)

   The protection schemes presented in Section 2 are capable of
   protecting each interconnected ring as a separate entity independent
   of the other rings in the network.  This protects the traffic that
   traverses the entire network, as each ring will continue to transfer
   the traffic to the interconnection points, and from there to the next
   ring.

   When the interconnection nodes or links fail, there is the need to
   protect these connection points.  Therefore, it should be noted that
   in the case of single-node interconnect the interconnection node
   (LSR-A in Figure 9) is a single-point of failure and such an
   interconnection scheme should be avoided.  In the case of the dual-
   node interconnect scheme in Figure 8, the connection point over LSR-
   A<-->LSR-6 and LSR-F<-->LSR-5 could use basic linear protection as
   defined in [SurvivFwk] and [LinProtect] .

                      ____                     ___
                     / LSR\                   /LSR\
                   * \__B_/ *                *\_1_/*
                  *          *              *       *
                 *            *            *         *
             ___*              *___      _*_          * ___
            /LSR\              /LSR\****/LSR\          /LSR\
            \_C_/              \_A_/    \_6_/          \_2_/
              *     Ring #1      *        *   Ring #2    *
              *                  *        *              *
             _*_                _*_      _*_            _*_
            /LSR\              /LSR\    /LSR\          /LSR\
            \_D_/              \_F_/****\_5_/          \_3_/
                *              *           *            *
                 *            *             *          *
                   *   ____  *               *  ____  *
                     */ LSR\*                 */LSR \*
                      \__E_/                   \__4_/


                          *** physical link


                 Figure 8: Dual-node interconnected rings





Weingarten, et al.        Expires July 2, 2010                 [Page 22]


Internet-Draft                 MPLS-TP LP                  December 2009


                           ____                ___
                          / LSR\              /LSR\
                        * \__B_/ *           *\_1_/*
                       *          *         *       *
                      *            *       *         *
                  ___*              *___  *           * ___
                 /LSR\              /LSR\*             /LSR\
                 \_C_/              \_A_/              \_2_/
                   *     Ring #1      * *    Ring #2     *
                   *                  *  *               *
                  _*_                _*_  *  ___        _*_
                 /LSR\              /LSR\  */LSR\      /LSR\
                 \_D_/              \_F_/   \_5_/      \_3_/
                    *              *          *        *
                     *            *           *      *
                       *   ____  *            *___  *
                         */ LSR\*             /LSR\*
                          \__E_/              \_4_/


                               *** physical link

                Figure 9: Single-node interconnected rings


6.  Conclusions and Recommendations

   Based on the use of the Path Segment Tunnel construct, defined in
   [TPFwk] and [OAMFwk], it is possible to define a protection mechanism
   for MPLS-TP rings that is based on linear protection [SurvivFwk].
   This mechanism would be based on 1:1 linear protection for
   bidirectional or unidirectional p2p data paths, and 1+1 linear
   protection for unidirectional p2mp paths.  It has been shown that
   this protection architecture and mechanism fulfills the criteria
   defined in [TPReqs] for justification of designing a specific
   protection mechanism for a ring topology.

   It has also been shown that basing the ring protection on the
   existing linear protection mechanisms defined in [SurvivFwk] and
   [LinProtect], the operator has a choice of using either the wrapping
   or steering methodology for protection of both p2p and p2mp data
   traffic.  In addition, there is no need to define any new
   coordination protocol to complete this protection, instead depending
   upon the OAM functionality [outlined in [OAMFwk] and specified in
   various documents] and the coordination protocol specified for linear
   protection in [LinProtect].





Weingarten, et al.        Expires July 2, 2010                 [Page 23]


Internet-Draft                 MPLS-TP LP                  December 2009


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


8.  Security Considerations

   To be added in future version.


9.  Acknowledgements

   The authors would like to thank all members of the teams (the Joint
   Working Team, the MPLS Interoperability Design Team in IETF and the
   T-MPLS Ad Hoc Group in ITU-T) involved in the definition and
   specification of MPLS Transport Profile.


10.  Informative References

   [FRR]      Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
              Exensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.

   [TPReqs]   Niven-Jenkins, B., Nadeau, T., and C. Pignataro,
              "Requirements for the Transport Profile of MPLS",
              RFC 5654, April 2009.

   [TPFwk]    Bocci, M., Bryant, S., Frost, D., and L. Levrau, "MPLS-TP
              Framework", ID draft-ietf-mpls-tp-framework-06,
              October 2009.

   [OAMFwk]   Niven-Jenkins, B., Allan, D., and I. Busi, "MPLS-TP OAM
              Framework", ID draft-ietf-mpls-tp-oam-framework-04,
              October 2009.

   [SurvivFwk]
              Sprecher, N. and A. Farrel, "MPLS-TP Survivability
              Framework", ID draft-ietf-mpls-tp-survive-fwk-02,
              October 2009.

   [LinProtect]
              Sprecher, N., Bryant, S., van Helvoort, H., Fulignoli, A.,
              and Y. Weingarten, "MPLS-TP Linear Protection",
              ID draft-weingarten-mpls-tp-linear-protection-04,
              October 2009.



Weingarten, et al.        Expires July 2, 2010                 [Page 24]


Internet-Draft                 MPLS-TP LP                  December 2009


   [RSVP]     Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) - Functional
              Specifications", RFC 2205, September 1997.

   [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery (Protection and
              Restoration) Terminology for GMPLS", RFC 4427, March 2006.

   [G.841]    "Types and characteristics of SDH network protection
              architectures", ITU-T G.841, October 1998.


Authors' Addresses

   Yaacov Weingarten (editor)
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Phone: +972-9-775 1827
   Email: yaacov.weingarten@nsn.com


   Stewart Bryant
   Cisco
   United Kingdom

   Email: stbryant@cisco.com


   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Email: nurit.sprecher@nsn.com


   Danielle Ceccarelli (editor)
   Ericsson
   Via A. Negrone 1/A
   Genova, Sestri Ponente
   Italy

   Email: daniele.ceccarelli@ericsson.com





Weingarten, et al.        Expires July 2, 2010                 [Page 25]


Internet-Draft                 MPLS-TP LP                  December 2009


   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: marco.corsi@altran.it


   Bo Wu
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road
   Nanjing, Yuhuatai District
   P.R.China

   Email: wu.bo@zte.com.cn


   Xuehui Dai
   ZTE Corporation
   4F,RD Building 2,Zijinghua Road
   Nanjing, Yuhuatai District
   P.R.China

   Email: dai.xuehui@zte.com.cn








Weingarten, et al.        Expires July 2, 2010                 [Page 26]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/