[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                                     S. Bryant, Ed.
Internet-Draft                                                     Cisco
Intended status: Informational                          N. Sprecher, Ed.
Expires: April 28, 2010                                    Y. Weingarten
                                                  Nokia Siemens Networks
                                                        October 25, 2009


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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 April 28, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Bryant, et al.           Expires April 28, 2010                 [Page 1]


Internet-Draft                 MPLS-TP LP                   October 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes mechanisms to address the requirements for
   protection of ring topologies for Multi-Protocol Label Switching
   Transport Profile (MPLS-TP) Label Switched Paths (LSP) and
   Pseudowires (PW) on multiple layers.  Ring topologies offer the
   possibility of reducing the OAM overhead while providing a simplified
   protection mechanism.  The document analyzes two basic ring
   protection schemes and explains how ring protection can be viewed as
   an application of linear protection.



































Bryant, et al.           Expires April 28, 2010                 [Page 2]


Internet-Draft                 MPLS-TP LP                   October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Contributing Authors . . . . . . . . . . . . . . . . . . .  4
   2.  Ring Topologies  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Interconnected rings . . . . . . . . . . . . . . . . . . .  5
   3.  Ring protection schemes  . . . . . . . . . . . . . . . . . . .  7
     3.1.  Wrapping . . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  Optimization of wrapping . . . . . . . . . . . . . . .  9
     3.2.  Steering . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.1.  Point-to-Multipoint paths  . . . . . . . . . . . . . . 10
   4.  Conclusions and Recommendations  . . . . . . . . . . . . . . . 11
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12


































Bryant, et al.           Expires April 28, 2010                 [Page 3]


Internet-Draft                 MPLS-TP LP                   October 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 [MPLS-TP Reqs] inidcates that there is
   requirement to support a network that may include sections that
   constitute a MPLS-TP ring (either logical or physical).  The support
   for ring topologies as stated in the requirements is based on the
   ability to demonstrate that this topology allows the network to
   optimize either the protection or the number of Operations,
   Administration & Maintenance (OAM) entities needed to maintain the
   network.

   This document will examine different proposed mechanisms for
   protection of a ring in the context of MPLS-TP and try and determine
   how they may optimize the protection and the OAM procedures for a
   ring topology.  Finally, we plan to show how the generic protection
   mechanisms can be used to address the requirements in an optimized
   manner.

1.1.  Contributing Authors

   Akira Sakurai (NEC), Rolf Winter (NEC)


2.  Ring Topologies

   The MPLS-TP Requirements [MPLS-TP Reqs] defines a ring as a topology
   in which each LSR is connected to exactly two neighboring LSRs, each
   via a single point-to-point birectional MPLS-TP capable link.  A ring
   provides certain advantages in transport networks, including:

   o  Configuration of point-to-multipoint paths around a ring are
      easily accomplished.

   o  There are always two paths between any two LSRs on a ring that can
      be easily identified and associated.

   o  It is believed that the number of OAM entities needed, in order to
      detect faults and perform recovery actions, may be minimized in a
      ring topology.

   The following figure shows a MPLS-TP ring that is a segment that may
   be traversed by numerous LSPs or PWs.  In particular, the figure



Bryant, et al.           Expires April 28, 2010                 [Page 4]


Internet-Draft                 MPLS-TP LP                   October 2009


   shows that for all LSP that connect to the ring through LSR-B and
   exit the ring from LSR-F we can define two paths through the ring
   (the first path along B-A-F, and the second B-C-D-E-F).

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


           ===> connected LSP  *** physical link
           ###  logical path   @@@ secondary logical path

                         Figure 1: A MPLS-TP ring

2.1.  Interconnected rings

   The Requirements document [MPLS-TP Reqs] 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:

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

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

   The protection schemes presented in Section 3 are capable of
   protecting each interconnected ring as a separate entity independent



Bryant, et al.           Expires April 28, 2010                 [Page 5]


Internet-Draft                 MPLS-TP LP                   October 2009


   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 3) is a single-point of failure and such an
   interconnection scheme should be avoided.  The protection of the
   dual-node interconnect is essentially a linear-protection situation
   and should be protected using appropriate protection mechanisms.

                          ____                     ___
                         / 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 2: Dual-node interconnected rings














Bryant, et al.           Expires April 28, 2010                 [Page 6]


Internet-Draft                 MPLS-TP LP                   October 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 3: Single-node interconnected rings


3.  Ring protection schemes

   There are two classic mechanisms 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.

3.1.  Wrapping

   The "easier" recovery architecture is "wrapping".  This mechanism is
   local to the LSRs that are neighbors to the detected fault.  When a
   fault is detected, the neighboring LSR "wrap" all data traffic around
   the ring until arriving at the LSR that is on the opposite side of
   the fault, at which point the traffic continues on the normal working
   path until the egress from the ring segment.











Bryant, et al.           Expires April 28, 2010                 [Page 7]


Internet-Draft                 MPLS-TP LP                   October 2009


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

                   ===> connected LSP  *** physical link
                   ###  logical path   @@@ Bypass tunnel

                       Figure 4: Wrapping protection

   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
   there is the need for configuring a bypass tunnel [FRR] between A &
   F. The traffic will be transmitted over this bypass tunnel from A to
   F, and then will continue on the normal working path from F->E.
   Essentially, 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 via the
   bypass tunnel (at the near-end) or back to the normal path (at the
   far-end).

   When applying this scheme to a MPLS-TP ring topology segment there
   are the following considerations:

   o  The OAM should be performed at either the link level (by defining
      a TCME between each adjacent pair of LSR) and/or per LSR (by
      defining a TCME between the LSR that are neighbors of the
      protected LSR) when using node-level protection.





Bryant, et al.           Expires April 28, 2010                 [Page 8]


Internet-Draft                 MPLS-TP LP                   October 2009


   o  For each protected TCME there is a need to define a bypass tunnel
      that traverses the alternate path around the ring to connect
      between the two ends of the TCME.  If protecting both the links
      and the nodes, then, for a ring with N nodes, there is a need for
      O(2N) bypass tunnels.

   o  Protection of point-to-multipoint paths is similar to the simple
      protection since the data continues along the original path after
      wrapping around the ring.  The one exception is the case where the
      failed node was one of the egress points for the data.

   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 wrapping also involves greater latency in delivering the
      packets, as a result of traversing the entire ring.

   o  The resource allocation for the bypass tunnels could be
      problematic, since most of the tunnels 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.

3.1.1.  Optimization of wrapping

   It may be possible to optimize the basic performance, in terms of
   bandwidth utilization, of the Fast-reroute mechanism when protecting
   particular LSPs.  However, it is important to consider the basic
   criteria for ring protection, i.e. an appreciable minimization of the
   number of OAM sessions necessarily or the protection resources
   needed.

   One suggestion for optimization is to define the bypass tunnel to
   wrap only until the furthest egress point of the working LSP.  This
   method reduces the number of links that are traversed twice, in most
   cases, by not wrapping back to the working path at the far-end of the
   signal fault.  However, the method requires defining a particular
   bypass tunnel for each LSP and cannot use the optimization of the OAM
   sessions presented above to protect all LSPs with a single set of
   bypass LSPs.

3.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



Bryant, et al.           Expires April 28, 2010                 [Page 9]


Internet-Draft                 MPLS-TP LP                   October 2009


   egress point.  This is illustrated in Figure 1 above, where if a
   Signal Fault is detected on the working path (B-A-F), then the
   traffic is redirected by B to the secondary path (i.e.  B-C-D-E-F).

   When considering this mechanism it is almost identical to linear 1:1
   protection.  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 protection path and there is a need to
   coordinate the switchover between the two end-points of the protected
   path.

   There is one aspect that this diverts from the basic linear
   protection scheme - in the number of OAM sessions that would be
   neccesary to detect faults in the protected domain.  Whereas, using
   generic linear protection would neccesitate a separate OAM session
   per LSP that traverses the ring, when using ring protection there is
   a possiblity of taking proper advantage of the realization that we
   are dealing with a ring, and reduce the number of OAM sessions.  This
   is done by defining an OAM session on the basis of a Path Segment
   Tunnel (PST), i.e. between any two nodes of the ring.  This would
   lead to the number of OAM sessions for a ring with N nodes to be
   O(N*N/2), which could be very large.  However, taking into
   consideration that the required support of rings, is for rings with
   up-to 16 nodes - this implies that the number of OAM sessions should
   be on the order of (16*16/2) or 128.

   This form of OAM would allow the ingress LSR to directly detect any
   faulty situations and redirect traffic to the secondary path without
   the need for any additional communication to the LSR.

   The following observations can be drawn from using this protection
   mechanism for MPLS-TP ring topologies:

   o  Steering can be based on linear protection for the protection of a
      single ring.  For cases of interconnected rings further study is
      necessary.

   o  The number of OAM sessions can be greatly minimized, relative to
      using plain linear protection, by running the OAM sessions on the
      ring segments for all LSPs that traverse the ring, rather than
      running a OAM session per LSP.  This fulfills the objective
      presented in [MPLS-TP Reqs].

3.2.1.  Point-to-Multipoint paths

   [MPLS-TP Reqs] requires that ring protection must provide protection
   for unidirectional point-to-multipoint paths through the ring.  As
   was pointed out in section 1, ring topologies provide a ready



Bryant, et al.           Expires April 28, 2010                [Page 10]


Internet-Draft                 MPLS-TP LP                   October 2009


   platform for supporting such data paths.

   It is possible to create a protection architecture for p2mp within a
   MPLS-TP ring topology, based on 1+1 linear protection by monitoring
   two p2mp uni-directional PST from each ingress node on the ring with
   egress points at each node.  The two PST traverse the ring in
   opposite directions, i.e. one checks the clockwise path and the
   second the counter-clockwise path.

   The data for a particular p2mp LSP is transmitted on both the working
   and protecting LSP, 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 from the protecting path.

   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.  Conclusions and Recommendations

   In order to fulfill the requirements for protection of ring
   topologies for MPLS-TP networks, according to the conditions stated
   in [MPLS-TP Reqs], the protection should be based on MPLS-TP 1:1
   linear protection.  This mechanism will cover the cases of a single
   fault in a single ring topology.

   When defining the OAM behavior of the ring nodes, they should define
   a segment of all the LSPs that traverse a path within the ring.  The
   OAM should be executed for each ring path, i.e.  PST, to detect
   faults and trigger the protection switching within the ring.


5.  IANA Considerations

   This document makes no request of IANA.

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


6.  Security Considerations

   This document does not by itself raise any particular security



Bryant, et al.           Expires April 28, 2010                [Page 11]


Internet-Draft                 MPLS-TP LP                   October 2009


   considerations.


7.  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.


8.  Informative References

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

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


Authors' Addresses

   Stewart Bryant (editor)
   Cisco
   United Kingdom

   Email: stbryant@cisco.com


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

   Email: nurit.sprecher@nsn.com













Bryant, et al.           Expires April 28, 2010                [Page 12]


Internet-Draft                 MPLS-TP LP                   October 2009


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

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











































Bryant, et al.           Expires April 28, 2010                [Page 13]


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