Network Working Group P. Pfister Internet-Draft Intended status: Standards Track October 27, 2014 Expires: April 30, 2015 Source Specific support for Bidirectional Protocol Independent Multicast draft-pfister-pim-ssbidir-00 Abstract This document adds Source-Specific capabilities to the Bidirectional Protocol Independent Multicast (PIM-BIDIR) routing protocol. Similarly to PIM-BIDIR, multicast traffic is always forwarded to the RP Link, but packets are also filtered based on their source address and source-specific subscription state. This operation mode is backwards compatible with PIM-BIDIR, provides a simpler alternative to PIM-SM and does not suffer when the multicast source location cannot be determined. 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 30, 2015. Copyright Notice Copyright (c) 2014 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 Pfister Expires April 30, 2015 [Page 1] Internet-Draft PIM Source-Specific BIDIR October 2014 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. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Specifications . . . . . . . . . . . . . . . . . . . 4 3.1. PIM-SSBIDIR Protocol State . . . . . . . . . . . . . . . 5 3.1.1. Per Neighbor State . . . . . . . . . . . . . . . . . 5 3.1.2. (*,G) State . . . . . . . . . . . . . . . . . . . . . 5 3.1.3. (S,G) State . . . . . . . . . . . . . . . . . . . . . 5 3.1.4. (S,G,rpt) State . . . . . . . . . . . . . . . . . . . 6 3.1.5. Designated Forwarder Election . . . . . . . . . . . . 7 3.1.6. State Summerization Macro . . . . . . . . . . . . . . 7 3.2. Forwarding Rules . . . . . . . . . . . . . . . . . . . . 9 3.3. PIM Join/Prune Messages . . . . . . . . . . . . . . . . . 9 3.3.1. Receiving (*,G) Join/Prune Messages . . . . . . . . . 9 3.3.2. Receiving (S,G) Join/Prune Messages . . . . . . . . . 9 3.3.3. Receiving (S,G,rpt) Join/Prune Messages . . . . . . . 10 3.3.4. Sending (*,G) Join/Prune Messages . . . . . . . . . . 11 3.3.5. Sending (S,G) Join/Prune Messages . . . . . . . . . . 12 3.3.6. Sending (S,G,rpt) Join/Prune in (*,G) messages . . . 12 3.3.7. Sending triggered (S,G,rpt) Join/Prune Messages . . . 13 3.4. SSBIDIR-PIM Packet Formats . . . . . . . . . . . . . . . 15 3.4.1. Encoded-Group Format . . . . . . . . . . . . . . . . 15 3.4.2. SSBIDIR Capable PIM-Hello Option . . . . . . . . . . 15 4. PIM-BIDIR Compatibility . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction The Protocol Independent Multicast (PIM - [RFC4601]) Sparse-Mode provides All-Source (ASM) and Source-Specific multicast (SSM) routing using an optimal source-specific routing path, but at the cost of two major drawbacks: 1. It relies on packet tunneling for All-Source Multicast (Pretty complex in terms of implementation). Pfister Expires April 30, 2015 [Page 2] Internet-Draft PIM Source-Specific BIDIR October 2014 2. It does not provide native multicast when some multicast source's location cannot be determined (e.g. when multiple default routes are in the RIB). PIM BIDIR was specified as an alternative to PIM-SM: Simpler in terms of implementation and execution, at the cost of dropping source- specific multicast support. It is particularly suited in situations where multiple multicast sources also subscribe to other sources' sent packets. This document specifies the Source-Specific Bidirectional Mode (PIM-SSBIDIR), which adds source-specificity support to PIM-BIDIR. Unlike PIM-SM, all the traffic, including the source specific traffic, is forwarded on the RP-tree. Therefore, PIM-SSBIDIR does not provide source-specific path optimization, but still filters traffic according to multicast packet's source address, and thus reduces undesired traffic forwarding. PIM-SSBIDIR, specified in this document, has two major advantages compared to PIM-SM. 1. Implementation and execution is simpler. * A single RP-rooted forwarding tree is used. * Assert state machine and messages are not used. * Register and Register-Stop messages are not used (No tunneling). 2. Packets are forwarded natively even when the source's location can't be determined. This extension was designed for multi-homed home networks ([I-D.ietf-homenet-arch] - a typical case in which source-location cannot be determined for ISP-origininated traffic because of the multiple default routes). PIM-SM using PIM RPF Vectors [RFC5496] could be another alternative, but it is not clear how routers should behave when they receive conflicting RPF vectors. The protocol simplicity was also an important consideration as home routers usually have little resources and software reliability is important. Inputs from PIM and Homenet working group regarding other possible solutions are very welcome. 2. Protocol Overview PIM-BIDIR specifies how a single RP-rooted tree can be maintained and used for forwarding multicast traffic to group subscribers. In the original document, only the (*,G) state machine was defined. This Pfister Expires April 30, 2015 [Page 3] Internet-Draft PIM Source-Specific BIDIR October 2014 document specifies (S,G) and (S,G,rpt) state machines when operating in BIDIR mode. Similarly to PIM-SM, (S,G) Join/Prune messages allow subscribing to multicast traffic originated by a given source for a given group while (S,G,rpt) Join/Prune messages provide support for source- specific pruning. But unlike PIM-SM, SSBIDIR Join/Prune messages are always sent to the Designated Forwarder, and downstream multicast packets are always forwarded from the RP link to the subscribed hosts. Consequently, one major difference with PIM-SM is that (*,G) and (S,G,rpt) upstream states do not operate concurrently. A router's either operates in "include" mode using (S,G) states, or in "exclude" mode using (*,G) and (S,G,rpt) states. Depending on the RP and sources locations, PIM-SSBIDIR does not always provide optimal routing of source-specific traffic. PIM-SM or PIM-SSM should be used in situations where source-specific path optimization is required. PIM-SSBIDIR can operate with PIM-BIDIR neighbors. Neighbor's capabilities are determined using the new Source-Specific Bidirectional Capable PIM Hello option which is included in all Hello messages sent by SSBIDIR routers. When at least one neighbor, on a given link, does not support PIM-SSBIDIR, (S,G,rpt) states are not used, but (S,G) state can be. Additionaly, when the Designated Forwarder does not support PIM-SSBIDIR, (S,G) downstream states are converted into (*,G) subscriptions. In any case, requested multicast traffic is always forwarded to the subscribed hosts. Although BIDIR- only router presence may increase undesired traffic overhead. 3. Protocol Specifications The specification of PIM-SSBIDIR is broken into several parts: o Section 3.1 details the protocol state. o Section 3.1.5 recalls that the Designated Forwarder election must take place. o Section 3.2 specifies the multicast data forwarding rules. o Section 3.3 specifies the PIM-SSBIDIR Join/Prune generation and processing rules. Pfister Expires April 30, 2015 [Page 4] Internet-Draft PIM Source-Specific BIDIR October 2014 3.1. PIM-SSBIDIR Protocol State This section describes the state that must be kept by routers operating in PIM-SSBIDIR mode, in addition to the state specified in PIM-BIDIR specifications. 3.1.1. Per Neighbor State Routers MUST keep track of neighbor's SSBIDIR and BIDIR capabilities as specified in PIM Hello BIDIR and SSBIDIR capable options (Section 3.4.2). This state is used by "ssbidir_neighbor(N)" macro defined in section Section 3.1.6. 3.1.2. (*,G) State The (*,G) state is similar to the (*,G) state described in PIM- BIDIR's specifications. 3.1.3. (S,G) State For every source S and group G operating in SSBIDIR mode, routers keep the following state: (S,G) state: For each interface: Local Membership: - State: One of {"NoInfo", "Include"} PIM (S,G) Join/Prune: - State: One of {"NoInfo", "Join", "Prune-Pending"} - Prune-Pending Timer - Join/Prune Expiry Timer Not interface specific: Upstream (S,G) Join/Prune State: - State: One of {"NotJoined", "Joined"} - Upstream (S,G) Join/Prune Timer Pfister Expires April 30, 2015 [Page 5] Internet-Draft PIM Source-Specific BIDIR October 2014 Local membership is the result of the local membership mechanism (such as MLD [RFC3810] or IGMP [RFC3376]) running on that interface. This information is used by pim_include(S,G) macro described in Section 3.1.6. PIM (S,G) Join/Prune state is the result of receiving PIM (S,G) Join/ Prune messages on this interface, and is specified in Section 3.3.2. The upstream (S,G) Join/Prune State reflects the state of the upstream (S,G) state machine and the upstream (S,G) Join/Prune Timer is used to send periodic (S,G) Joins and override Prune(S,G) messages from peers on an upstream interface. Details are specified in Section 3.3.5. 3.1.4. (S,G,rpt) State For every group G and source S operating in SSBIDIR mode, routers keep the following state: (S,G,rpt) state: For each interface: Local Membership: - State: One of {"NoInfo", "Exclude"} PIM (S,G,rpt) Join/Prune: - State: One of {"NoInfo", "Prune", "Prune-Pending", "PruneTmp", "Prune-Pending-Tmp"} - Prune-Pending Timer - Join/Prune Expiry Timer Not interface specific: Upstream (S,G,rpt) Join/Prune State: - State: One of {"NotPruned", "Pruned"} - Upstream (S,G) Override Timer Local membership is the result of the local membership mechanism (such as MLD or IGMP) running on that interface. This information is used by pim_include(S,G) macro described in Section 3.1.6. Pfister Expires April 30, 2015 [Page 6] Internet-Draft PIM Source-Specific BIDIR October 2014 PIM (S,G,rpt) Join/Prune state is the result of receiving PIM (S,G,rpt) Join/Prune messages on this interface, and is specified in Section 3.3.3. The upstream (S,G,rpt) Join/Prune State reflects the state of the upstream (S,G,rpt) state machine and the upstream (S,G,rpt) Join/ Prune Timer is used to send periodic (S,G,rpt) Prunes and override Prune(S,G,rpt) messages from peers on the upstream interface. The upstream state machine's behavior is specified in Section 3.3.7. 3.1.5. Designated Forwarder Election PIM-SSBIDIR routers MUST comply to the Designated Forwarder (DF) election process, as defined in PIM-BIDIR specifications. 3.1.6. State Summerization Macro This section describes the macros used by PIM-SSBIDIR state machines. RPA(G), RPF_interface(rpa) and RPF_neighbor(rpa) are related to the Designated Forwarder election. They are defined in PIM-BIDIR's specifications. The following pseudo code describes the set of interfaces requesting (S,G) traffic. olist(S,G) = RPF_interface(RPA(G)) (+) joins(S,G) (+) (joins(*,G) (-) prunes(S,G,rpt)) (+) pim_include(S,G) (+) (pim_include(*,G) - pim_exclude(S,G)) The set "joins(*,G)" is the set of interfaces on which the router has received (*,G) Joins: joins(*,G) = { all interfaces I such that I_am_DF(RPA(G),I) AND DownstreamJPState(*,G,I) is either Join or Prune-Pending } The set "joins(S,G)" is the set of interfaces on which the router has received (S,G) Joins: joins(S,G) = { all interfaces I such that I_am_DF(RPA(G),I) AND DownstreamJPState(S,G,I) is either Join or Prune-Pending } Pfister Expires April 30, 2015 [Page 7] Internet-Draft PIM Source-Specific BIDIR October 2014 The set "prunes(S,G,rpt)" is the set of interfaces on which the router has received (S,G,rpt) prunes: prunes(S,G,rpt) = { all interfaces I such that I_am_DF(RPA(G),I) AND DownstreamJPState(S,G,rpt,I) is either Prune or PruneTmp } The sets "pim_include(S,G)" and "pim_include(*,G)" indicate interfaces to which multicast traffic might be forwarded because of hosts that are local members on that interface. The set "pim_exclude(S,G)" is the set of interfaces where local members required to not receive traffic from source S: pim_include(*,G) = { all interfaces I such that I_am_DF(RPA(G),I) AND local_receiver_include(*,G,I) } pim_include(S,G) = { all interfaces I such that I_am_DF(RPA(G),I) AND local_receiver_include(S,G,I) } pim_exclude(S,G) = { all interfaces I such that I_am_DF(RPA(G),I) AND local_receiver_exclude(S,G,I) } Clauses "local_receiver_include(*,G,I)", "local_receiver_include(S,G,I)" and "local_receiver_exclude(S,G,I)" reflect local membership subscriptions, as defined in PIM-SM specifications. In order to operate with BIDIR routers, SSBIDIR routers keep track of neighbors' capabilities. The clause "ssbidir_neighbor(N)" is TRUE if the last received Hello from neighbor N contained a Source-Specific Bidirectional Capable Hello Option. It is FALSE otherwise. In addition, the "ssbidir_link(I)" is TRUE if "ssbidir_neighbor(N)" is TRUE for any neighbor reachable through the interface I. It is FALSE otherwise. These clauses are used in JoinDesired(G), JoinDesired(S,G) and PruneDesired(S,G,rpt) macro specified in Section 3.3. Pfister Expires April 30, 2015 [Page 8] Internet-Draft PIM Source-Specific BIDIR October 2014 3.2. Forwarding Rules Similarly to PIM-BIDIR, forwarding takes place on the RP-tree, defined as the set of uplink interfaces RPF_interface(RPA(G)) and interfaces where the router is elected Designated Forwarder. The process of accepting a packet for forwarding, before building the outgoing interface list, is similar to PIM-BIDIR's as well. In PIM-SSBIDIR, both group and source addresses are used in order to build the outgoing interface list, based on router's source-specific state. This differs from PIM-BIDIR, where only the group address is used. A packet received on an interface for which we are the Designated Forwarder is always relayed upstream. A packet received on the upstream interface, or on an interface on which we are the DF, is forwarded on all interfaces that requested the corresponding multicast traffic (Except the input interface). In summary, on receipt of data from S to G on interface iif: if( iif == RPA_interface(RPA(G)) || I_am_DF(RPA(G), iif) ) { oiflist = olist(S,G) (-) iif forward packet on all interfaces in oiflist } 3.3. PIM Join/Prune Messages PIM SSBIDIR adds source-specific states and messaging to the existing PIM-BIDIR specifications. Therefore, this document only specifies (S,G) and (S,G,rpt) state machines and do not modify the existing BIDIR (*,G) state machine. 3.3.1. Receiving (*,G) Join/Prune Messages The per-interface (*,G) state machine is similar to the state machine described in PIM-BIDIR. 3.3.2. Receiving (S,G) Join/Prune Messages When a router receives a Join(S,G) or Prune(S,G) for which SSBIDIR is enabled, it MUST first check if the group's [B]idir flag is set. If not, the packet MUST be discarded. The per-interface state machine for receiving (S,G) Join/Prune has three states. Pfister Expires April 30, 2015 [Page 9] Internet-Draft PIM Source-Specific BIDIR October 2014 NoInfo (NI) The interface has no (S,G) Join state and no timers running. Join (J) One of the routers reachable on interface I has requested receiving source-specific traffic sent by S to G. If the router is the DF on this interface (I_am_DF(RPA(G),I) is TRUE), the Join state will cause us to forward packets sent by S to G on this interface. PrunePending (PP) The router has received a a Prune(S,G) message and is waiting for the PrunePending timer to timeout before moving to the NoInfo state. During that lapse of time, forwarding takes place exactly like in the Join state and on-link routers can override the Prune(S,G) by sending a Join(S,G) message. (S,G) per-interface state machine events, transitions and timer values are similar to PIM-BIDIR's (*,G) (By replacing (*,G) by (S,G)). Details can be found in Section 3.4.1 [1] from [RFC5015]. 3.3.3. Receiving (S,G,rpt) Join/Prune Messages When a router receives a Join(S,G,rpt) or a Prune(S,G,rpt) for which SSBIDIR is enabled, it MUST first check if the group's [B]idir flag is set. If not, the packet MUST be discarded. When a message is parsed for a given group G, (*,G) Joins must be processed before processing any (S,G,rpt) Prunes. Transient state "PruneTmp" and "Prune-Pending-Tmp" are used during the parsing process. The per-interface state machine for receiving (S,G,rpt) Join/Prune messages has four states. NoInfo (NI) The interface has no (S,G,rpt) Prune state and no timers running. Prune (P) The per-interface (*,G) state is set to Join and we received a Prune(S,G,rpt) message. It means that all interface's neighbors that are interested in (*,G) do not want to receive packets sent by source S. If the router is the DF on this interface (I_am_DF(RPA(G),I) is TRUE), the Prune state will cause us to *not* forward packets sent by S to G on this interface. PrunePending (PP) Pfister Expires April 30, 2015 [Page 10] Internet-Draft PIM Source-Specific BIDIR October 2014 The router has received a Prune(S,G,rpt) message and is waiting for the PrunePending timer to timeout before moving to the Prune state. During that lapse of time, forwarding takes place exactly like the NoInfo state and neighboring routers can override the Prune(S,G,rpt) by sending a Join(S,G,rpt) message. PruneTmp (P') This state is a transient state that is used as we parse a Join/Prune message that contains a (*,G) Join. A (S,G,rpt) Prune present in the same message will reinstate the Prune state. However, if we reach the end of the message without encountering such a (S,G,rpt) Prune, we will revert to NoInfo state in this state machine. For forwarding purposes, PruneTmp behaves exactly like Prune. Prune-Pending-Tmp (PP') This state is a transient state that is identical to P' except that it is associated with the PP state rather than the P state. For forwarding purposes, PP' behaves exactly like PP state. (S,G,rpt) per-interface state machine events, transitions and timer values are similar to PIM-SM (S,G,rpt) per-interface state. Details can be found in Section 4.5.4 [2] from [RFC4601]. In addition, the state machine needs to react to the "Stop Being DF on I" event. When this event occurs, all (S,G,rpt) states associated with I are moved to "NoInfo" and PrunePending and Expiry timers are stopped (if running). 3.3.4. Sending (*,G) Join/Prune Messages The Upstream (*,G) state machine is similar to the state machine described in PIM-BIDIR's specifications. For BIDIR compatibility support, the JoinDesired(G) macro must be modified as follows: bool JoinDesired(G) { out = joins(*,G) (+) pim_include(*,G) if(!ssbidir_neighbor(RPF_neighbor(RPA(G)))) { out = out (+) {olist(S,G) for any source S} } return (out (-) RPF_interface(RPA(G))) != {} } In case the upstream neighbor is not SSBIDIR capable, downstream (S,G) Joins are translated into upstream (*,G) Joins. Pfister Expires April 30, 2015 [Page 11] Internet-Draft PIM Source-Specific BIDIR October 2014 3.3.5. Sending (S,G) Join/Prune Messages The upstream (S,G) state machine holds join state from downstream routers and local membership information. It controls (S,G) Join/ Prune message emission. This state machine has two possible states. Not Joined The downstream state machines and local membership information do not indicate that the router needs to send (S,G) Joins or override other routers' (S,G) prunes. Joined The downstream state machines and local membership information indicate that the router needs to send (S,G) Joins and override other routers' (S,G) prunes. In addition, one timer JT(S,G) is kept that is used to trigger the sending of a Join(S,G) to the upstream Designated Forwarder RPF_neighbor(RPA(G)). The detailed state machine is derived from PIM-BIDIR (*,G) upstream state machine by replacing (*,G) references with (S,G). The JoinDesired(S,G) macro is defined as follows: bool JoinDesired(S,G) { if(!ssbidir_neighbor(RPF_neighbor(RPA(G))) OR JoinDesired(G)) return FALSE return (olist(S,G) (-) RPF_interface(RPA(G))) != {} } In case the upstream neighbor is not SSBIDIR capable, downstream (S,G) Joins are translated into upstream (*,G) Joins. 3.3.6. Sending (S,G,rpt) Join/Prune in (*,G) messages Whenever a Join(*,G) message is sent in response to a Prune(*,G), it must include a Prune(S,G,rpt) for every (S,G,rpt) upstream state that is set to Pruned. When sending a periodic Join(*,G), it must include a Prune(S,G,rpt) for every (S,G,rpt) state set to Pruned which Override Timer is not running. Pfister Expires April 30, 2015 [Page 12] Internet-Draft PIM Source-Specific BIDIR October 2014 Note that if the message construction is made after processing the Join(*,G) event in the upstream (S,G,rpt) state machine, the first paragraph can be ignored and the second paragraph applied in all cases. That is because the Join(*,G) reception event cancels all (S,G,rpt) Override Timers. 3.3.7. Sending triggered (S,G,rpt) Join/Prune Messages The upstream (S,G,rpt) state machine holds join state from downstream routers and local membership information. It controls (S,G,rpt) Join /Prune message emission. It is only used when upstream (*,G) state is Joined. The upstream (S,G,rpt) state machine has two states: NotPruned The upstream (*,G) state is "Joined" but downstream routers and local membership indicates that at least one downstream interface should receive traffic sent from S to G. Pruned The upstream (*,G) state is "Joined" but not a single downstream interface requested traffic sent from S to G. ASNotJoined(G) The All-Sources (*,G) state is NotJoined. This state is kept because the (*,G) state machine takes care of sending (S,G,rpt) Prunes when JoinDesired(G) changes to true. Similarly, when JoinDesired(G) changes to false, all (S,G,rpt) states are moved back to ASNotJoined. In addition, there is an (S,G,rpt) Override Timer, OT(S,G,rpt). In the NotPruned state, it is used to delay triggered Join(S,G,rpt) messages to prevent explosion of triggered messages. In the Pruned state, it is used to delay Prune(S,G,rpt) message origination whenever we received a Join(S,G,rpt) on that interface. This timer can be either cancelled, decreased to t_override or increased to t_suppressed (see PIM-BIDIR specifications for t_override and t_suppressed values). The following tables show (S,G,rpt) upstream state machine transitions and events. Pfister Expires April 30, 2015 [Page 13] Internet-Draft PIM Source-Specific BIDIR October 2014 +----------------+--------------------------------------------------+ | | State | | Event +----------------------+---------------------------+ | | ASNotJoined(NJ) | NotPruned(NP) & Pruned(P) | +----------------+----------------------+---------------------------+ | JoinDesired(G) | If PD(S,G,rpt) -> P | _ | | -> true | Else -> NP | | +----------------+----------------------+---------------------------+ | JoinDesired(G) | _ | -> NP | | -> false | | | +----------------+----------------------+---------------------------+ | Other events | Do nothing | +----------------+----------------------+ +-----------------------+-------------------------------------------+ | | State | | Event +---------------------+---------------------+ | | NotPruned(NP) | Pruned(P) | +-----------------------+---------------------+---------------------+ | PruneDesired(S,G,rpt) | -> P; Cancel OT; | _ | | -> true | Send Prune(S,G,rpt) | | +-----------------------+---------------------+---------------------+ | PruneDesired(S,G,rpt) | _ | -> NP; Cancel OT; | | -> false | | Send Join(S,G,rpt) | +-----------------------+---------------------+---------------------+ | See Prune(S,G,rpt) | Decrease OT to | Cancel OT | | to RPF_DF(RPA(G)) | t_override | | +-----------------------+---------------------+---------------------+ | See Join(S,G,rpt) | Cancel OT | Increase OT to | | to RPF_DF(RPA(G)) | | t_suppress | +-----------------------+---------------------+---------------------+ | See Prune(*,G) | Do nothing | Cancel OT | | to RPF_DF(RPA(G)) | | | +-----------------------+---------------------+---------------------+ | DF Changes | Cancel OT | Send Join/Prune to | | | | old/new DF | +-----------------------+---------------------+---------------------+ | DF GenId changes | Do nothing | Decrease OT to | | | | t_override | +-----------------------+---------------------+---------------------+ | Override Timer | Send Join(S,G,rpt) | Send Prune(S,G,rpt) | | timeouts | | | +-----------------------+---------------------+---------------------+ Upstream (S,G,rpt) state machine. Pfister Expires April 30, 2015 [Page 14] Internet-Draft PIM Source-Specific BIDIR October 2014 The (S,G,rpt) upstream state machine uses the following macro: bool PruneDesired(S,G,rpt) { if(!ssbidir_link(RPF_interface(RPA(g)))) return FALSE return (olist(S,G) (-) RPF_interface(RPA(G))) == {} } The PruneDesired(S,G,rpt) macro can return true even if JoinDesired(G) is false (And thus does not always means that Prune(S,G,rpt) should be sent upstream). That is to differentiate PruneDesired(S,G,rpt) transitions that are due to JoinDesired(G) transition and those which aren't. 3.4. SSBIDIR-PIM Packet Formats This section describes the details of the packet formats for PIM- SSBIDIR control messages. 3.4.1. Encoded-Group Format For all groups G operating in SSBIDIR mode, the [B]idirectional bit must be set in the Group-Encoded format included in Join/Prune messages. 3.4.2. SSBIDIR Capable PIM-Hello Option SSBIDIR-PIM introduces one new PIM-Hello option. o OptionType TBD_BY_IANA: Source-Specific Bidirectional Capable. 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_BY_IANA | Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option MUST be included in all PIM Hello messages sent by SSBIDIR capable routers. SSBIDIR capable routers MUST as well include the Bidirection PIM- BIDIR Hello Option in sent Hello messages. Pfister Expires April 30, 2015 [Page 15] Internet-Draft PIM Source-Specific BIDIR October 2014 4. PIM-BIDIR Compatibility Compatibility problems between SSBIDIR and BIDIR routers occur when a BIDIR router joins (*,G) while an SSBIDIR router is pruning (S,G,rpt) on the same link: The BIDIR router will not suppress (S,G,rpt) Prunes, which will prevent it from receiving traffic from source S. Similarly, if the Designated Forwarder is not SSBIDIR capable, it will reject (S,G) and (S,G,rpt) messages. PIM-SSBIDIR interoperates with PIM-BIDIR by detecting BIDIR-only neighbors and suppressing undesired behaviors. When at least one neighbor, on a given link, is BIDIR-only, (S,G,rpt) messages are not used anymore (all traffic to G will be requested). When the upstream router is BIDIR-only, both (S,G,rpt) and (S,G) messages are not used anymore and only All-Source Multicast is supported. PIM-BIDIR compatibility SHOULD be supported. If an implementer chooses not to implement the compatibility support, its implementation MUST behave as if all neighbors were SSBIDIR capable. Additionaly, an error MUST be logged in a rate-limited manner if a Hello message that does not include the SSBIDIR Capable Option is received. PIM-BIDIR capable routers send (*,G) Join/Prune messages with the [B]idir bit set, but do not deal with (S,G) or (S,G,rpt) Join/Prune messages. The expected behavior from BIDIR capable routers in such situations is not specified. In order to support (S,G) subscriptions while operating in compatibility mode, we expect BIDIR implementations to silently ignore source-specific Join/Prunes. 5. Security Considerations Similarly to PIM-SM, introducing Source-Specific support to PIM BIDIR makes it vulnerable to easy deny of service attacks by generating lots of (S,G) Join or (S,G,rpt) Prune states for different sources. In order to operate securely, PIM messages SHOULD be authenticated and local subscriptions should be limited in rate and number (On a per-host basis if the link-layer provides authentication, on a per- link basis otherwise). 6. IANA Considerations IANA is kindly asked to assign a new PIM-Hello Option Type to be used for Source-Specific Bidirectional BIDIR-PIM Hello options. Pfister Expires April 30, 2015 [Page 16] Internet-Draft PIM Source-Specific BIDIR October 2014 7. References 7.1. Normative References [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR- PIM)", RFC 5015, October 2007. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. 7.2. Informative References [I-D.ietf-homenet-arch] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", draft- ietf-homenet-arch-11 (work in progress), October 2013. [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009. 7.3. URIs [1] http://tools.ietf.org/html/rfc5015#section-3.4.1 [2] http://tools.ietf.org/html/rfc4601#section-4.5.4 Appendix A. Acknowledgments The author would like to thank Steven Barth, Mohammed Hawari, Mark Townsley, Stig Venaas and IJsbrand Wijnands for their useful comments. Author's Address Pierre Pfister Paris France Email: pierre@darou.fr Pfister Expires April 30, 2015 [Page 17]