Versions: 00 01

PIM WG                                                   J. Asghar
Internet-Draft                                        IJ. Wijnands
Intended status: Informational                     S. Krishnaswamy
Expires: October 25, December 22, 2013                                A. Karan
                                                     Cisco Systems
                                                           V. Arya
                                                     Directv, Inc.

						    April 26,

                                                     June 21, 2013

                   Explicit RPF Vector
            draft-ietf-pim-explicit-rpf-vector-00
            draft-ietf-pim-explicit-rpf-vector-01

Abstract

   This document describes a use of the Reverse Path Forwarding (RPF)
   Vector TLV as defined in [RPC 5496] to build multicast trees via an
   explicitly configured
   explicit path sent in the PIM join.

Status of this Memo

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

   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/1id-abstracts.html

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

   This Internet-Draft will expire April 15, December 21, 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
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents carefully,
   as they describe your rights and restrictions with respect to this
   document.  Code Components extracted from this document must include
   Simplified BSD License text as described in Section 4.e of the Trust
   Legal Provisions and are provided without warranty as described in
   the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Specification of Requirements . . . . . . . . . . . . . . . . . 3
   3.  Soluton  Solution Requirements  . . . . . . . . . . . . . . . . . . . . .  3
   4.  Use of the Explicit RPF Vector  . . . . . . . . . . . . . . . . 4
   5.  Explicit RPF Vector Attribute . . . . . . . . . . . . . . . . . 4
   6.  Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . . 4
   7.  Explicit RPF Vector Attribute TLV Format  PIM Asserts  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   8.  IANA Considerations  Join Suppression. . . . . . . . . . . . . . . . . . . . . . . .5 . 5
   9.  Security Considerations  Vector Handling By Unsupported PIM Router . . . . . . . . . . . 5
   10. Explicit RPF Vector Attribute TLV Format  . . . . . . . . . . . 5
10.  Acknowledgments
   11.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 5
   12.  Security Considerations . . 6
11.  Normative References . . . . . . . . . . . . . . . . .  6
   13.  Acknowledgments  . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 6
   14.  Normative References   . . . . 7 . . . . . . . . . . . . . . . . 6

1.  Introduction

   In

   For some applications applications, it might be useful to have a way to specify
   the explicit path along which the PIM join is propagated.

   This document defines a new TLV in the PIM Join Attribute message
   [RFC5384] for specifying the explicit path.

   The procedures in [RFC5496] define how a RPF vector can be used
   to influence the path selection in the absence of a route to the
   Source. However, the same procedures can be used to override a
   route to the Source when it exists. It is possible to include
   multiple RPF vectors in the stack where each router along the
   path will perform a unicast route lookup on the first vector in
   the attribute list. Once the router owning the address of the RPF
   vector is reached, following the procedures in [RFC5496], the RPF
   vector will be removed from the attribute list. This will result
   in a 'loosely' routed path based on the unicast reachability of
   the RPF vector(s). We call this loosely 'loosely' because we still depend
   on unicast routing reachability to the RPF Vector.

   In some scenarios we don't want to rely on the unicast reachability
   to the RPF vector address and we want to build a path strictly
   based on the RPF vectors. In that case the RPF vector(s) represent
   a list of directly connected PIM neighbors along the path. For
   these vectors we MUST NOT do a unicast route lookup. We call
   these 'explicit' RPF vector addresses. If a router receiving an
   explicit RPF vector does not have a PIM neighbor matching the
   explicit RPF vector address it MUST NOT fall back to loosely
   routing the JOIN. Instead, it may process the packet and store
   the RPF Vector stack so that the explicit rpf vector join may be
   sent out as soon as the neighbor comes up. Since the behavior of
   the explicit RPF vector differs from the loose RPF vector as
   defined [RFC5496], we're defining a new attribute called the
   explicit RPF Vector.

2.  Specification of Requirements

   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 [RFC2119].

3.  Solution Requirements

   Some broadcast video transport networks use a multicast PIM
   live-live resiliency model for video delivery based on PIM SSM
   or PIM ASM. Live-Live implies using 2 active-active spatially
   diverse multicast trees to transport video flows from root to
   leaf multicast routers. The leaf multicast router receives 2
   copies from the PIM multicast core and will replicate 1 copy
   towards the receivers [draft-mofrr-karan].

   One of the main requirements of PIM live-live resiliency model
   is to ensure path-diversity of the active-active PIM trees in
   the core such that they do not intersect to avoid a single
   point of failure. IGP routed RPF paths of active-active PIM
   trees could be routed over the same transit router and create
   a single point of failure. It might be useful to have a way to
   specify the explicit path along which the PIM join is propagated.

   How the explicit RPF vector stack is determined is outside the
   scope of this document. It may either be manually configured by
   the network operator or procedures may be implemented on the
   egress router to dynamically calculate the vector stack based on
   a link state database protocol, like OSPF or ISIS.

   Due to the fact that the leaf router receives two copies of the
   multicast stream via two diverse paths, there is no need for PIM
   to repair the broken path immediately. It is up to the egress
   router to either wait for the broken path to be repaired or build
   a new explicit path using a new RPF vector stack. Which method is
   applied depends very much on how the vector stack was determined
   initially. Double failures are not considered and outside the
   scope of this document

   4.  Use of the PIM Explicit RPF Vector

   Figure 1 provides an example multicast join path R4->R3->R6->R5->R2->R1,
   where the multicast JOIN is explicitly routed to the source hop-by-hop
   using the explicit RPF vector list.

   [S]---(R1)--(R2)---(R3)--(R4)---[R]
          <---   |      |  ---
             |   |      |  |
             | (R5)---(R6) |
             - (S,G) Join -

                Figure 1

5.  Explicit RPF Vector Attribute

   This draft uses vector attribute 4 for specifying an explicit RPF
   vector.

6.  Conflicting RPF Vectors

   It is possible that a PIM router has multiple downstream neighbors.
   If for the same multicast route there is inconsistency between the
   Explicit RPF Vector stacks provided by the downstream PIM neighbor,
   the procedures as documented in RFC5384 section 3.3.3 apply.

7.  PIM Asserts

   RFC5496 section 3.3.3 describes the procedure how to deal with PIM
   asserts when RPF vectors are used. The same procedure applies to the
   Explicit RPF vector. There is minor behavioural difference, the routing
   protocol's Metric that is included in the PIM Assert should be taken
   from the first Explicit vector in the stack. However, the first Explicit
   vector should always be directly connected, so the Metric will be zero.
   The Metric will therefore not be a tie breaker in the PIM Assert
   selection procedure.

8.  Join Suppression

   RFC5496 section 3.3.4 describes the procedure how to apply join
   suppression when an RPF Vector attribute is included in the PIM join.
   The same procedure applies to the Explicit RPF Vector attribute. The
   procedure MUST match against all the Explicit RPF Vectors in the PIM
   join before a PIM join can be suppressed.

9.  Unsupported Explicit Vector Handling

   Routers that don't support the Explicit Vector MUST never forward the
   vector to their upstream PIM neighbor. Such router will not be able
   to remove the Explicit Vector from stack, causing a PIM control plane
   routing loop with the upstream PIM neighbor. For that reason the F bit
   MUST be set to 0. See RFC 5384 section 3.3.2.

10.  Explicit RPF Vector Attribute TLV Format

   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|S|
   |F|E| Type      | Length        |        Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......

   F bit
   -----
   The F bit MUST be set to 0. Otherwise there could be loops.

   S

   E bit
   -----
   Bottom
   End of Stack. Attributes. If this bit is set then this is the last
   TLV in the stack.

   Type
   ----
   The Vector Attribute type is 4.

   Length
   ------
   Length depending on Address Family of Encoded-Unicast address.

   Value
   -----
   Encoded-Unicast address. For IPv6, this should This could be a unique global
   address and NOT link-local.

8. valid primary or secondary
   address.

11.  IANA Considerations

   An new attribute type from the "PIM Join Attribute Types" registry
   needs to be assigned by IANA for the RPF Vector.  The proposed
   value is 4.

9.

12.  Security Considerations

   Security of the RPF Vector Attribute is only guaranteed by the
   security of the PIM packet, so the security considerations for PIM
   join packets as described in PIM-SM [RFC4601] apply here.

10.

13.  Acknowledgments

   The authors would like to thank Vatsa Kumar and Nagendra Kumar
   for the comments on the draft.

11.

14.  Normative References

   [RFC5496]  Wijnands, IJ., Boers, A., Rosen, E., "The Reverse Path
              Forwarding (RPF) Vector TLV", RFC 5496, March 2009.

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

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

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

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

Authors' Addresses

   Javed Asghar
   Cisco Systems, Inc.
   725, Alder Drive
   Milpitas, CA 95035

   Email: jasghar@cisco.com

   IJsbrand Wijnands
   Cisco Systems, Inc.
   De kleetlaan 6a
   Diegem  1831
   Belgium

   EMail: ice@cisco.com

   Sowmya Krishnaswamy
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, CA 95134

   EMail: sowkrish@cisco.com

   Apoorva Karan
   Cisco Systems, Inc.
   3750 Cisco Way
   San Jose, CA 95134

   EMail: apoorva@cisco.com

   Vishal Arya
   DIRECTV Inc.
   2230 E Imperial Hwy
   El Segundo, CA  90245

   Email: varya@directv.com