Versions: 02 PIM WG J. Asghar Internet-Draft IJ. Wijnands Intended status: Informational S. Krishnaswamy Expires: January 1, 2013 A. Karan Cisco Systems V. Arya Directv, Inc. July 12, 2013 Explicit RPF Vector draft-ietf-pim-explicit-rpf-vector-02 Abstract This document defines a new Reverse Path Forwarding (RPF) Vector TLV to build multicast trees via an explicit path sent in the PIM join. 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 12, 2013. 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 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. Solution Requirements . . . . . . . . . . . . . . . . . . . . 3 4. Use of the Explicit RPF Vector . . . . . . . . . . . . . . . . 4 5. Explicit RPF Vector Attribute . . . . . . . . . . . . . . . . . 4 6. Mixed Vector Processing . . . . . . . . . . . . . . . . . . . . 4 7. Conflicting RPF Vectors . . . . . . . . . . . . . . . . . . . . 4 8. PIM Asserts . . . . . . . . . . . . . . . . . . . . . . . . . 4 9. Join Suppression. . . . . . . . . . . . . . . . . . . . . . . . 5 10. Vector Handling By Unsupported PIM Router . . . . . . . . . . 5 11. Explicit RPF Vector Attribute TLV Format . . . . . . . . . . 5 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 13. Security Considerations . . . . . . . . . . . . . . . . . . . 6 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 15. Normative References . . . . . . . . . . . . . . . . . . . . 6 1. Introduction For 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 list 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 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 vectors 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 list 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 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 requirements of the PIM Live-Live resiliency model is to ensure path-diversity of the 2 active PIM trees in the core such that they do not intersect to avoid a single point of failure. IGP routed RPF paths of 2 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 list 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 list based on a link state database protocol, like OSPF or IS-IS. 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 list. Which method is applied depends very much on how the vector list was determined initially. Double failures are not considered and are 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 PIM join attribute type 4 for specifying an Explicit RPF Vector. 6. Mixed Vector Processing Explicit RPF Vector attribute does not impact or restrict the functionality of other RPF vector attributes in a PIM join. It is possible to mix vectors of different types, such that some part of the tree is explicit and other parts are loosely routed. RPF vectors are processed in the order in which they are specified. That is, the first RPF vector attribute is looked at and processed, it can be either loose or explicit. 7. Conflicting RPF Vectors It is possible that a PIM router has multiple downstream neighbors. If for the same multicast route there is an inconsistency between the Explicit RPF Vector lists provided by the downstream PIM neighbor, the procedures as documented in section 3.3.3 [RFC5384] apply. 8. PIM Asserts Section 3.3.3 of [RFC5496] specifies the procedures for how to deal with PIM asserts when RPF vectors are used. The same procedures apply to the Explicit RPF Vector. There is minor behavioral difference, the routing protocol's Metric that is included in the PIM Assert should be taken from the first Explicit vector in the list. However, the first Explicit vector should always be directly connected, so the Metric may likely be zero. The Metric will therefore not be a tie breaker in the PIM Assert selection procedure. 9. Join Suppression Section 3.3.4 of [RFC5496] specifies the procedures 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. 10. Unsupported Explicit Vector Handling Routers that don't support the Explicit Vector attribute MUST NOT forward the vector to their upstream PIM neighbor and if required send a PIM join with these attributes removed. Such router will not be able to remove the Explicit Vector attribute from the list, causing a PIM control plane routing loop with the upstream PIM neighbor. For that reason the F bit MUST be set to 0. See section 3.3.2 of [RFC5384]. 11. 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|E| Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-....... F bit ----- The F bit MUST be set to 0. Otherwise there could be loops. E bit ----- End of Attributes. If this bit is set then this is the last TLV specified in the list. Type ---- The Vector Attribute type is 4. Length ------ Length depending on the Address Family of the Encoded-Unicast address. Value ----- Encoded-Unicast address. This could be a valid primary or secondary address. 12. IANA Considerations A new attribute type from the "PIM Join Attribute Types" registry needs to be assigned by IANA for the RPF Vector attribute. The proposed value is 4. 13. Security Considerations This document describes Explicit RPF Vector Attribute only which by itself does not modify the security of PIM join packet or PIM-SM operation and shares the security considerations described in [RFC4601]. 14. Acknowledgments The authors would like to thank Vatsa Kumar and Nagendra Kumar for the comments on the document. 15. 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. 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