Protocol Independent Multicast Working Group              R. Kebler, Ed.
Internet-Draft                                                  A. Atlas
Intended status: Standards Track                        Juniper Networks
Expires: January 13, 2014                                        N. Shen
                                                     Cisco Systems, Inc.
                                                                  Y. Cai
                                                               Microsoft
                                                           July 12, 2013


     PIM Extensions for Protection Using Maximally Redundant Trees
                   draft-kebler-pim-mrt-protection-01

Abstract

   This document specifies Protocol Independent Multicast (PIM)
   procedures for Failure Protection, as specified in the MRT Multicast
   architecture [I-D.atlas-rtwg-mrt-mc-arch].  This can be accomplished
   with Global Repair (aka Live-Live) or with Local Repair (aka Fast Re-
   route).  Maximally Redundant Trees (MRTs) provide the capability to
   PIM to provide alternate paths around any given failure.

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 January 13, 2014.

Copyright Notice

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

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



Kebler, et al.          Expires January 13, 2014                [Page 1]


Internet-Draft          PIM Protection using MRTs              July 2013


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Global Protection (Live-Live) . . . . . . . . . . . . . . . .   4
     3.1.  Egress Router Behavior  . . . . . . . . . . . . . . . . .   4
     3.2.  Limitation when a LAN is a cut-link . . . . . . . . . . .   4
     3.3.  Using Different Groups to identify MRTs . . . . . . . . .   5
   4.  Local Protection  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  PLR Replication . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  PLR Behavior  . . . . . . . . . . . . . . . . . . . .   6
       4.1.2.  Unicast convergence during PLR Replication  . . . . .   6
       4.1.3.  MP Behavior . . . . . . . . . . . . . . . . . . . . .   6
       4.1.4.  Downstream Routers from the MP  . . . . . . . . . . .   7
       4.1.5.  Protected Node Behavior . . . . . . . . . . . . . . .   7
   5.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Hello Options . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.1.  MRT Protection Capabilities . . . . . . . . . . . . .   8
     5.2.  Join Attributes . . . . . . . . . . . . . . . . . . . . .   9
       5.2.1.  Merge Point Attribute . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document specifies how to reduce traffic loss after network
   failures by using Maximally Redundant Trees (MRTs).  This can be
   accomplished with Global Repair (aka Live-Live) or with Local Repair
   (aka Fast Re-route).  The tradeoffs and applicability for each method
   of protection are discussed in the MRT Multicast architecture
   [I-D.atlas-rtwg-mrt-mc-arch].

   With Global Repair, a multicast egress will send PIM Joins for the
   same stream on multiple MRT topologies.  The Global Repair specified
   in this document is similar to [I-D.ietf-rtgwg-mofrr].  This document
   specifies how this can be accomplished using MRTs, however, providing
   100% coverage without requiring any particular network topology.




Kebler, et al.          Expires January 13, 2014                [Page 2]


Internet-Draft          PIM Protection using MRTs              July 2013


   Local Repair for Link or Node protection can also be used to protect
   Multicast traffic.  A Point of Local Repair (PLR) can replicate the
   traffic to all Merge Points (MPs).  In order to accomplish this, the
   PLR must know the unicast destination of all MPs.  Upon the failure,
   the PLR will send the traffic to all MPs.

2.  Terminology

   2-connected:   A graph that has no cut-vertices.  This is a graph
      that requires two nodes to be removed before the network is
      partitioned.

   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.

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

   Maximally Redundant Trees (MRT):   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.

   Maximally Redundant Multicast Trees (MRMT):   A pair of multicast
      trees built of the sub-set of MRTs that is needed to reach all
      interested receivers.

   network graph:   A graph that reflects the network topology where all
      links connect exactly two nodes and broadcast links have been
      transformed into the standard pseudo-node representation.

   Redundant Trees (RT):   A pair of trees where the path from any node
      X to the root R along the first tree is node-disjoint with the
      path from the same node X to the root along the second tree.
      These can be computed in 2-connected graphs.

   Merge Point (MP):   For local repair, a router at which the alternate
      traffic rejoins the primary multicast tree.  For global
      protection, a router which receives traffic on multiple trees and
      must decide which stream to forward on.

   Point of Local Repair (PLR):   The router that detects a local
      failure and decides whether and when to forward traffic on
      appropriate alternates.



Kebler, et al.          Expires January 13, 2014                [Page 3]


Internet-Draft          PIM Protection using MRTs              July 2013


   MT-ID:   Multi-topology identifier

   Stream Selection:   The process by which a router determines which of
      the multiple primary multicast streams to accept and forward.  The
      router can decide on a packet-by-packet basis or simply per-
      stream.  This is done for global protection as described in
      [I-D.ietf-rtgwg-mofrr].

   MultiCast Egress (MCE):   Multicast Egress, a node where the
      multicast stream exists the current PIM domain.  This is usually a
      receiving router that may forward the multicast traffic towards
      receivers based upon IGMP or other technology.

3.  Global Protection (Live-Live)

   In order to achieve Global Protection, traffic will flow through the
   network through disjoint paths.  A multicast egress (MCE) router will
   trigger this traffic flow by sending PIM joins on two different
   interfaces.  The MRT algorithm will ensure that these joins travel
   through maximally disjoint paths to the source.  The egress router
   must then forward a single stream along to its downstream members.
   Any failure in the network to either stream can be repaired by this
   egress router, since it is receiving the redundant stream.

   Any router that is capable of supporting Global Repair with MRTs must
   advertise the T bit in the MRT Protection Hello Option.

3.1.  Egress Router Behavior

   A multicast egress (MCE) router will join a multicast stream on both
   the Blue and Red MRT.  The MT-ID [RFC6420] of the MRT will be
   included in the Join as a Join Attribute [RFC5384].  Traffic will
   flow down both MRTs to the egress router to achieve redundancy.  The
   egress router will forward a single stream along to its downstream
   interfaces.  The techniques for this stream selection are described
   in MoFRR [I-D.ietf-rtgwg-mofrr].

3.2.  Limitation when a LAN is a cut-link

   There is a limitation in end-to-end protection when, for a given S,G,
   the MRTs converge on a single LAN with different upstream neighbors.
   In this case, both upstream neighbors will be sending on the LAN, and
   there is no distinguishing the data traffic for the different MRTs if
   it is carried with the same S,G.  The PIM Assert procedures will
   select a single forwarding router on the LAN and the other router
   will stop sending.  This could cause the Assert Loser to prune back
   the S,G. Therefore, traffic will flow on only one MRT between the
   source and the downstream router on the LAN.



Kebler, et al.          Expires January 13, 2014                [Page 4]


Internet-Draft          PIM Protection using MRTs              July 2013


3.3.  Using Different Groups to identify MRTs

   There may be cases when different sources or groups are used to send
   the same stream, as decribed in the MRT Multicast architecture
   [I-D.atlas-rtwg-mrt-mc-arch].  In this case the egress router may not
   need to perform the stream selection.  However, it would be desirable
   for the egress router to join the sources or groups on different
   MRTS.  The mechanism to perform group to MRT mapping is outside the
   scope of this document.  Once the egress router knows the group to
   MRT mapping, then it will join for the S,G on the particular tree by
   including the MT-ID for the MRT in the Join message.  In this case,
   the streams can travel across the same LAN without the issues
   described above.

4.  Local Protection

   Local Protection can protect either a link or node, and this will be
   determined on a per flow basis.  A Join Attribute will be used for
   downstream routers to signal the Merge Point information.  Each
   router will advertise in its MRT Protection Hello Options whether it
   is capable of performing Link or Node protection.

4.1.  PLR Replication

   At a PLR, each S,G flow will have a set of downstream interfaces and
   a set of MPs for each downstream interface.  There will be MPLS label
   information learned for each MP.  Upon a failure to the protected
   link, the PLR will encapsulate and send the protected multicast
   traffic to all MPs for that particlar (S,G,intf).  The MP will,
   therefore, receive the encapsulated data upon the failure and traffic
   will resume to all of its downstream receivers.  Once the PLR has
   given the downstream routers sufficient time to recover from the
   failure, it can stop sending the protected traffic, and prune
   upstream, if required.

   For the PLR to send the protected traffic upon a failure, it requires
   the unicast address and an MPLS label (which may be Implicit Null)
   for all the Merge Points.  Each MP will advertise this information in
   a Merge Point Join Attribute.  If link protection is used, this is
   sufficient to reach the PLR.  For node protection, the information
   for all MPs will be sent to the PLR in a Join Attribute from the
   upstream node of the MP (i.e., the Protected Node).  In this case,
   the MP will set the N bit in these Join Attributes to indicate the
   Protected Node needs to send the Join Attribute upstream to the PLR.
   If the MP or the Protecting Node is sending the Join attribute to the
   PLR, it will set the P bit in the Join Attribute.





Kebler, et al.          Expires January 13, 2014                [Page 5]


Internet-Draft          PIM Protection using MRTs              July 2013


   All routers that support this functionality will advertise the Link
   or Node capability bits in the MRT Protection Hello Option.  Any Node
   that is capable of acting as a PLR will advertise the PLR-Replication
   capable bit in the MRT Protection Hello Option.

4.1.1.  PLR Behavior

   The PLR will learn the location of all the MPs in the its Join
   Messages that it receives from downstream routers.  The Merge Points
   will be kept per (S,G, downstream-interface).  Upon a failure to the
   protected interface, the PLR will encapsulate and forward the
   multicast data to all the MPs for that downstream interface, and it
   will start the Alternate-Tree-Protection-Timer.  The Alternate-Tree-
   Protection-Timer should be a configurable timer with a default of 10
   seconds.  The PLR will suppress the PIM Prunes from being sent while
   the Protection-Timer is running.  Once this timer expires, it will
   stop sending the traffic to MPs, and it can send a Prune upstream if
   required.

   For a PLR to learn of all MPs, then Join Suppression must be disabled
   on the interfaces between the MP and the PLR.  In addition, the PLR
   must accept all MP ID Join Attributes that it receives from
   downstream neighbors.

4.1.2.  Unicast convergence during PLR Replication

   Since it is likely for unicast routes to converge before PIM fully
   converges, the PLR must still be able to route the traffic to all MPs
   while unicast recovers from the original failure.  The PLR must not
   use stale forwarding information to reach the MPs for the protected
   multicast traffic if unicast has already updated it forwarding
   entries after the network event.  An implementation should use the
   same forwarding information that would be used to forward unicast
   traffic to that destination.  In this way, the PLR will be able to
   forward traffic to the MPs.

4.1.3.  MP Behavior

   As is done today, the MP will forward traffic received on its normal
   incoming interface.  While the normal RPF interface is up,
   encapulated alternate traffic will not be forwarded.  If the RPF
   interface fails, the MP will forward the encapulated alternate
   traffic (if it is received with the correct encapsulation).  This
   procedure assumes that there is a method for the routers on both
   sides of the protected link to determine if the link has gone down.
   Such methods are outside the scope of this document.





Kebler, et al.          Expires January 13, 2014                [Page 6]


Internet-Draft          PIM Protection using MRTs              July 2013


   After the incoming interface changes the MP will start the Alternate-
   Tree-Protection-Timer.  Once traffic arrives on the new incoming
   interface or the Alternate-Tree-Protection-Timer expires, the Merge
   Point will advertise the label for the new RPF interface in the Merge
   Point Join Attribute, and it will stop accepting the encapsulated
   alternate traffic.

   The MP needs to know when it can release the label that it has
   advertised and potentially re-use that label for another purpose.  If
   the interface goes down or the adjacency goes down on an interface
   that the MP was advertising a label, it should wait JP_Holdtime for
   link protection and (2 * JP_Holdtime) for node protection before re-
   using that label for any other purpose.

4.1.4.  Downstream Routers from the MP

   Some make-before-break techniques should be used on routers
   downstream from the failure to ensure that traffic is not discarded
   once these routers learn of the unicast change.  For example, if a
   downstream router, upon a unicast route change, prunes itself off its
   old RPF interface and discards traffic until the new tree is formed
   back to the source, then there will be end-to-end loss.  The work
   that the upstream routers did to repair the local failure will be
   wasted since the downstream router is going to discard flowing
   traffic.  The make-before-breaks procedures needed on the downstream
   router is outside the scope of this document.

4.1.5.  Protected Node Behavior























Kebler, et al.          Expires January 13, 2014                [Page 7]


Internet-Draft          PIM Protection using MRTs              July 2013


   For Node Protection, the MP will be one hop away from the Protected
   Node and two hops away from the PLR.  In this case, there may be
   multiple next-next-hops to advertise as Merge Points in the Join
   Attribute.  The Protected Node will learn the downstream members and
   it will gather the MP information from each downstream neighbor's
   Merge Point Join Attribute.  For each Merge Point in the downstream
   list, the Protected Node will include a Merge Point Join Attribute in
   the Join that is sent upstream to the PLR.  These Join attributes
   must have the N bit cleared when they are sent to the PLR.  The PLR
   will add a Merge Point attribute for its own information to include
   itself as a Merge Point.  All the Join attributes will have the P bit
   set, indicating they are being sent to a PLR.  The Merge Point
   information may change for a route entry before the JoinPrune would
   normally be updated or refreshed to the PLR.  Upon a change to the
   next-next hop list, the router can send a triggered JoinPrune with
   the updated Join Attribute, or it can wait for the next periodic
   refresh.  It would be a tradeoff of increased control messages
   against a window of being unprotected.  For a PLR to learn of all
   MPs, then Join Suppression must be disabled on the interfaces between
   the MP and the PLR.

5.  Packet Formats

5.1.  Hello Options

5.1.1.  MRT Protection Capabilities


      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 = TBD          |         Length = 1            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Rsvd  |P|T|L|N|
      +-+-+-+-+-+-+-+-+



                    MRT Protection Hello Option Format

      Type: TBD.

      Length: 1



         Rsvd: Sent with 0, ignored on receipt




Kebler, et al.          Expires January 13, 2014                [Page 8]


Internet-Draft          PIM Protection using MRTs              July 2013


         P: PLR Replication capable.  This bit is set if a router is
         capable of acting as a PLR-replicating router, as described in
         this document.  This router must also be capable of receiving a
         Merge Point Join Attribute.

         T: MRT Topology Capable.  This bit is set if the router is
         capable of understanding MRT topology IDs sent in the MT-ID
         Join Attribute [RFC5384], as defined in this document.

         L: Link Protection Capable.  This bit is set if the router is
         capable of performing Link Protection, as defined in this
         document.  This router must also be capable of receiving a
         Merge Point Join Attribute.

         N: Node Protection.  This bit is set if the router is capable
         of performing Node Protection, as defined in this document.
         This router must also be capable of receiving a Merge Point
         Join Attribute.

5.2.  Join Attributes

5.2.1.  Merge Point Attribute

   The following Join attribute is used for local protection, when the
   Protected-Node needs to signal the Merge Point information to the
   PLR.  There will be a separate Merge Point Attribute for each Merge
   Point being advertised for the source.  This attribute should only be
   sent to routers that are Link or Node capable, as advertised in the
   MRT Protection Hello Option.


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|E| Type      | Length        |N|P|        Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Reserved          |              label                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               MP                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                        Merge Point Join Attribute

      F-bit: This bit will be clear as this is a non-transitive
      attribute.




Kebler, et al.          Expires January 13, 2014                [Page 9]


Internet-Draft          PIM Protection using MRTs              July 2013


      E-bit: As defined in [RFC5384]

      Type: TBD

      Length field: variable

      N bit - This Label is for a node-protecting MP.  The label and
      this Join attribute will need to be sent upstream (to the PLR) in
      the upstream Join message.  When sending this Join attribute
      upstream, this bit MUST be cleared.

      P bit - This bit indicates that the receiving router should act as
      a PLR.  This bit should only be set in Joins to routers that are
      PLR-Replication capable, as advertised in the MRT Protection Hello
      Option

      Reserved: Sent with zero, ignored on receipt

      label: the MPLS label associated with this MP

      MP: The encoded-Unicast addresses of the Merge Point

6.  IANA Considerations

   A new PIM Hello Option type is requested to assign to the MRT
   Protection Hello Option

   A new PIM Join Attribute Type is requested for the Merge Point Join
   Attribute

7.  Security Considerations

   There are no security considerations for this design other than what
   is already in the main PIM specification [RFC4601] .

8.  References

8.1.  Normative References

   [I-D.ietf-rtgwg-mofrr]
              Karan, A., Filsfils, C., Farinacci, D., Wijnands, I.,
              Decraene, B., Joorde, U., and W. Henderickx, "Multicast
              only Fast Re-Route", draft-ietf-rtgwg-mofrr-02 (work in
              progress), June 2013.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.



Kebler, et al.          Expires January 13, 2014               [Page 10]


Internet-Draft          PIM Protection using MRTs              July 2013


   [RFC5384]  Boers, A., Wijnands, I., and E. Rosen, "The Protocol
              Independent Multicast (PIM) Join Attribute Format", RFC
              5384, November 2008.

   [RFC6395]  Gulrajani, S. and S. Venaas, "An Interface Identifier (ID)
              Hello Option for PIM", RFC 6395, October 2011.

   [RFC6420]  Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
              Attribute", RFC 6420, November 2011.

8.2.  Informative References

   [I-D.atlas-rtwg-mrt-mc-arch]
              Atlas, A., Kebler, R., Wijnands, IJ., and G. Enyedi, "An
              Architecture for Multicast Protection Using Maximally
              Redundant Trees", atlas-rtwg-mrt-mc-arch-02 (work in
              progress), July 2013.

   [I-D.ietf-rtgwg-mrt-frr-architecture]
              Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura,
              J., Konstantynowicz, M., White, R., and M. Shand, "An
              Architecture for IP/LDP Fast-Reroute Using Maximally
              Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02
              (work in progress), February 2013.

Authors' Addresses

   Robert Kebler (editor)
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: rkebler@juniper.net


   Alia Atlas
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: akatlas@juniper.net








Kebler, et al.          Expires January 13, 2014               [Page 11]


Internet-Draft          PIM Protection using MRTs              July 2013


   Naiming Shen
   Cisco Systems, Inc.
   170 W. Tasman Drive
   San Jose, CA  95134
   USA

   Email: naiming@cisco.com


   Yiqun Cai
   Microsoft
   La Avenida
   Mountain View, CA  94043
   USA

   Email: yiqunc@microsoft.com



































Kebler, et al.          Expires January 13, 2014               [Page 12]