Versions: 00 PIM WG J. Asghar Internet-Draft IJ. Wijnands Intended status: Informational S. Krishnaswamy Expires: April 15, 2013 Cisco Systems, Inc. V. Arya Directv, Inc. October 15, 2012 Explicit RPF Vector draft-asghar-pim-explicit-rpf-vector-00 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 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, 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. Use of the Explicit RPF Vector . . . . . . . . . . . . . . . . 3 4. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . . 4 5. Interoperability . . . . . . . . . . . . . . . . . . . . . . .4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .4 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction In some 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 because we still depend on unicast routing reachability to the RPF Vector. In some scenario's 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. 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. Use of the PIM Explicit RPF Vector Normally PIM builds a receiver driven multicast forwarding tree by sending PIM Joins from the leaf router towards root based on unicast route lookup to source. Figure 1 provides an example multicast join path R4->R3->R2->R1, where the forwarding states are installed hop-by-hop dynamically. <--- (S,G) Join --- [S]---(R1)--(R2)---(R3)--(R4)---[R] | | | | (R5)---(R6) Figure 1 Figure 2 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 2 4. Explicit RPF Vector Attribute This draft uses vector attribute 1 for specifying an explicit rpf vector. 5. 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| Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... F bit ----- Forward Unknown TLV. If this bit is set the TLV is forwarded regardless of whether the router understands the Type. If the TLV is known the F bit is ignored. S bit ----- Bottom of Stack. If this bit is set then this is the last TLV in the stack. Type ---- The Vector Attribute type is 1. Length ------ Length depending on Address Family of Encoded-Unicast address. Value ----- Encoded-Unicast address. 6. Interoperability The behaviour is dictated by the F flag as specified in RFC 5496. 7. 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 1. 8. 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. 9. Acknowledgments The authors would like to thank Vatsa Kumar for the comments on the draft. 10. 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 Vishal Arya DIRECTV Inc. 2230 E Imperial Hwy El Segundo, CA 90245 Email: varya@directv.com Html markup produced by rfcmarkup 1.98, available from http://tools.ietf.org/tools/rfcmarkup/