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

Versions: 00 01 02 03 04 05

Network Working Group                                       Quintin Zhao
Internet-Draft                                                  Tao Chou
Intended status: Standards Track                       Huawei Technology
Expires: April 25, 2013                                      Boris Zhang
                                                    Telus Communications
                                                              Emily Chen
                                                        October 22, 2012


   P2MP Based mLDP Node Protection Mechanisms for Label Distribution
                Protocol P2MP/MP2MP Label Switched Paths
                draft-zhao-mpls-mldp-protections-03.txt

Abstract

   Existing techniques provide a Point-to-point (P2P) Label Switch Path
   (LSP) protection mechanism for mLDP nodes.  In situations where the
   data duplication along the p2p backup path is not acceptable, a
   Point-To-Multipoint (P2MP) or Multipoint-To-Multipoint (MP2MP) LSPs
   is needed, instead of a P2P LSPS, for the protection of mLDP nodes.

   This document defines procedures and protocol extensions for
   protection of mLDP nodes within Multi-Protocol Label Switching (MPLS)
   networks using P2MP and MP2MP backup LSPs.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 25, 2013.

Copyright Notice

   Copyright (c) 2012 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



Quintin Zhao, et al.     Expires April 25, 2013                 [Page 1]


Internet-Draft              mLDP Protections                October 2012


   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.

   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.































Quintin Zhao, et al.     Expires April 25, 2013                 [Page 2]


Internet-Draft              mLDP Protections                October 2012


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirement Language . . . . . . . . . . . . . . . . . . . . .  4
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  mLDP Node Protection using mLDP LSPs . . . . . . . . . . . . .  7
     4.1.  Signaling Procedures for P2MP Based Node Protection  . . .  8
       4.1.1.  Example of P2MP Based Node Protection's Procedure  . .  8
       4.1.2.  Choose backup upstream LSR . . . . . . . . . . . . . . 10
       4.1.3.  Create backup path by MRT  . . . . . . . . . . . . . . 11
       4.1.4.  PLR Switching Over Considerations  . . . . . . . . . . 12
       4.1.5.  mLDP End-to-End Protection . . . . . . . . . . . . . . 12
     4.2.  Signaling Procedures for MP2MP Based Node Protection . . . 13
     4.3.  Protocol Extensions for mLDP Based Node Protection . . . . 15
       4.3.1.  mLDP Based MP Protection Capability Parameter TLV  . . 15
       4.3.2.  mLDP Based MP Node Protection Status Elements  . . . . 16
       4.3.3.  mLDP Backup FEC Element Encoding . . . . . . . . . . . 16
   5.  Signaling Procedures for mLDP Based Facility Node
       Protection . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   7.  Manageability Considerations . . . . . . . . . . . . . . . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     10.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21






















Quintin Zhao, et al.     Expires April 25, 2013                 [Page 3]


Internet-Draft              mLDP Protections                October 2012


1.  Terminology

   This document uses terminology discussed in [RFC6388] and [I-D.ietf-
   mpls-ldp-multi-topology].  Additionally the following section
   provides further explanation for key terms and terminology:

   o  PLR: The node where the traffic is logically redirected onto the
      preset backup path is called Point of Local Repair (PLR).

   o  MP: The node where the backup path merges with the primary path is
      called Merge Point (MP).

   o  N: The node be protected.

   o  Pn: The nodes on the backup path for protecting node N.

   o  MT-ID: A 16 bit value used to represent the Multi-Topology ID.

   o  Default MT Topology: A topology that is built using the MT-ID
      default value of 0.

   o  MT Topology: A topology that is built using the corresponding
      MT-ID.

   o  cut-link: A link whose removal partitions the network.  A cut-link
      by definition must be connected between two cut-vertices.  If
      there are multiple parallel links, then they are referred to as
      cut-links in this document if removing the set of parallel links
      would partition the network.

   o  cut-vertex: A vertex whose removal partitions the network.

   o  MRT: Maximally Redundant Trees.  A pair of trees where the path
      from any node X to the root R along the first tree and the path
      from the same node X to the root along the second tree share the
      minimum number of nodes and the minimum number of links.  Each
      such shared node is a cut-vertex.  Any shared links are cut-links.
      Any RT is an MRT but many MRTs are not RTs.


2.  Requirement Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].






Quintin Zhao, et al.     Expires April 25, 2013                 [Page 4]


Internet-Draft              mLDP Protections                October 2012


3.  Introduction

   In order to meet user's demands, operators and service providers
   continue to deploy multicast applications using Multicast LDP (mLDP)
   across MPLS networks.  For the real-time applications, such as stock
   trading, on-line games, and multimedia teleconferencing, traditional
   IGP-mLDP convergence mechanisms fail to meet protection switching
   times required to minimize, or negate entirely, application
   interruptions.

   Current best practice for protecting services, and subsequently
   higher-layer applications, include the pre-computation and
   establishment of a backup path.  Once a failure has been detected on
   the primary path, the traffic will be transmitted across the back-up
   path.

   However, two major challenges exist with the aforementioned solution.
   The first is how to build an absolutely disjointed backup path for
   each node in a multicast tree; the second is how to balance between
   convergence time, resource consumption and network efficiency.

   For a primary LDP P2MP/MP2MP LSP, there are several methods to set up
   a backup path, these include:

   o  The use of an RSVP-TE P2P tunnel as a logical out-going interface,
      consequently utilize the mature high availability technologies of
      RSVP-TE.

   o  The use of an LDP P2P LSP as a packet encapsulation, so that the
      complex configuration of P2P RSVP-TE can be skipped.

   o  Creating a P2MP/MP2MP backup LSP according to IGP's loop-free
      alternative route.  This solution avoids unnecessary packet
      duplication compare to the use of a P2P LSP (which is specified in
      the draft of I-D.wijnands-mpls-mldp-node-protection)and can have
      100% scenario coverage if using with multi topology technology,
      where the backup topology either can be statically configured or
      dynamically computed/signaled mechanisms such the the mechanism
      specified in the draft of [I-D.ietf-rtgwg-mrt-frr-architecture].

   o  Creation of Multiple Topology (MT) LSP using an entirely
      disjointed topology.

   When the backup path is present, there are two options for packet
   forwarding and protection switchover:

   o  Option 1
      The traffic sender transmits the stream on both the primary and



Quintin Zhao, et al.     Expires April 25, 2013                 [Page 5]


Internet-Draft              mLDP Protections                October 2012


      backup path.  Once the local traffic receiver detects a failure
      the switchover will be relatively fast.  However the disadvantage
      of this method is that it consumes bandwidth as duplicate traffic
      will be sent on the protection and backup path.

   o  Option 2
      The traffic sender transmits only on the primary path.  Although
      bandwidth resource usage is minimized, cooperation is required to
      provide adequate switching times and minimize high-layer
      application impact.  Noted that, some mechanisms may need create
      more than one backup path, like the MRT, and need feed traffics on
      all the backup paths.  That means the MPs need to choose and
      accept only one traffic of all in such case.

   Ideally if switching time performance can be equal or better than the
   Option 1, it is reasonable to choose option 2 to avoid bandwidth
   wastage.  Some recommendations of this document are based on this
   viewpoint.

   This document specifies P2MP/MP2MP LSP based mLDP node protection.

   Note that the computation and configuration of the primary topology
   and backup topology is out of the scope of this draft, the algorithm
   can be either MRT based or any other algorithms/method available
   including the static and offline tools.  Besides, how to detect
   failure is also outside the scope of this document, the mechanism can
   be bidirectional or unidirectional forwarding detection for link or
   target object.

3.1.  Requirements

   A number of requirements have been identified that allow the optimal
   set of mechanisms to developed.  These currently include:

   o  Computation of a disjointed (link and node) backup path within the
      multicast tree;

   o  Minimization of protection convergence time;

   o  Minimization of operation and maintenance cost;

   o  Optimization of bandwidth usage;

   o  More protect scenarios can be covered.







Quintin Zhao, et al.     Expires April 25, 2013                 [Page 6]


Internet-Draft              mLDP Protections                October 2012


3.2.  Scope

   The method to detect failure is outside the scope of this document.
   Also this document does not provide any authorization mechanism for
   controlling the set of LSRs that may attempt to join a mLDP
   protection session.


4.  mLDP Node Protection using mLDP LSPs

   By using IGP-FRR or Multi Topology Routing(including the MRT MT
   routing), LDP can build the backup mLDP LSP among PLR, Pn, and MPs
   (the downstream nodes of the protected node).  In the cases where the
   amount of downstream nodes are huge, this mechanism can avoid
   unnecessary packet duplication on PLR, so that can protect the
   network from traffic congestion risk.


                               +------------+ Point of Local Repair/
                               |     R1     | Switchover Point
                               +------------+ (Upstream LSR)
                                  /       \
                                 /         \
                              10/           \20
                               /             \
                              /               \
                             /                 \
                       +----------+        +-----------+
        Protected Node |    R2    |        |     R3    |
                       +----------+        +-----------+
                         |       \         /        |
                         |        \       /         |
                         |         \     /          |
                       10|        10\   /20       20|
                         |           \ /            |
                         |            \             |
                         |           / \            |
                         |          /   \           |
                         |         /     \          |
                         |        /       \         |
                       +-----------+      +-----------+ Merge Point
                       |    R4     |      |    R5     | (Downstream LSR)
                       +-----------+      +-----------+


          Figure 1: mLDP Local Protection using mLDP LSP Example

   In Figure 1, R2 is on the preferential path from R4/5 to R1, and the



Quintin Zhao, et al.     Expires April 25, 2013                 [Page 7]


Internet-Draft              mLDP Protections                October 2012


   secondary path is through R3.  In this case, the mLDP LSP will be
   established according to the IGP preferential path as R1--R2--R4/R5.
   This section will take R2 as Protected Node for example, actually the
   Protected Node can be any Transit node of the mLDP LSP.  (We assume
   that all the nodes in Figure 1 support this mLDP based node
   protection method, including Pn.)

   The procedure of P2MP/MP2MP Based mLDP Node Protection is as follows:

   o  As Protected Node, R2 should announce its selected upstream node
      R1 to all its downstream nodes, which are R4 and R5 in this
      example.  How to know if one node should be protected can be
      decided by local configuration or its role(transit) in the mLDP
      LSP.

   o  R4 and R5 can consider R1 as the root node of the backup mLDP LSP,
      and trigger the backup LSP signaling.  In parallel, R4/R5 will
      bind the primary NHLFE(s) to both the backup and primary ILM
      entry, so that the traffic receiving from backup mLDP LSP can be
      merged locally to the primary LSP.

   o  PLR can distinguish primary LSP and backup LSP by the signaling
      procedure and only feed traffic on the primary path before
      failure.  When R2 node fails, R1 should switch the traffic to the
      preset backup path quickly.

   In this scenario, if R2 is protected by two P2P LSPs as R1--R3--R4
   and R1--R3--R5, the traffic will be duplicated on R1, and R3 will
   receive two streams.  But, If R2 is protected by a mLDP LSP instead,
   R3 will only receive one stream, and the packet duplication will be
   done on R3.

   The backup mLDP LSP can be P2MP/MP2MP LSP.  The P2MP backup LSP is
   used for P2MP LSP's node protection and the MP2MP backup LSP is used
   for MP2MP LSP's node protection.

4.1.  Signaling Procedures for P2MP Based Node Protection

   This section introduces the signaling procedures of P2MP LSP's node
   protection by backup P2MP LSP.

4.1.1.  Example of P2MP Based Node Protection's Procedure

   [Editors Note - This section introduces the procedures for P2MP Based
   Node Protection desires the PLR being capable for node failure
   detection.]

   We assume all the involved nodes have advertised their corresponding



Quintin Zhao, et al.     Expires April 25, 2013                 [Page 8]


Internet-Draft              mLDP Protections                October 2012


   protection capabilities.  And the following in this section
   demonstrates the signaling procedures of P2MP Based Node Protection.

   STEP1  Normal procedure of setting up primary path:
          Each non-Ingress LSR determine its own upstream LSR and sends
          out label mapping message, following the procedures as
          documented in [RFC6388] without any extension.  And its
          upstream LSR will propagate a new label mapping message to its
          upstream LSR.  In such case, we can say the non-Ingress LSR is
          MP(as R4, R5 in Figure 1), MP's upstream LSR is protected
          node(as R2 in Figure 1) and protected node's upstream node is
          PLR(as R1 in Figure 1).

   STEP2  Protected Node's procedure of setting up backup path:
          After the Protected Node (R2) determines its upstream LSR
          (R1), it will send the information(PLR's indentify, mLDP FEC)
          in Notification messages to all its downstream nodes(MPs)
          immediately.  If there are other LSR(s) becoming its
          downstream node(s) later, it will send such announcement for
          its new MP(s).

   STEP3  MP's procedure of setting up backup path:
          When one MP (R4/R5) receive the Notification, it individually
          determine its secondary paths toward R1 according to the IGP
          results.  Choosing which IGP mechanism's, LFA or MRT etc,
          results is a local determination.  After choosing the backup
          upstream LSR, MP will send out a FRR Label mapping messages
          including mLDP backup tree's key <PLR, protected-node,
          original-mLDP-FEC> and MT-ID if backup path is not in the
          default topology.  Noted that, the label assigned for primary
          path and secondary path MUST be different to avoid the MP
          feeding the primary traffic to its secondary path's downstream
          LSRs.  In addition, the original-mLDP-FEC of the backup tree
          key is encoded in a special opaque value as introduced in
          section 4.2.3.

   STEP4  Pn's procedure of setting up backup path:
          When one node receives such aforementioned FRR label mapping
          message, if it is not the PLR, it can consider itself as a Pn
          node and will choose its backup upstream node toward PLR on
          the corresponding topology's shortest IGP path.  To avoid the
          backup LSP going through the Protected Node, additional path
          selection rule(s) should be applied.  A simple method is that
          the transit nodes can not choose the specified Protected Node
          as its upstream LSR for the backup LSP.  Other methods, such
          as not-via policy, are under study, and will be added in the
          future.  In order to make the primary and backup topologies
          rooted from PLR to satisfy the 'maximum disjointed'



Quintin Zhao, et al.     Expires April 25, 2013                 [Page 9]


Internet-Draft              mLDP Protections                October 2012


          requirement, they can be either configured through static
          configurations or be signaled dynamically through other
          mechanisms such as MRT.

   STEP5  PLR's procedures of setting up backup path:
          When PLR(R1) receives the FRR label mapping message, it can
          identify that it is the PLR by the mLDP backup FEC elements,
          so it will decode the special opaque value(which contains the
          primary mLDP FEC element, introduced in section 4.2.3) and
          generate the backup forwarding entry for the specific LSP,
          which is identified by the root address and opaque value in
          the special opaque value, and bind the backup forwarding state
          to the specific primary entry, which is indicated by the
          Protected Node address in the message.  Note that there might
          be more than one backup forwarding entries for a specific
          protected node.

   STEP6  PLR's procedure when the Protected Node fails:
          When failure is detected by PLR, it will switch the traffic to
          the backup paths.  MP will also locally choose to receive
          which traffic and merge this traffic back to the primary LSP.
          The switchover manner on PLR is specified in the later
          section.

   STEP7  Procedure after network re-converges:
          When Merge Point(s) see the next hop to Root changed, it/they
          will advertise the new mapping message(s), and the traffic
          will re-converge to the new primary path.  MP then withdraw
          the backup label after finishing their re-converge.  Pn will
          delete the specified backup LSP like the procedure of deleting
          normal P2MP LSP.  And the entire backup P2MP LSP will be
          deleted when all the node MP leave the backup P2MP LSP.

4.1.2.  Choose backup upstream LSR

   Obviously, the backup path can not go through the protected node N,
   this section discusses how to choose the backup upstream LSR to avoid
   N.

   Firstly, finding out the candidate upstream LSRs as below:

   o  MPs should preferentially choose the upstream LSRs on the shortest
      path as candidates, except node N. If no other upstream LSRs on
      the shortest path, MPs should choose the next-hop on N's detour
      path as candidate.  The detour path can be IGP-FRR path or other
      topologies' disjoint paths.  The IGP-FRR path can be provided by
      LFA, U-Turn, etc.  The disjoint path can be provided by MT, MRT,
      etc.  How to choose the candidates is a local decision, can be



Quintin Zhao, et al.     Expires April 25, 2013                [Page 10]


Internet-Draft              mLDP Protections                October 2012


      determined by configuration.

   o  For the Pn node, it MUST choose from the IGP next-hops on the
      shortest path toward PLR within the topology specified in the FRR
      mLDP FEC element by MT-ID field.  The candidate upstream LSRs MUST
      except the node N.

   Then, each node can choose one from the candidate upstream LSRs as
   its backup upstream LSR, following the algorithm described in
   [RFC6388] section 2.4.1.1.

4.1.3.  Create backup path by MRT

   The algorithm of Maximally Redundant Trees(MRTs), which is defined in
   [I-D.enyedi-rtgwg-mrt-frr-algorithm], can compute two topologies(Blue
   and Red) automatically.  The two topologies can provide a pair of
   maximally disjoint paths from one MP to PLR.  The failed node will
   not exist in both of the paths, unless it is the cut-vertex.  So
   these paths can be used as backup paths for the mLDP node protection.

   Two backup multicast trees need be created along the MRT paths in
   each MRT topologies, because sometimes MPs can not indentify which
   path can avoid the failed node.  The tree in one MRT topology also
   uses the combination of <PLR, failed-node, original-mLDP-FEC> as its
   own key, and the two trees in different topologies is distinguished
   by MT-ID.  The MRT backup tree's creation uses the same procedure
   described as above.

   The announcement with PLR's information from the protected node
   triggers the MP to send backup mapping message along the MRT path in
   both topologies, with corresponding tree's key, labels and MT-ID.
   One node receives the backup message and find out it is not the PLR,
   then it send out a new backup mapping message along the corresponding
   path.  If one node's multicast upstream node can only be the
   protected node, this node can stop the procedure.  When PLR receives
   these messages, it associates the primary tree with the backup tree.
   PLR may receive two backup trees if both paths can avoid the
   protected node.

   Because one MRT tree may not include all MPs, PLR must feeds the
   traffics to both corresponding backup trees once PLR detects the
   failure.  And MPs may receive packets from both MRT paths, MPs MUST
   drop the packets in the Red topology in such case.

   MRT makes the solution more complex, but it can be deployed
   automatically and reach 100 percent scenario coverage in theory.





Quintin Zhao, et al.     Expires April 25, 2013                [Page 11]


Internet-Draft              mLDP Protections                October 2012


4.1.4.  PLR Switching Over Considerations

   The P2MP Based Node Protection also has the BFD scalability issue on
   the Protected node.  Similar with P2P Based Node Protection solution,
   this section provides two methods for deployment.

   o  Option 1:
      If PLR cannot differentiate link and node failure, MP must take
      the responsibility to drop one of the two reduplicate traffics
      when failure is detected.  In this case, the Node Failure Required
      Flag, in the P2MP Based MP Node Protection Status Element, must be
      set as 'N'.  PLR will switch the traffic to the backup path when
      failure detected and MP will drop traffic on the backup path until
      it sees N fails.

   o  Option 2:
      If PLR can differentiate link and node failure, PLR MUST NOT
      switch the traffic to the backup path until it detects the node N
      failure.  In this case, the Node Failure Required Flag, in the
      P2MP Based MP Node Protection Status Element, must be set as 'Y'.

   Note that, all the MPs of N MUST use one same Node Failure Required
   Flag value.  Otherwise, the backup P2MP LSP tree need depart to two
   trees different from the switch over type, and this part is TBD.  And
   it is also possible that can use a backup MP2MP LSP tree to protect
   one node in the primary MP2MP LSP tree, this part is TBD too

   [Editors Note - This Editors note and remaining options will be
   removed before publication of this document.]

4.1.5.  mLDP End-to-End Protection

   [I-D.ietf-mpls-ldp-multi-topology] provides the mechanism to setup
   disjointed LSPs within different topologies.  Applications can use
   these redundant LSPs for end-to-end protection based on MT.

   The backup topologies can be build by static configuration or
   automatic computation.  The static method need create the disjoint
   trees artificially in one topology, root node can setup 1:1 or 1+1
   End-to-End protection, using these backup disjoint mLDP LSP.  The
   automatic method can use MRT algorithm.  MRT can also provide
   maximally disjoint P2P paths to build a pair of redundant multicast
   trees from leaves to root.  This section mainly analyses the
   automatic method.

   The procedure of building backup multicast trees by MRT just like the
   creation of primary multicast tree.  Leaf triggers building multicast
   tree along the path toward root in both MRT topologies, colored as



Quintin Zhao, et al.     Expires April 25, 2013                [Page 12]


Internet-Draft              mLDP Protections                October 2012


   Blue and Red, separately.

   Each MRT backup tree can cover all the leaves, but two different sets
   of leaves maybe share one same mid node(not the cut-vertex).
   Therefore, the root must feed traffic to both two MRT trees when
   failure, and the leaves must drop the packets in the Red topology if
   receives packets on both MRT backup tree.

   Take Figure 2 for example, node R is the root and the other nodes are
   leaves.  When the node G breaks, node F,D will not receive traffic in
   Blue MRT and node E,B will not receive traffic in Red MRT.
   Therefore, only feeds traffics in both MRTs can protect all leaves.
   In addition, node A,C can receive traffics in both MRTs, they must
   choose dropping the one in Red MRT.


    [A]---[R]---[B]---+      [A]<--[R]-->[B]---+     [A]   [R]   [B]
     |     |     |    |       |           |    |      ^     |     ^
     |     |     |    |       V           |    V      |     V     |
    [C]---[D]    |   [E]     [C]   [D]    |   [E]    [C]<--[D]    |   [E]
           |     |    |             ^     |                 |     |    ^
           |     |    |             |     V                 V     |    |
          [F]---[G]---+            [F]<--[G]               [F]-->[G]---+

   (a) Original topology   (b) Blue MRT of root R   (c) Red MRT of root R

              Figure 2: mLDP End-to-End Protection using MRT

   Because MRT computation is separate in different areas, in the case
   of inter-area, root and leaves are not in the same area, the
   BR(Border Router) must do some special procedure for protecting
   another BR.  For example, BR1 and BR2 cross the area(x) and area(y).
   Root is in area(y).  One node, LSR1, in area(x) may choose BR1 as its
   Red MRT upstream LSR to against BR2's failure.  But maybe BR1 will
   choose BR2 as its Red MRT upstream LSR in area(y).  LSR1 will receive
   no traffic when BR2 fails.  To solving such problem, BR can choose to
   treat itself as a leaf when it receives the mLDP mapping message,
   which need cross areas, in MRT topology.  That means BR needs to join
   both the Blue and Red MRT trees in such case, and drops the Red MRT's
   traffic if it receives traffic in both MRTs.

   In order to reduce the packets' loss in convergence, End-to-End
   Protection also needs leaves to support MBB procedure.

4.2.  Signaling Procedures for MP2MP Based Node Protection

   This section introduces the solution to protect MP2MP LSP node by
   backup MP2MP LSP.



Quintin Zhao, et al.     Expires April 25, 2013                [Page 13]


Internet-Draft              mLDP Protections                October 2012


   The procedure is similar with the P2MP based node protection.  MP
   send backup label mapping message with MP2MP downstream FRR FEC
   element.  When PLR receives backup label mapping message with MP2MP
   downstream flag, it send the backup label mapping message with mp2mp
   upstream FRR FEC element to Pn, and then finally to MPs.  This
   procedure just follows the normal MP2MP LSP procedure.

   PLR node binds its backup MP2MP downstream NHLFE entry to primary
   MP2MP downstream ILM entry and binds its primary MP2MP upstream NHLFE
   entry to backup MP2MP upstream ILM entry.

   MP node binds its primary MP2MP downstream NHLFE entry to backup
   MP2MP downstream ILM entry and binds its backup MP2MP upstream NHLFE
   entry to primary MP2MP upstream ILM entry.

   Once detecting the protected node failure, PLR switches the
   downstream traffic to backup path and MP switches the upstream
   traffic to backup path.

   End-to-End protection can also use the backup multicast tree to
   protect MP2MP applications.  The biggest difference between End-to-
   End and Node protection is the detecting method, which is outside the
   scope of this document.  In addition, the MRT may not suitable for
   MP2MP End-to-End protection at present.  The disjoint path from leaf
   to root can not provide protection for the traffic from leaf to leaf.
   Because the upstream traffic sent from leaf to leaf include two
   directions, downstream and upstream.  One node may be another one's
   downstream LSR in both directions of both MRT topologies.

   For example in figure 3, node R is the root and the other nodes are
   leaves of the MP2MP LSPs.  The downstream traffic from root to leaves
   is along the path shown in sub figure (b) and (c), and the upstream
   traffic from leaf G to other nodes is along the path shown in sub
   figure (e) and (f).  Obviously, if the node F breaks, the node D can
   not receive the traffic sent by leaf G in both MRT topologies.
















Quintin Zhao, et al.     Expires April 25, 2013                [Page 14]


Internet-Draft              mLDP Protections                October 2012


    [A]---[R]---[B]          [A]<--[R]-->[B]          [A]   [R]   [B]
     |     |     |            |           |            ^     |     ^
     |     |     |            V           |            |     V     |
    [C]---[D]    |           [C]   [D]    |           [C]<--[D]    |
           |     |                  ^     |                  |     |
           |     |                  |     V                  V     |
          [F]---[G]                [F]<--[G]                [F]-->[G]

   (a) Original topology   (b) Blue MRT of root R   (c) Red MRT of root R

     [A]<--[R]<--[B]          [A]   [R]   [B]
      |           ^            ^     ^     ^
      V           |            |     |     |
     [C]   [D]    |           [C]<--[D]    |
            ^     |                  ^     |
            |     |                  |     |
           [F]<--[G]                [F]<--[G]

   (e) Blue MRT of root G  (f) Red MRT of root G


      Figure 3: The problem of MP2MP End-to-End Protection using MRT

   [TBD]This section is still in research, the details will be shown in
   the future versions.

4.3.  Protocol Extensions for mLDP Based Node Protection

4.3.1.  mLDP Based MP Protection Capability Parameter TLV

   A new Capability Parameter TLV is defined as mLDP Based MP Protection
   Capability for node protection.  Following is the format of this new
   Capability Parameter TLV:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |1|0| mLDP Based MP Prot.(IANA) |          Length (= 2)         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |S| Reserved    |
       +-+-+-+-+-+-+-+-+

       S: As specified in [RFC5561]


               Figure 4: mLDP Based MP Protection Capability

   This is an unidirectional capability announced.



Quintin Zhao, et al.     Expires April 25, 2013                [Page 15]


Internet-Draft              mLDP Protections                October 2012


   An LSR, which supports the mLDP based protection procedures, should
   advertise this mLDP Based MP Protection Capability TLV to its LDP
   speakers.  Without receiving this capability announcement, an LSR
   MUST NOT send any message including the mLDP Based MP Node Protection
   Status Element and mLDP Backup FEC Element to its peer.

   Capability Data might be needed to distinguish the capabilities of
   different nodes, such as PLR, MP, N, Pn and so on.  This part is TBD.

4.3.2.  mLDP Based MP Node Protection Status Elements

   A new type of LDP MP Status Value Element is introduced, for
   notifying upstream LSR information.  It is encoded as follows:



        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |mLDP FRR Type=3|      Length                   |   Reserved    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                    PLR Node Address                           ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 5:  FRR LDP MP Status Value Element


      mLDP FRR Type:  Type 3 (to be assigned by IANA)

      Length:  If the Address Family is IPv4, the Length MUST be 5;
      if the Address Family is IPv6, the Length MUST be 17.

      PLR Node Address:  The host address of the PLR Node.


4.3.3.  mLDP Backup FEC Element Encoding

   A new type of mLDP backup FEC Element is introduced, for notifying
   upstream LSR information.  It is encoded as follows:











Quintin Zhao, et al.     Expires April 25, 2013                [Page 16]


Internet-Draft              mLDP Protections                October 2012


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |mLDP FEC T=FRR |         Address Family        | Address Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        PLR Node Address                       ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N| Status code | FEC-Type      |        MT-ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Protected Node Address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Opaque Length              |    Opaque Value ...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   ~                                                               ~
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 6: mLDP Backup FEC Element


   mLDP FEC Type-FRR:  Type 5 (to be assigned by IANA)

   Length:  If the Address Family is IPv4, the Address Length MUST be 9;
            if the Address Family is IPv6, the Address Length MUST be 33.

   Status code:  1 = Primary path for traffic forwarding
                 2 = Secondary path for traffic forwarding

   FEC-Type: 6 = P2MP FEC type
             7 = MP2MP-up FEC type
             8 = MP2MP-down FEC type

   PLR Node Address:  The host address of the PLR Node.

   Protected Node Address:  The host address of the Protected Node.

   N Bit: Node Failure Required Flag, the occasion of switching traffic's on PLR
           1 = 'Y', switch traffic to backup path only when PLR detects the node failure
           0 = 'N', switch traffic to backup path when PLR detects failure

   Opaque Length:  The length of the opaque value, in octets.







Quintin Zhao, et al.     Expires April 25, 2013                [Page 17]


Internet-Draft              mLDP Protections                October 2012


   Opaque Value: One or more MP opaque value elements, the same definition in [RFC6388].
                 Specially for the FRR mLDP FEC element, the Opaque Value MUST be encoded
                 as the Recursive Opaque Value, which is defined in [RFC6512]. The value
                 fields of the Recursive Opaque Value contains the original primary
                 path's mLDP FEC element.


    The encoding for this Recursive Opaque Value, as defined in [RFC6512], is shown in Figure 5.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type = 7     |         Length                |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
    ~                                                               ~
    |                 P2MP or MP2MP FEC Element                     |
    |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


          Figure 7: Recursive Opaque Value, defined in [RFC6512]

   The Opaque Value is encoded by MP node and decoded by PLR.  Other
   nodes MUST NOT interpret the opaque value at all.


5.  Signaling Procedures for mLDP Based Facility Node Protection

   [TBD]In the detour solution, one backup LSP protects one primary one.
   So if there are several mLDP LSPs using one backup path, there will
   be several backup LSPs on one same backup path.  In such case, this
   may cause one kind waste of LSP resource.  Using the facility node
   protection solution can minimize such waste, the cost is making the
   procedure more complicated.

   MP chooses its primary upstream LSR as N and send label mapping
   message to N. When N receives the label mapping message from MP, it
   will assign a upstream label to MP.  MP uses this upstream label as
   its incoming label and release the label resource it used for this
   LSP before.  Then MP will find the backup mLDP LSP by the specified
   PLR and N address, if no such LSP exists, MP will trigger creating
   one.  The backup mLDP LSP is exclusive by PLR and N address.  N uses
   this upstream label as its own incoming label and send this label's
   label mapping message to PLR.  After PLR create the primary LSP, it
   will find one backup mLDP LSP by the specified PLR and N address.  If
   there exists one such LSP, PLR will bind the backup LSP to primary



Quintin Zhao, et al.     Expires April 25, 2013                [Page 18]


Internet-Draft              mLDP Protections                October 2012


   one.

   When PLR detects the N's failure, it switches traffic to backup path
   using dual label stack, the inner label is the outgoing label from N
   and the outer label is the backup LSP's outgoing label from Pn.  MP
   will receive the traffic from Pn, which is same as the traffic from
   N.

   The key point of the facility solution is node N how to assign the
   upstream label.  This solution is still under research.


6.  IANA Considerations

   This memo includes the following requests to IANA:

   o  mLDP Based MP Protection Capability.

   o  mLDP FRR types for LDP MP Status Value Element.

   o  mLDP FEC FRR Element type.


7.  Manageability Considerations

   [Editors Note - This section is TBD.]


8.  Security Considerations

   The same security considerations apply as for the base LDP
   specification, as described in [RFC5036].  The protocol extensions
   specified in this document do not provide any authorization mechanism
   for controlling the set of LSRs that may attempt to join a mLDP
   protection session.  If such authorization is desirable, additional
   mechanisms, outside the scope of this document, are needed.

   Note that authorization policies should be implemented and/or
   configure at all the nodes involved.

   Note that authorization policies should be implemented and/or
   configure at all the nodes involved.


9.  Acknowledgements

   We would like to thank Nicolai Leymann and Daniel King for his
   valuable suggestions regarding to this draft.  We also would like to



Quintin Zhao, et al.     Expires April 25, 2013                [Page 19]


Internet-Draft              mLDP Protections                October 2012


   thank Robin Li, Lujun Wan for their comments and suggestions to the
   draft.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

   [RFC6348]  Le Roux, JL. and T. Morin, "Requirements for Point-to-
              Multipoint Extensions to the Label Distribution Protocol",
              RFC 6348, September 2011.

   [RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
              "Label Distribution Protocol Extensions for Point-to-
              Multipoint and Multipoint-to-Multipoint Label Switched
              Paths", RFC 6388, November 2011.

   [RFC6512]  Wijnands, IJ., Rosen, E., Napierala, M., and N. Leymann,
              "Using Multipoint LDP When the Backbone Has No Route to
              the Root", RFC 6512, February 2012.

10.2.  Informative References

   [I-D.ietf-mpls-ldp-multi-topology]
              Zhao, Q., Fang, L., Zhou, C., Li, L., and N. So, "LDP
              Extensions for Multi Topology Routing",
              draft-ietf-mpls-ldp-multi-topology-04 (work in progress),
              July 2012.

   [I-D.wijnands-mpls-mldp-node-protection]
              Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
              A., and Q. Zhao, "mLDP Node Protection",
              draft-wijnands-mpls-mldp-node-protection-01 (work in
              progress), June 2012.

   [I-D.ietf-rtgwg-mrt-frr-architecture]



Quintin Zhao, et al.     Expires April 25, 2013                [Page 20]


Internet-Draft              mLDP Protections                October 2012


              Atlas, A., Kebler, R., Envedi, G., Csaszar, A.,
              Konstantynowicz, M., White, R., and M. Shand, "An
              Architecture for IP/LDP Fast-Reroute Using Maximally
              Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01
              (work in progress), March 2012.

   [I-D.enyedi-rtgwg-mrt-frr-algorithm]
              Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan,
              "Algorithms for computing Maximally Redundant Trees for
              IP/LDP Fast- Reroute",
              draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in
              progress), October 2012.


Authors' Addresses

   Quintin Zhao
   Huawei Technology
   125 Nagog Technology Park
   Acton, MA  01719
   US

   Email: quintin.zhao@huawei.com


   Tao Chou
   Huawei Technology
   156 Beiqing Rd
   Haidian District, Beijing  100095
   China

   Email: tao.chou@huawei.com


   Boris Zhang
   Telus Communications
   200 Consilium Pl Floor 15
   Toronto, ON  M1H 3J3
   Canada

   Phone:
   Email: Boris.Zhang@telus.com









Quintin Zhao, et al.     Expires April 25, 2013                [Page 21]


Internet-Draft              mLDP Protections                October 2012


   Emily Chen
   2717 Seville Blvd, Apt 1205
   Clearwater, FL  33764
   US

   Email: emily.chen220@gmail.com













































Quintin Zhao, et al.     Expires April 25, 2013                [Page 22]


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