summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5015.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5015.txt')
-rw-r--r--doc/rfc/rfc5015.txt2411
1 files changed, 2411 insertions, 0 deletions
diff --git a/doc/rfc/rfc5015.txt b/doc/rfc/rfc5015.txt
new file mode 100644
index 0000000..b148f60
--- /dev/null
+++ b/doc/rfc/rfc5015.txt
@@ -0,0 +1,2411 @@
+
+
+
+
+
+
+Network Working Group M. Handley
+Request for Comments: 5015 UCL
+Category: Standards Track I. Kouvelas
+ T. Speakman
+ Cisco
+ L. Vicisano
+ Digital Fountain
+ October 2007
+
+
+ Bidirectional Protocol Independent Multicast (BIDIR-PIM)
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document discusses Bidirectional PIM (BIDIR-PIM), a variant of
+ PIM Sparse-Mode that builds bidirectional shared trees connecting
+ multicast sources and receivers. Bidirectional trees are built using
+ a fail-safe Designated Forwarder (DF) election mechanism operating on
+ each link of a multicast topology. With the assistance of the DF,
+ multicast data is natively forwarded from sources to the Rendezvous-
+ Point (RP) and hence along the shared tree to receivers without
+ requiring source-specific state. The DF election takes place at RP
+ discovery time and provides the route to the RP, thus eliminating the
+ requirement for data-driven protocol events.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 1]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................4
+ 2.1. Definitions ................................................4
+ 2.2. Pseudocode Notation ........................................6
+ 3. Protocol Specification ..........................................6
+ 3.1. BIDIR-PIM Protocol State ...................................7
+ 3.1.1. General Purpose State ...............................8
+ 3.1.2. RPA State ...........................................8
+ 3.1.3. Group State .........................................9
+ 3.1.4. State Summarization Macros .........................10
+ 3.2. PIM Neighbor Discovery ....................................11
+ 3.3. Data Packet Forwarding Rules ..............................11
+ 3.3.1. Upstream Forwarding at RP ..........................12
+ 3.3.2. Source-Only Branches ...............................12
+ 3.3.3. Directly Connected Sources .........................13
+ 3.4. PIM Join/Prune Messages ...................................13
+ 3.4.1. Receiving (*,G) Join/Prune Messages ................13
+ 3.4.2. Sending Join/Prune Messages ........................16
+ 3.5. Designated Forwarder (DF) Election ........................18
+ 3.5.1. DF Requirements ....................................18
+ 3.5.2. DF Election Description ............................19
+ 3.5.2.1. Bootstrap Election ........................20
+ 3.5.2.2. Loser Metric Changes ......................20
+ 3.5.2.3. Winner Metric Changes .....................21
+ 3.5.2.4. Winner Loses Path .........................22
+ 3.5.2.5. Late Router Starting Up ...................22
+ 3.5.2.6. Winner Dies ...............................22
+ 3.5.3. Election Protocol Specification ....................22
+ 3.5.3.1. Election State ............................22
+ 3.5.3.2. Election Messages .........................23
+ 3.5.3.3. Election Events ...........................24
+ 3.5.3.4. Election Actions ..........................25
+ 3.5.3.5. Election State Transitions ................26
+ 3.5.4. Election Reliability Enhancements ..................30
+ 3.5.5. Missing Pass .......................................30
+ 3.5.6. Periodic Winner Announcement .......................30
+ 3.6. Timers, Counters, and Constants ...........................31
+ 3.7. BIDIR-PIM Packet Formats ..................................34
+ 3.7.1. DF Election Packet Formats .........................34
+ 3.7.2. Backoff Message ....................................36
+ 3.7.3. Pass Message .......................................36
+ 3.7.4. Bidirectional Capable PIM-Hello Option .............37
+ 4. RP Discovery ...................................................37
+ 5. Security Considerations ........................................38
+ 5.1. Attacks Based on Forged Messages ..........................38
+ 5.1.1. Election of an Incorrect DF ........................38
+
+
+
+Handley, et al. Standards Track [Page 2]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ 5.1.2. Preventing Election Convergence ....................39
+ 5.2. Non-Cryptographic Authentication Mechanisms ...............39
+ 5.2.1. Basic Access Control ...............................39
+ 5.3. Authentication Using IPsec ................................40
+ 5.4. Denial-of-Service Attacks .................................40
+ 6. IANA Considerations ............................................40
+ 7. Acknowledgments ................................................40
+ 8. Normative References ...........................................40
+ 9. Informative References .........................................41
+List of Figures
+ Figure 1. Downstream group per-interface state machine ............15
+ Figure 2. Upstream group state machine ............................17
+ Figure 3. Designated Forwarder election state machine .............27
+
+1. Introduction
+
+ This document specifies Bidirectional PIM (BIDIR-PIM), a variant of
+ PIM Sparse-Mode (PIM-SM) [4] that builds bidirectional shared trees
+ connecting multicast sources and receivers.
+
+ PIM-SM constructs unidirectional shared trees that are used to
+ forward data from senders to receivers of a multicast group. PIM-SM
+ also allows the construction of source-specific trees, but this
+ capability is not related to the protocol described in this document.
+
+ The shared tree for each multicast group is rooted at a multicast
+ router called the Rendezvous Point (RP). Different multicast groups
+ can use separate RPs within a PIM domain.
+
+ In unidirectional PIM-SM, there are two possible methods for
+ distributing data packets on the shared tree. These differ in the
+ way packets are forwarded from a source to the RP:
+
+ o Initially, when a source starts transmitting, its first hop router
+ encapsulates data packets in special control messages (Registers)
+ that are unicast to the RP. After reaching the RP, the packets are
+ decapsulated and distributed on the shared tree.
+
+ o A transition from the above distribution mode can be made at a
+ later stage. This is achieved by building source-specific state on
+ all routers along the path between the source and the RP. This
+ state is then used to natively forward packets from that source.
+
+ Both of these mechanisms suffer from problems. Encapsulation results
+ in significant processing, bandwidth, and delay overheads.
+ Forwarding using source-specific state has additional protocol and
+ memory requirements.
+
+
+
+
+Handley, et al. Standards Track [Page 3]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Bidirectional PIM dispenses with both encapsulation and source state
+ by allowing packets to be natively forwarded from a source to the RP
+ using shared tree state. In contrast to PIM-SM, this mode of
+ forwarding does not require any data-driven events.
+
+ The protocol specification in this document assumes familiarity with
+ the PIM-SM specification in [4]. Portions of the BIDIR-PIM protocol
+ operation that are identical to that of PIM-SM are only defined by
+ reference.
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
+ indicate requirement levels for compliant BIDIR-PIM implementations.
+
+2.1. Definitions
+
+ This specification uses a number of terms to refer to the roles of
+ routers participating in BIDIR-PIM. The following terms have special
+ significance for BIDIR-PIM:
+
+ Multicast Routing Information Base (MRIB)
+ The multicast topology table, which is typically derived from the
+ unicast routing table, or routing protocols such as Multiprotocol
+ BGP (MBGP) [8] that carry multicast-specific topology information.
+ It is used by PIM for establishing the RPF interface (used in the
+ forwarding rules). In PIM-SM, the MRIB is also used to make
+ decisions regarding where to forward Join/Prune messages, whereas
+ in BIDIR-PIM, it is used as a source for routing metrics for the
+ DF election process.
+
+ Rendezvous Point Address (RPA)
+ An RPA is an address that is used as the root of the distribution
+ tree for a range of multicast groups. The RPA must be routable
+ from all routers in the PIM domain. The RPA does not need to
+ correspond to an address for an interface of a real router. In
+ this respect, BIDIR-PIM differs from PIM-SM, which requires an
+ actual router to be configured as the Rendezvous Point (RP). Join
+ messages from receivers for a BIDIR-PIM group propagate hop-by-hop
+ towards the RPA.
+
+ Rendezvous Point Link (RPL)
+ An RPL for a particular RPA is the physical link to which the RPA
+ belongs. In BIDIR-PIM, all multicast traffic to groups mapping to
+ a specific RPA is forwarded on the RPL of that RPA. The RPL is
+ special within a BIDIR-PIM domain as it is the only link on which
+
+
+
+Handley, et al. Standards Track [Page 4]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ a Designated Forwarder election does not take place (see DF
+ definition below).
+
+ Upstream
+ Towards the root (RPA) of the tree. The direction used by packets
+ traveling from sources to the RPL.
+
+ Downstream
+ Away from the root of the tree. The direction on which packets
+ travel from the RPL to receivers.
+
+ Designated Forwarder (DF)
+ The protocol presented in this document is largely based on the
+ concept of a Designated Forwarder (DF). A single DF exists for
+ each RPA on every link within a BIDIR-PIM domain (this includes
+ both multi-access and point-to-point links). The only exception
+ is the RPL on which no DF exists. The DF is the router on the
+ link with the best route to the RPA (determined by comparing MRIB
+ provided metrics). A DF for a given RPA is in charge of
+ forwarding downstream traffic onto its link, and forwarding
+ upstream traffic from its link towards the RPL. It does this for
+ all the bidirectional groups that map to the RPA. The DF on a
+ link is also responsible for processing Join messages from
+ downstream routers on the link as well as ensuring that packets
+ are forwarded to local receivers (discovered through a local
+ membership mechanism such as MLD [3] or IGMP [2]).
+
+ RPF Interface
+ RPF stands for "Reverse Path Forwarding". The RPF Interface of a
+ router with respect to an address is the interface that the MRIB
+ indicates should be used to reach that address. In the case of a
+ BIDIR-PIM multicast group, the RPF interface is determined by
+ looking up the RPA in the MRIB. The RPF information determines
+ the interface of the router that would be used to send packets
+ towards the RPL for the group.
+
+ RPF Neighbor
+ The RPF Neighbor of a router with respect to an address is the
+ neighbor that the MRIB indicates should be used to reach that
+ address. Note that in BIDIR-PIM, the RPF neighbor for a group is
+ not necessarily the router on the RPF interface that Join messages
+ for that group would be directed to (Join messages are only
+ directed to the DF on the RPF interface for the group).
+
+ Tree Information Base (TIB)
+ This is the collection of state at a PIM router that has been
+ created by receiving PIM Join/Prune messages, PIM DF election
+ messages, and IGMP or MLD information from local hosts. It
+
+
+
+Handley, et al. Standards Track [Page 5]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ essentially stores the state of all multicast distribution trees
+ at that router.
+
+ Multicast Forwarding Information Base (MFIB)
+ The TIB holds all the state that is necessary to forward multicast
+ packets at a router. However, although this specification defines
+ forwarding in terms of the TIB, to actually forward packets using
+ the TIB is very inefficient. Instead, a real router
+ implementation will normally build an efficient MFIB from the TIB
+ state to perform forwarding. How this is done is implementation-
+ specific, and is not discussed in this document.
+
+2.2. Pseudocode Notation
+
+ We use set notation in several places in this specification.
+
+ A (+) B
+ is the union of two sets, A and B.
+
+ A (-) B is the elements of set A that are not in set B.
+
+ NULL
+ is the empty set or list.
+
+ In addition, we use C-like syntax:
+
+ = denotes assignment of a variable.
+
+ == denotes a comparison for equality.
+
+ != denotes a comparison for inequality.
+
+ Braces { and } are used for grouping.
+
+3. Protocol Specification
+
+ The specification of BIDIR-PIM is broken into several parts:
+
+ o Section 3.1 details the protocol state stored.
+
+ o Section 3.2 defines the BIDIR-PIM extensions to the PIM-SM [4]
+ neighbor discovery mechanism.
+
+ o Section 3.3 specifies the data packet forwarding rules.
+
+ o Section 3.4 specifies the BIDIR-PIM Join/Prune generation and
+ processing rules.
+
+
+
+
+Handley, et al. Standards Track [Page 6]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ o Section 3.5 specifies the Designated Forwarder (DF) election.
+
+ o Section 3.7 specifies the PIM packet formats.
+
+ o Section 3.6 summarizes BIDIR-PIM timers and gives their default
+ values.
+
+3.1. BIDIR-PIM Protocol State
+
+ This section specifies all the protocol state that a BIDIR-PIM
+ implementation should maintain in order to function correctly. We
+ term this state the Tree Information Base or TIB, as it holds the
+ state of all the multicast distribution trees at this router. In
+ this specification, we define PIM mechanisms in terms of the TIB.
+ However, only a very simple implementation would actually implement
+ packet forwarding operations in terms of this state. Most
+ implementations will use this state to build a multicast forwarding
+ table, which would then be updated when the relevant state in the TIB
+ changes.
+
+ Although we specify precisely the state to be kept, this does not
+ mean that an implementation of BIDIR-PIM needs to hold the state in
+ this form. This is actually an abstract state definition, which is
+ needed in order to specify the router's behavior. A BIDIR-PIM
+ implementation is free to hold whatever internal state it requires,
+ and will still be conformant with this specification so long as it
+ results in the same externally visible protocol behavior as an
+ abstract router that holds the following state.
+
+ We divide TIB state into two sections:
+
+ RPA state
+ State that maintains the DF election information for each RPA.
+
+ Group state
+ State that maintains a group-specific tree for groups that map to
+ a given RPA.
+
+ The state that should be kept is described below. Of course,
+ implementations will only maintain state when it is relevant to
+ forwarding operations - for example, the "NoInfo" state might be
+ assumed from the lack of other state information, rather than being
+ held explicitly.
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 7]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+3.1.1. General Purpose State
+
+ A router holds the following state that is not specific to an RPA or
+ group:
+
+ Neighbor State:
+
+ For each neighbor:
+
+ o Neighbor's Gen ID
+
+ o Neighbor liveness timer (NLT)
+
+ o Other information from neighbor's Hello
+
+ For more information on Hello information, look at Section 3.2 as
+ well as the PIM-SM specification in [4].
+
+3.1.2. RPA State
+
+ A router maintains a multicast-group to RPA mapping, which is built
+ through static configuration or by using an automatic RP discovery
+ mechanism like BSR or AUTO-RP (see Section 4). For each BIDIR-PIM
+ RPA, a router holds the following state:
+
+ o RPA (actual address)
+
+ Designated Forwarder (DF) State:
+
+ For each router interface:
+
+ Acting DF information:
+
+ o DF IP Address
+
+ o DF metric
+
+ Election information:
+
+ o Election State
+
+ o DF election-Timer (DFT)
+
+ o Message-Count (MC)
+
+ Current best offer:
+
+ o IP address of best offering router
+
+
+
+Handley, et al. Standards Track [Page 8]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ o Best offering router metric
+
+ Designated Forwarder state is described in Section 3.5.
+
+3.1.3. Group State
+
+ For every group G, a router keeps the following state:
+
+ Group state:
+
+ For each interface:
+
+ Local Membership:
+
+ o State: One of {"NoInfo", "Include"}
+
+ PIM Join/Prune State:
+
+ o State: One of {"NoInfo" (NI), "Join" (J),
+ "PrunePending" (PP)}
+
+ o PrunePendingTimer (PPT)
+
+ o Join/Prune Expiry Timer (ET)
+
+ Not interface specific:
+
+ o Upstream Join/Prune Timer (JT)
+
+ o Last RPA Used
+
+ Local membership is the result of the local membership mechanism
+ (such as IGMP [2]) running on that interface. This information is
+ used by the pim_include(*,G) macro described in Section 3.1.4.
+
+ PIM Join/Prune state is the result of receiving PIM (*,G) Join/Prune
+ messages on this interface, and is specified in Section 3.4.1. The
+ state is used by the macros that calculate the outgoing interface
+ list in Section 3.1.4, and in the JoinDesired(G) macro (defined in
+ Section 3.4.2) that is used in deciding whether a Join(*,G) should be
+ sent upstream.
+
+ The upstream Join/Prune timer is used to send out periodic Join(*,G)
+ messages, and to override Prune(*,G) messages from peers on an
+ upstream LAN interface.
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 9]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ The last RPA used must be stored because if the group to RPA mapping
+ changes (see RP Set changes in [4]), then state must be torn down and
+ rebuilt for groups whose RPA changes.
+
+3.1.4. State Summarization Macros
+
+ Using this state, we define the following "macro" definitions that we
+ will use in the descriptions of the state machines and pseudocode in
+ the following sections.
+
+ olist(G) =
+ RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G)
+
+ RPF_interface(RPA) is the interface the MRIB indicates would be used
+ to route packets to RPA. The olist(G) is the list of interfaces on
+ which packets to group G must be forwarded.
+
+ The macro pim_include(G) indicates the interfaces to which traffic
+ might be forwarded because of hosts that are local members on that
+ interface.
+
+ pim_include(G) =
+ { all interfaces I such that:
+ I_am_DF(RPA(G),I) AND local_receiver_include(G,I) }
+
+ The clause "I_am_DF(RPA,I)" is TRUE if the router is in the Win or
+ Backoff states in the DF election state machine (described in Section
+ 3.5) for the given RPA on interface I. Otherwise, it is FALSE.
+
+ The clause "local_receiver_include(G,I)" is true if the IGMP module,
+ MLD module, or other local membership mechanism has determined that
+ there are local members on interface I that desire to receive traffic
+ sent to group G.
+
+ The set "joins(G)" is the set of all 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 Joined or PrunePending }
+
+ DownstreamJPState(G,I) is the state of the finite state machine in
+ Section 3.4.1.
+
+ RPF_DF(RPA) is the neighbor that Join messages must be sent to in
+ order to build the group shared tree rooted at the RPL for the given
+ RPA. This is the Designated-Forwarder on the RPF_interface(RPA).
+
+
+
+Handley, et al. Standards Track [Page 10]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+3.2. PIM Neighbor Discovery
+
+ PIM routers exchange PIM-Hello messages with their neighboring PIM
+ routers. These messages are used to update the Neighbor State
+ described in Section 3.1. The procedures for generating and
+ processing Hello messages as well as maintaining Neighbor State are
+ specified in the PIM-SM [4] documentation.
+
+ BIDIR-PIM introduces the Bidirectional Capable PIM-Hello option that
+ MUST be included in all Hello messages from a BIDIR-PIM capable
+ router. The Bidirectional Capable option advertises the router's
+ ability to participate in the BIDIR-PIM protocol. The format of the
+ Bidirectional Capable option is described in Section 3.7.
+
+ If a BIDIR-PIM router receives a PIM-Hello message that does not
+ contain the Bidirectional Capable option from one of its neighbors,
+ the error must be logged to the router administrator in a rate-
+ limited manner.
+
+3.3. Data Packet Forwarding Rules
+
+ For groups mapping to a given RPA, the following responsibilities are
+ uniquely assigned to the DF for that RPA on each link:
+
+ o The DF is the only router that forwards packets traveling
+ downstream onto the link.
+
+ o The DF is the only router that picks-up upstream traveling packets
+ off the link to forward towards the RPL.
+
+ Non-DF routers on a link, which use that link as their RPF interface
+ to reach the RPA, may perform the following forwarding actions for
+ bidirectional groups:
+
+ o Forward packets from the link towards downstream receivers.
+
+ o Forward packets from downstream sources onto the link (provided
+ they are the DF for the downstream link from which the packet was
+ picked-up).
+
+ The BIDIR-PIM packet forwarding rules are defined below in
+ pseudocode.
+
+ iif is the incoming interface of the packet.
+ G is the destination address of the packet (group address).
+ RPA is the Rendezvous Point Address for this group.
+
+
+
+
+
+Handley, et al. Standards Track [Page 11]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ First we check to see whether the packet should be accepted based on
+ TIB state and the interface that the packet arrived on. A packet is
+ accepted if it arrives on the RPF interface to reach the RPA
+ (downstream traveling packet) or if the router is the DF on the
+ interface the packet arrives (upstream traveling packet).
+
+ If the packet should be forwarded, we build an outgoing interface
+ list for the packet.
+
+ Finally, we remove the incoming interface from the outgoing interface
+ list we've created, and if the resulting outgoing interface list is
+ not empty, we forward the packet out of those interfaces.
+
+ On receipt of data to G on interface iif:
+ if( iif == RPF_interface(RPA) || I_am_DF(RPA,iif) ) {
+ oiflist = olist(G) (-) iif
+ forward packet on all interfaces in oiflist
+ }
+
+3.3.1. Upstream Forwarding at RP
+
+ When configuring a BIDIR-PIM domain, it is possible to assign the
+ Rendezvous Point Address (RPA) such that it does not belong to a
+ physical box but instead is simply a routable address. Routers that
+ have interfaces on the RPL that the RPA belongs to will upstream
+ forward traffic onto the link. Joins from receivers in the domain
+ will propagate hop-by-hop till they reach one of the routers
+ connected to the RPL where they will terminate (as there will be no
+ DF elected on the RPL).
+
+ If instead the administrator chooses to configure the RPA to be the
+ address of a physical interface of a specific router, then nothing
+ changes. That router must still upstream forward traffic on to the
+ RPL and behave no differently than any other router with an interface
+ on the RPL.
+
+ To configure a BIDIR-PIM network to operate in a mode similar to that
+ of PIM-SM where a single router (the RP) is acting as the root of the
+ distribution tree, the RPA can be configured to be the loopback
+ interface of a router.
+
+3.3.2. Source-Only Branches
+
+ Source-only branches of the distribution tree for a group G are
+ branches that do not lead to any receivers, but that are used to
+ forward packets traveling upstream from sources towards the RPL.
+ Routers along source-only branches only have the RPF interface to the
+ RPA in their olist for G, and hence do not need to maintain any group
+
+
+
+Handley, et al. Standards Track [Page 12]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ specific state. Upstream forwarding can be performed using only RPA
+ specific state. An implementation may decide to maintain group state
+ for source-only branches for accounting or performance reasons.
+ However, doing so requires data-driven events (to discover the groups
+ with active sources), thus sacrificing one of the main benefits of
+ BIDIR-PIM.
+
+3.3.3. Directly Connected Sources
+
+ A major advantage of using a Designated Forwarder in BIDIR-PIM
+ compared to PIM-SM is that special treatment is no longer required
+ for sources that are directly connected to a router. Data from such
+ sources does not need to be differentiated from other multicast
+ traffic and will automatically be picked up by the DF and forwarded
+ upstream. This removes the need for performing a directly-
+ connected-source check for data to groups that do not have existing
+ state.
+
+3.4. PIM Join/Prune Messages
+
+ BIDIR-PIM Join/Prune messages are used to construct group-specific
+ distribution trees between receivers and the RPL. Joins are
+ originated by last-hop routers that are elected as the DF on an
+ interface with directly connected receivers. The Joins propagate
+ hop-by-hop towards the RPA until they reach a router connected to the
+ RPL.
+
+ A BIDIR-PIM Join/Prune message consists of a list of Joined and
+ Pruned Groups. When processing a received Join/Prune message, each
+ Joined or Pruned Group is effectively considered individually by
+ applying the following state machines. When considering a Join/Prune
+ message whose PIM Destination field addresses this router, (*,G)
+ Joins and Prunes can affect the downstream state machine. When
+ considering a Join/Prune message whose PIM Destination field
+ addresses another router, most Join or Prune entries could affect the
+ upstream state machine.
+
+3.4.1. Receiving (*,G) Join/Prune Messages
+
+ When a router receives a Join(*,G) or Prune(*,G), it MUST first check
+ to see whether the RP address in the message matches RPA(G) (the
+ router's idea of what the Rendezvous Point Address is). If the RP
+ address in the message does not match RPA(G), the Join or Prune MUST
+ be silently dropped.
+
+ If a router has no RPA information for the group (e.g., has not
+ recently received a BSR message), then it MAY choose to accept
+ Join(*,G) or Prune(*,G) and treat the RP address in the message as
+
+
+
+Handley, et al. Standards Track [Page 13]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ RPA(G). If the newly discovered RPA did not previously exist for any
+ other group, a DF election has to be initiated.
+
+ Note that a router will process a Join(*,G) targeted to itself even
+ if it is not the DF for RP(G) on the interface on which the message
+ was received. This is an optimisation to eliminate the Join delay of
+ one Join period (t_periodic) in the case where a new DF processes the
+ received Pass and Join messages in reverse order. The BIDIR-PIM
+ forwarding logic will ensure that data packets are not forwarded on
+ such an interface while the router is not the DF (unless it is the
+ RPF interface towards the RPA).
+
+ The per-interface state machine for receiving (*,G) Join/Prune
+ Messages is given below. There are three states:
+
+ NoInfo (NI)
+ The interface has no (*,G) Join state and no timers running.
+
+ Join (J)
+ The interface has (*,G) Join state. 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 destined for G on this interface.
+
+ PrunePending (PP)
+ The router has received a Prune(*,G) on this interface from a
+ downstream neighbor and is waiting to see whether the Prune
+ will be overridden by another downstream router. For
+ forwarding purposes, the PrunePending state functions exactly
+ like the Join state.
+
+ In addition, the state machine uses two timers:
+
+ ExpiryTimer (ET)
+ This timer is restarted when a valid Join(*,G) is received.
+ Expiry of the ExpiryTimer causes the interface state to revert
+ to NoInfo for this group.
+
+ PrunePendingTimer (PPT)
+ This timer is set when a valid Prune(*,G) is received. Expiry
+ of the PrunePendingTimer causes the interface state to revert
+ to NoInfo for this group.
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 14]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Figure 1: Downstream group per-interface state machine in tabular
+ form
+
+ +---------------++---------------------------------------------------+
+ | || Prev State |
+ |Event ++---------------+-----------------+-----------------+
+ | || NoInfo (NI) | Join (J) | PrunePending |
+ | || | | (PP) |
+ +---------------++---------------+-----------------+-----------------+
+ | || -> J state | -> J state | -> J state |
+ |Receive || start Expiry | restart Expiry | restart Expiry |
+ |Join(*,G) || Timer | Timer | Timer; stop |
+ | || | | PrunePending- |
+ | || | | Timer |
+ +---------------++---------------+-----------------+-----------------+
+ |Receive || - | -> PP state | -> PP state |
+ |Prune(*,G) || | start Prune- | |
+ | || | PendingTimer | |
+ +---------------++---------------+-----------------+-----------------+
+ |PrunePending- || - | - | -> NI state |
+ |Timer Expires || | | Send Prune- |
+ | || | | Echo(*,G) |
+ +---------------++---------------+-----------------+-----------------+
+ |Expiry Timer || - | -> NI state | -> NI state |
+ |Expires || | | |
+ +---------------++---------------+-----------------+-----------------+
+ |Stop Being DF || - | -> NI state | -> NI state |
+ |on I || | | |
+ +---------------++---------------+-----------------+-----------------+
+
+ The transition events "Receive Join(*,G)" and "Receive Prune(*,G)"
+ imply receiving a Join or Prune targeted to this router's address on
+ the received interface. If the destination address is not correct,
+ these state transitions in this state machine must not occur,
+ although seeing such a packet may cause state transitions in other
+ state machines.
+
+ On unnumbered interfaces on point-to-point links, the router's
+ address should be the same as the source address it chose for the
+ Hello packet it sent over that interface. However, on point-to-point
+ links, we also RECOMMEND that PIM messages with a destination address
+ of all zeros also be accepted.
+
+ The transition event "Stop Being DF" implies a DF re-election taking
+ place on this router interface for RPA(G) and the router changing
+ status from being the active DF to being a non-DF router (the value
+ of the I_am_DF macro changing to FALSE).
+
+
+
+
+Handley, et al. Standards Track [Page 15]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ When ExpiryTimer is started or restarted, it is set to the HoldTime
+ from the Join/Prune message that triggered the timer.
+
+ When PrunePendingTimer is started, it is set to the
+ J/P_Override_Interval if the router has more than one neighbor on
+ that interface; otherwise, it is set to zero causing it to expire
+ immediately.
+
+ The action "Send PruneEcho(*,G)" is triggered when the router stops
+ forwarding on an interface as a result of a Prune. A PruneEcho(*,G)
+ is simply a Prune(*,G) message sent by the upstream router to itself
+ on a LAN. Its purpose is to add additional reliability so that if a
+ Prune that should have been overridden by another router is lost
+ locally on the LAN, then the PruneEcho may be received and cause the
+ override to happen. A PruneEcho(*,G) need not be sent when the
+ router has only one neighbor on the link.
+
+3.4.2. Sending Join/Prune Messages
+
+ The downstream per-interface state machines described above hold Join
+ state from downstream PIM routers. This state then determines
+ whether a router needs to propagate a Join(*,G) upstream towards the
+ RPA. Such Join(*,G) messages are sent on the RPF interface towards
+ the RPA and are targeted at the DF on that interface.
+
+ If a router wishes to propagate a Join(*,G) upstream, it must also
+ watch for messages on its upstream interface from other routers on
+ that subnet, and these may modify its behavior. If it sees a
+ Join(*,G) to the correct upstream neighbor, it should suppress its
+ own Join(*,G). If it sees a Prune(*,G) to the correct upstream
+ neighbor, it should be prepared to override that Prune by sending a
+ Join(*,G) almost immediately. Finally, if it sees the Generation ID
+ (see PIM-SM specification [4]) of the correct upstream neighbor
+ change, it knows that the upstream neighbor has lost state, and it
+ should be prepared to refresh the state by sending a Join(*,G) almost
+ immediately.
+
+ In addition, changes in the next hop towards the RPA trigger a Prune
+ off from the old next hop and join towards the new next hop. Such a
+ change can be caused by the following two events:
+
+ o The MRIB indicates that the RPF Interface towards the RPA has
+ changed. In this case the DF on the new RPF interface becomes
+ the new RPF Neighbor.
+
+ o There is a DF re-election on the RPF interface and a new router
+ emerges as the DF.
+
+
+
+
+Handley, et al. Standards Track [Page 16]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ The upstream (*,G) state machine only contains two states:
+
+ Not Joined
+ The downstream state machines indicate that the router does not
+ need to join the RPA tree for this group.
+
+ Joined
+ The downstream state machines indicate that the router would
+ like to join the RPA tree for this group.
+
+ In addition, one timer JT(G) is kept, which is used to trigger the
+ sending of a Join(*,G) to the upstream next hop towards the RPA (the
+ DF on the RPF interface for RPA(G)).
+
+ Figure 2: Upstream group state machine in tabular form
+
+ +---------------------+----------------------------------------------+
+ | | Event |
+ | Prev State +-----------------------+----------------------+
+ | | JoinDesired(G) | JoinDesired(G) |
+ | | ->True | ->False |
+ +---------------------+-----------------------+----------------------+
+ | | -> J state | - |
+ | NotJoined (NJ) | Send Join(*,G); | |
+ | | Set Timer to | |
+ | | t_periodic | |
+ +---------------------+-----------------------+----------------------+
+ | Joined (J) | - | -> NJ state |
+ | | | Send Prune(*,G) |
+ +---------------------+-----------------------+----------------------+
+
+ In addition, we have the following transitions that occur within the
+ Joined state:
+
+ +--------------------------------------------------------------------+
+ | In Joined (J) State |
+ +----------------+----------------+-----------------+----------------+
+ |Timer Expires | See Join(*,G) | See Prune(*,G) | RPF_DF(RPA(G)) |
+ | | to | to | GenID changes |
+ | | RPF_DF(RPA(G)) | RPF_DF(RPA(G)) | |
+ +----------------+----------------+-----------------+----------------+
+ |Send | Increase Timer | Decrease Timer | Decrease Timer |
+ |Join(*,G); Set | to | to t_override | to t_override |
+ |Timer to | t_suppressed | | |
+ |t_periodic | | | |
+ +----------------+----------------+-----------------+----------------+
+
+
+
+
+
+Handley, et al. Standards Track [Page 17]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ +--------------------------------------------------------------------+
+ | In Joined (J) State |
+ +-----------------------------------+--------------------------------+
+ | Change of RPF_DF(RPA(G)) | RPF_DF(RPA(G)) GenID |
+ | | changes |
+ +-----------------------------------+--------------------------------+
+ | Send Join(*,G) to new | Decrease Timer to |
+ | DF; Send Prune(*,G) to | t_override |
+ | old DF; set Timer to | |
+ | t_periodic | |
+ +-----------------------------------+--------------------------------+
+
+ This state machine uses the following macro:
+
+ bool JoinDesired(G) {
+ if (olist(G) (-) RPF_interface(RPA(G))) != NULL
+ return TRUE
+ else
+ return FALSE
+ }
+
+3.5. Designated Forwarder (DF) Election
+
+ This section presents a fail-safe mechanism for electing a per-RPA
+ designated router on each link in a BIDIR-PIM domain. We call this
+ router the Designated Forwarder (DF). The DF election does not take
+ place on the RPL for an RPA.
+
+3.5.1. DF Requirements
+
+ The DF election chooses the best router on a link to assume
+ responsibility for forwarding traffic between the RPL and the link
+ for the range of multicast groups served by the RPA. Different
+ multicast groups that share a common RPA share the same upstream
+ direction. Hence, the election of an upstream forwarder on each link
+ does not have to be a group-specific decision but instead can be
+ RPA-specific. As the number of RPAs is typically small, the number
+ of elections that have to be performed is significantly reduced by
+ this observation.
+
+ To optimise tree creation, it is desirable that the winner of the
+ election process should be the router on the link with the "best"
+ unicast routing metric (as reported by the MRIB) to reach the RPA.
+ When comparing metrics from different unicast routing protocols, we
+ use the same comparison rules used by the PIM-SM assert process [4].
+
+ The election process needs to take place when information on a new
+ RPA initially becomes available. The result can be re-used as new
+
+
+
+Handley, et al. Standards Track [Page 18]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ bidir groups that map to the same RPA are encountered. However,
+ there are some conditions under which an update to the election is
+ required:
+
+ o There is a change in unicast metric to reach the RPA for any of
+ the routers on the link.
+
+ o The interface on which the RPA is reachable (RPF Interface)
+ changes to an interface for which the router was previously the
+ DF.
+
+ o A new PIM neighbor starts up on a link that must participate in
+ the elections and be informed of the current outcome.
+
+ o The elected DF fails (detected through neighbor information
+ timeout or MRIB RPF change at downstream router).
+
+ The election process has to be robust enough to ensure with very high
+ probability that all routers on the link have a consistent view of
+ the DF. Given the forwarding rules described in Section 3.3, loops
+ may result if multiple routers end-up thinking that they should be
+ responsible for forwarding. To minimize the possibility of this
+ occurrence, the election algorithm has been biased towards discarding
+ DF information and suspending forwarding during periods of ambiguity.
+
+3.5.2. DF Election Description
+
+ This section gives an outline of the DF election process. It does
+ not provide the definitive specification for the DF election. If any
+ discrepancy exists between Section 3.5.3 and this section, the
+ specification in Section 3.5.3 is to be assumed correct.
+
+ To perform the election of the DF for a particular RPA, routers on a
+ link need to exchange their unicast routing metric information for
+ reaching the RPA. Routers advertise their own metrics in Offer,
+ Winner, Backoff, and Pass messages. The advertised metric is
+ calculated using the RPF Interface and metric to reach the RPA
+ available through the MRIB. When a router is participating in a DF
+ election for an RPA on the interface that its MRIB indicates as the
+ RPF Interface, then that router MUST always advertise an infinite
+ metric in its election messages. When a router is participating in a
+ DF election on an interface other than the MRIB-indicated RPF
+ Interface then it MUST advertise the MRIB-provided metrics in its
+ election messages.
+
+ In the election protocol described below, many message exchanges are
+ repeated Election_Robustness times for reliability. In all those
+ cases, the message retransmissions are spaced in time by a small
+
+
+
+Handley, et al. Standards Track [Page 19]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ random interval. All of the following description is specific to the
+ election on a single link for a single RPA.
+
+3.5.2.1. Bootstrap Election
+
+ Initially, when no DF has been elected, routers finding out about a
+ new RPA start participating in the election by sending Offer
+ messages. Offer messages include the router's metric to reach the
+ RPA. Offers are periodically retransmitted with a period of
+ Offer_Interval.
+
+ If a router hears a better offer than its own from a neighbor, it
+ stops participating in the election for a period of
+ Election_Robustness * Offer_Interval, thus giving a chance to the
+ neighbor with the better metric to be elected DF. If during this
+ period no winner is elected, the router restarts the election from
+ the beginning. If at any point during the initial election a router
+ receives an out of order offer with worse metrics than its own, then
+ it restarts the election from the beginning.
+
+ The result should be that all routers except the best candidate stop
+ advertising their offers.
+
+ A router assumes the role of the DF after having advertised its
+ metrics Election_Robustness times without receiving any offer from
+ any other neighbor. At that point, it transmits a Winner message
+ that declares to every other router on the link the identity of the
+ winner and the metrics it is using.
+
+ Routers receiving a Winner message stop participating in the election
+ and record the identity and metrics of the winner. If the local
+ metrics are better than those of the winner, then the router records
+ the identity of the winner (accepting it as the acting DF) but re-
+ initiates the election to try and take over.
+
+3.5.2.2. Loser Metric Changes
+
+ Whenever the unicast metric to an RPA changes at a non-DF router to a
+ value that is better than that previously advertised by the acting
+ DF, the router with the new better metric should take action to
+ eventually assume forwarding responsibility. When the metric change
+ is detected, the non-DF router with the now better metric restarts
+ the DF election process by sending Offer messages with this new
+ metric. Note that at any point during an election if no response is
+ received after Election_Robustness retransmissions of an offer, a
+ router assumes the role of the DF following the usual Winner
+ announcement procedure.
+
+
+
+
+Handley, et al. Standards Track [Page 20]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Upon receipt of an offer that is worse than its current metric, the
+ DF will respond with a Winner message declaring its status and
+ advertising its better metric. Upon receiving the Winner message,
+ the originator of the Offer records the identity of the DF and aborts
+ the election.
+
+ Upon receipt of an offer that is better than its current metric, the
+ DF records the identity and metrics of the offering router and
+ responds with a Backoff message. This instructs the offering router
+ to hold off for a short period of time while the unicast routing
+ stabilizes and other routers get a chance to put in their offers.
+ The Backoff message includes the offering router's new metric and
+ address. All routers on the link that have pending offers with
+ metrics worse than those in the Backoff message (including the
+ original offering router) will hold further offers for a period of
+ time defined in the Backoff message.
+
+ If a third router sends a better offer during the Backoff_Period, the
+ Backoff message is repeated for the new offer and the Backoff_Period
+ is restarted.
+
+ Before the Backoff_Period expires, the acting DF nominates the router
+ having made the best offer as the new DF using a Pass message. This
+ message includes the IDs and metrics of both the old and new DFs.
+ The old DF stops performing its tasks at the time the Pass message
+ transmission is made. The new DF assumes the role of the DF as soon
+ as it receives the Pass message. All other routers on the link take
+ note of the new DF and its metric. Note that this event constitutes
+ an RPF Neighbor change, which may trigger Join messages to the new DF
+ (see Section 3.4).
+
+3.5.2.3. Winner Metric Changes
+
+ If the DF's routing metric to reach the RPA changes to a worse value,
+ it sends a set of Election_Robustness randomly spaced Winner messages
+ on the link, advertising the new metric. Routers that receive this
+ announcement but have a better metric may respond with an Offer
+ message that results in the same handoff procedure described above.
+ All routers assume the DF has not changed until they see a Pass or
+ Winner message indicating the change.
+
+ There is no pressure to make this handoff quickly if the acting DF
+ still has a path to the RPL. The old path may now be suboptimal, but
+ it will still work while the re-election is in progress.
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 21]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+3.5.2.4. Winner Loses Path
+
+ If a router's RPF Interface to the RPA switches to be on a link for
+ which it is acting as the DF, then it can no longer provide
+ forwarding services for that link. It therefore immediately stops
+ being the DF and restarts the election. As its path to the RPA is
+ through the link, an infinite metric is used in the Offer message it
+ sends.
+
+3.5.2.5. Late Router Starting Up
+
+ A late router starting up after the DF election process has completed
+ will have no immediate knowledge of the election outcome. As a
+ result, it will start advertising its metric in Offer messages. As
+ soon as this happens, the currently elected DF will respond with a
+ Winner message if its metric is better than the metric in the Offer
+ message, or with a Backoff message if its metric is worse than the
+ metric in the Offer message.
+
+3.5.2.6. Winner Dies
+
+ Whenever the DF dies, a new DF has to be elected. The speed at which
+ this can be achieved depends on whether there are any downstream
+ routers on the link.
+
+ If there are downstream routers, typically their MRIB reported next-
+ hop before the DF dies will be the DF itself. They will therefore
+ notice either a change in the metric for the route to the RPA or a
+ change in next-hop away from the DF and can restart the election by
+ transmitting Offer messages. If according to the MRIB the RPA is now
+ reachable through the same link via another upstream router, an
+ infinite metric will be used in the Offer.
+
+ If no downstream routers are present, the only way for other upstream
+ routers to detect a DF failure is by the timeout of the PIM neighbor
+ information, which will take significantly longer.
+
+3.5.3. Election Protocol Specification
+
+ This section provides the definitive specification for the DF
+ election process. If any discrepancy exists between Section 3.5.2
+ and this section, the specification in this section is to be assumed
+ correct.
+
+3.5.3.1. Election State
+
+ The DF election state is maintained per RPA for each multicast
+ enabled interface I on the router as introduced in Section 3.1.
+
+
+
+Handley, et al. Standards Track [Page 22]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ The state machine has the following four states:
+
+ Offer
+ Initial election state. When in the Offer state, a router
+ thinks it can eventually become the winner and periodically
+ generates Offer messages.
+
+ Lose
+ In this state, the router knows that there either is a
+ different election winner or that no router on the link has a
+ path to the RPA.
+
+ Win
+ The router is the acting DF without any contest.
+
+ Backoff
+ The router is the acting DF but another router has made a bid
+ to take over.
+
+ In the state machine, a router is considered to be an acting DF if it
+ is in the Win or Backoff states.
+
+ The operation of the election protocol makes use of the variables and
+ timers described below:
+
+ Acting DF information
+ Used to store the identity and advertised metrics of the
+ election winner that is the currently acting DF.
+
+ DF election-Timer (DFT)
+ Used to schedule transmission of Offer, Winner, and Pass
+ messages.
+
+ Message-Count (MC)
+ Used to maintain the number of times an Offer or Winner message
+ has been transmitted.
+
+ Best-Offer
+ Used by the DF to record the identity and advertised metrics of
+ the router that has made the last offer, for use when sending
+ the Path message.
+
+3.5.3.2. Election Messages
+
+ The election process uses the following PIM control messages. The
+ packet format is described in Section 3.7:
+
+
+
+
+
+Handley, et al. Standards Track [Page 23]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Offer (OfferingID, Metric)
+ Sent by routers that believe they have a better metric to the
+ RPA than the metric that has been on offer so far.
+
+ Winner (DF-ID, DF-Metric)
+ Sent by a router when assuming the role of the DF or when re-
+ asserting in response to worse offers.
+
+ Backoff (DF-ID, DF-Metric, OfferingID, OfferMetric,
+ BackoffInterval)
+ Used by the DF to acknowledge better offers. It instructs
+ other routers with equal or worse offers to wait until the DF
+ passes responsibility to the sender of the offer.
+
+ Pass (Old-DF-ID, Old-DF-Metric, New-DF-ID, New-DF-Metric)
+ Used by the old DF to pass forwarding responsibility to a
+ router that has previously made an offer. The Old-DF-Metric is
+ the current metric of the DF at the time the pass is sent.
+
+ Note that when a router is participating in a DF election for an RPA
+ on the interface that its MRIB indicates as the RPF Interface, then
+ that router MUST always advertise an infinite metric in its election
+ messages. When a router is participating in a DF election on an
+ interface other than the MRIB-indicated RPF Interface, then it MUST
+ advertise the MRIB-provided metrics in its election messages.
+
+3.5.3.3. Election Events
+
+ During protocol operation, the following events can take place:
+
+ Control message reception
+ Reception of one of the four control DF election messages
+ (Offer, Winner, Backoff, and Pass). When a control message is
+ received and actions are specified on a condition that metrics
+ are Better or Worse, the comparison must be performed as
+ follows:
+
+ o On receipt of an Offer or Winner message, compare the current
+ metrics for the RPA with the metrics advertised for the
+ sender of the message.
+
+ o On receipt of a Backoff or Pass message, compare the current
+ metrics for the RPA with the metrics advertised for the
+ target of the message.
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 24]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Path to RPA lost
+ Losing the path to the RPA can happen in two ways. The first
+ happens when the route learned through the MRIB is withdrawn
+ and the MRIB no longer reports an available route to reach the
+ RPA. The second case happens when the next-hop information
+ reported by the MRIB changes to indicate a next-hop that is
+ reachable through the router interface under consideration.
+ Clearly, as the router is using the interface as its RPF
+ Interface, it cannot offer forwarding services towards the RPL
+ to other routers on that link.
+
+ Metric reported by the MRIB to reach the RPA changes
+ This event is triggered when the MRIB supplied information for
+ the RPA changes and the new information provides a path to the
+ RPA. If the new MRIB information either reports no route or
+ reports a next-hop interface through the interface for which
+ the DF election is taking place, then the "Path to RPA lost"
+ event triggers instead. In specific states, the event may be
+ further filtered by specifying whether it is expected of the
+ metric to become better or worse and which of the stored
+ metrics the new MRIB information must be compared against. The
+ new information must be compared with either the router's old
+ metric, the stored DF metric, or the stored Best Offer metric.
+
+ Election-Timer (DFT) expiration
+ Expiration of the DFT election timer can cause message
+ transmission and state transitions. The event might be further
+ qualified by specifying the value of the Message Count (MC) as
+ well as the current existence of a path to the RPA (as defined
+ above).
+
+ Detection of DF failure
+ Detection of DF failure can occur through the timeout of PIM
+ neighbor state.
+
+3.5.3.4. Election Actions
+
+ The DF election state machine action descriptions use the following
+ notation in addition to the pseudocode notation described earlier in
+ this specification:
+
+ ?= denotes the operation of lowering a timer to a new value. If
+ the timer is not running, then it is started using the new
+ value. If the timer is running with an expiration lower than
+ the new value, then the timer is not altered.
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 25]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ When an action of "set DF to Sender or Target" is encountered during
+ receipt of a Winner, Pass, or Backoff message, it means the
+ following:
+
+ o On receipt of a Winner message, set the DF to be the originator
+ of the message and record its metrics.
+
+ o On receipt of a Pass message, set the DF to be the target of the
+ message and record its metrics.
+
+ o On receipt of a Backoff message, set the DF to be the originator
+ of the message and record its metrics.
+
+3.5.3.5. Election State Transitions
+
+ When a Designated Forwarder election is initiated, the starting state
+ is the Offer state, the message counter (MC) is set to zero, and the
+ DF election Timer (DFT) is set to OPlow (see Section 3.6 for a
+ definition of timer values).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 26]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Figure 3: Designated Forwarder election state machine in tabular form
+
+ +-------------+------------------------------------------------------+
+ | | Event |
+ | Prev State +-----------------+------------------+-----------------+
+ | | Recv better | Recv better | Recv better |
+ | | Pass / Win | Backoff | Offer |
+ +-------------+-----------------+------------------+-----------------+
+ | | -> Lose | - | - |
+ | Offer | DF = Sender or | DFT = BOperiod | DFT = OPhigh; |
+ | | Target; Stop | + OPlow; MC = | MC = 0 |
+ | | DFT | 0 | |
+ +-------------+-----------------+------------------+-----------------+
+ | | - | - | -> Offer |
+ | Lose | DF = Sender or | DF = Sender | DFT = OPhigh; |
+ | | Target | | MC = 0 |
+ +-------------+-----------------+------------------+-----------------+
+ | | -> Lose | -> Lose | -> Backoff |
+ | | DF = Sender or | DF = Sender; | Set Best to |
+ | Win | Target; Stop | Stop DFT | Sender; Send |
+ | | DFT | | Backoff; DFT = |
+ | | | | BOperiod |
+ +-------------+-----------------+------------------+-----------------+
+ | | -> Lose | -> Lose | - |
+ | | DF = Sender or | DF = Sender; | Set Best to |
+ | Backoff | Target; Stop | Stop DFT | Sender; Send |
+ | | DFT | | Backoff; DFT = |
+ | | | | BOperiod |
+ +-------------+-----------------+------------------+-----------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 27]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ +-----------+-------------------------------------------------------+
+ | | Event |
+ | +-------------+-------------+--------------+------------+
+ |Prev State |Recv Backoff |Recv Pass |Recv Worse |Recv worse |
+ | |for us |for us |Pass / Win / |Offer |
+ | | | |Backoff | |
+ +-----------+-------------+-------------+--------------+------------+
+ | |- |-> Win |- |- |
+ | |DFT = |Stop DFT |Set DF to |DFT ?= |
+ |Offer |BOperiod + | |Sender or |OPlow; MC = |
+ | |OPlow; MC = | |Target; DFT |0 |
+ | |0 | |?= OPlow; MC | |
+ | | | |= 0 | |
+ +-----------+-------------+-------------+--------------+------------+
+ | |-> Offer |-> Offer |-> Offer |-> Offer |
+ | |DF = Sender; |DF = Sender; |DF = Sender |DFT = OPlow;|
+ |Lose |DFT = OPlow; |DFT = OPlow; |or Target; |MC = 0 |
+ | |MC = 0 |MC = 0 |DFT = OPlow; | |
+ | | | |MC = 0 | |
+ +-----------+-------------+-------------+--------------+------------+
+ | |-> Offer |-> Offer |-> Offer |- |
+ | |DF = Sender; |DF = Sender; |DF = Sender |Send Winner |
+ |Win |DFT = OPlow; |DFT = OPlow; |or Target; | |
+ | |MC = 0 |MC = 0 |DFT = OPlow; | |
+ | | | |MC = 0 | |
+ +-----------+-------------+-------------+--------------+------------+
+ | |-> Offer |-> Offer |-> Offer |-> Win |
+ | |DF = Sender; |DF = Sender; |DF = Sender |Send Winner;|
+ |Backoff |DFT = OPlow; |DFT = OPlow; |or Target; |Stop DFT |
+ | |MC = 0 |MC = 0 |DFT = OPlow; | |
+ | | | |MC = 0 | |
+ +-----------+-------------+-------------+--------------+------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 28]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ +--------------------------------------------------------------------+
+ | In Offer State |
+ +----------------------+----------------------+----------------------+
+ | DFT Expires and MC | DFT Expires and MC | DFT Expires and MC |
+ | is less than | is equal to | is equal to |
+ | Robustness | Robustness and we | Robustness and |
+ | | have path to RPA | there is no path |
+ | | | to RPA |
+ +----------------------+----------------------+----------------------+
+ | - | -> Win | -> Lose |
+ | Send Offer; DFT = | Send Winner | Set DF to None |
+ | OPlow; MC = MC + 1 | | |
+ +----------------------+----------------------+----------------------+
+ +--------------------------------------------------------------------+
+ | In Offer State |
+ +--------------------------------------------------------------------+
+ | Metric changes and is now worse |
+ +--------------------------------------------------------------------+
+ | DFT ?= OPlow |
+ | MC = 0 |
+ +--------------------------------------------------------------------+
+
+ +--------------------------------------------------------------------+
+ | In Lose State |
+ +------------------------------+-------------------------------------+
+ | Detect DF Failure | Metric changes and now |
+ | | is better than DF |
+ +------------------------------+-------------------------------------+
+ | -> Offer | -> Offer |
+ | DF = None; DFT = | DFT = OPlow_int; MC = 0 |
+ | OPlow_int; MC = 0 | |
+ +------------------------------+-------------------------------------+
+
+ +--------------------------------------------------------------------+
+ | In Win State |
+ +----------------------+-----------------------+---------------------+
+ | Metric changes and | Timer Expires and | Path to RPA lost |
+ | is now worse | MC is less than | |
+ | | Robustness | |
+ +----------------------+-----------------------+---------------------+
+ | - | - | -> Offer |
+ | DFT = OPlow; MC = | Send Winner; DFT = | Set DF to None; |
+ | 0 | OPlow; MC = MC + 1 | DFT = OPlow; MC = |
+ | | | 0 |
+ +----------------------+-----------------------+---------------------+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 29]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ +--------------------------------------------------------------------+
+ | In Backoff State |
+ +----------------------+-----------------------+---------------------+
+ | Metric changes and | Timer Expires | Path to RPA lost |
+ | is now better than | | |
+ | Best | | |
+ +----------------------+-----------------------+---------------------+
+ | -> Win | -> Lose | -> Offer |
+ | Stop Timer | Send Pass; Set DF | Set DF to None; |
+ | | to stored Best | DFT = OPlow; MC = |
+ | | | 0 |
+ +----------------------+-----------------------+---------------------+
+
+3.5.4. Election Reliability Enhancements
+
+ For the correct operation of BIDIR-PIM, it is very important to avoid
+ situations where two routers consider themselves to be Designated
+ Forwarders for the same link. The two precautions below are not
+ required for correct operation but can help diagnose and correct
+ anomalies.
+
+3.5.5. Missing Pass
+
+ After a DF has been elected, a router whose metrics change to become
+ better than the DF will attempt to take over. If during the re-
+ election the acting DF has a condition that causes it to lose all of
+ the election messages (like a CPU overload), the new candidate will
+ transmit three offers and assume the role of the forwarder resulting
+ in two DFs on the link. This situation is pathological and should be
+ corrected by fixing the overloaded router. It is desirable that such
+ an event can be detected by a network administrator.
+
+ When a router becomes the DF for a link without receiving a Pass
+ message from the known old DF, the PIM neighbor information for the
+ old DF can be marked to this effect. Upon receiving the next PIM
+ Hello message from the old DF, the router can retransmit Winner
+ messages for all the RPAs for which it is acting as the DF. The
+ anomaly may also be logged by the router in a rate-limited manner to
+ alert the operator.
+
+3.5.6. Periodic Winner Announcement
+
+ An additional degree of safety can be achieved by having the DF for
+ each RPA periodically announce its status in a Winner message.
+ Transmission of the periodic Winner message can be restricted to
+ occur only for RPAs that have active groups, thus avoiding the
+ periodic control traffic in areas of the network without senders or
+ receivers for a particular RPA.
+
+
+
+Handley, et al. Standards Track [Page 30]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+3.6. Timers, Counters, and Constants
+
+ BIDIR-PIM maintains the following timers, as discussed in Section
+ 3.1. All timers are countdown timers - they are set to a value and
+ count down to zero, at which point they typically trigger an action.
+ Of course they can just as easily be implemented as count-up timers,
+ where the absolute expiry time is stored and compared against a real-
+ time clock, but the language in this specification assumes that they
+ count downwards to zero.
+
+ Per Rendezvous-Point Address (RPA):
+
+ Per interface (I):
+
+ DF Election Timer: DFT(RPA,I)
+
+ Per Group (G):
+
+ Upstream Join Timer: JT(G)
+
+ Per interface (I):
+
+ Join Expiry Timer: ET(G,I)
+
+ PrunePendingTimer: PPT(G,I)
+
+ When timers are started or restarted, they are set to default values.
+ This section summarizes those default values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 31]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Timer Name: DF Election Timer (DFT)
+
+ +-------------------+------------------------+-----------------------+
+ | Value Name | Value | Explanation |
+ +-------------------+------------------------+-----------------------+
+ | Offer_Period | 100 ms | Interval to wait |
+ | | | between repeated |
+ | | | Offer and Winner |
+ | | | messages. |
+ +-------------------+------------------------+-----------------------+
+ | Backoff_Period | 1 sec | Period that acting |
+ | | | DF waits between |
+ | | | receiving a better |
+ | | | Offer and sending |
+ | | | the Pass message |
+ | | | to transfer DF |
+ | | | responsibility. |
+ +-------------------+------------------------+-----------------------+
+ | OPlow | rand(0.5, 1) * | Range of actual |
+ | | Offer_Period | randomised value |
+ | | | used between |
+ | | | repeated messages. |
+ +-------------------+------------------------+-----------------------+
+ | OPhigh | Election_Robustness | Interval to wait |
+ | | * Offer_Period | in order to give a |
+ | | | chance to a router |
+ | | | with a better |
+ | | | Offer to become |
+ | | | the DF. |
+ +-------------------+------------------------+-----------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 32]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Timer Names: Join Expiry Timer (ET(G,I))
+
+ +---------------+---------------+------------------------------------+
+ |Value Name | Value | Explanation |
+ +---------------+---------------+------------------------------------+
+ |J/P HoldTime | from message | Hold Time from Join/Prune Message |
+ +---------------+---------------+------------------------------------+
+
+ Timer Names: PrunePendingTimer (PPT(G,I))
+
+ +-------------------------+-------------------+----------------------+
+ | Value Name | Value | Explanation |
+ +-------------------------+-------------------+----------------------+
+ | J/P Override Interval | Default: 3 secs | Short period after |
+ | | | a Join or Prune to |
+ | | | allow other |
+ | | | routers on the LAN |
+ | | | to override the |
+ | | | Join or Prune |
+ +-------------------------+-------------------+----------------------+
+
+ Note that the value of the J/P Override Interval is interface specific
+ and depends on both the Propagation_Delay and the Override_Interval
+ values that may change when Hello messages are received [4].
+
+ Timer Names: Upstream Join Timer (JT(G))
+
+ +------------+-------------------+-----------------------------------+
+ Value Name |Value Explanation |
+ +------------+-------------------+-----------------------------------+
+ t_periodic |Default: 60 secs Period between Join/Prune Messages |
+ +------------+-------------------+-----------------------------------+
+ t_suppressed |rand(1.1 * Suppression period when someone |
+ | |t_periodic, 1.4 * else sends a J/P message so we |
+ | |t_periodic) don't need to do so. |
+ +------------+-------------------+-----------------------------------+
+ t_override |rand(0, 0.9 * J/P Randomized delay to prevent |
+ | |Override Interval) response implosion when sending a |
+ | | Join message to override someone |
+ | | else's Prune message. |
+ +------------+-------------------+-----------------------------------+
+
+ For more information about these values, refer to the PIM-SM [4]
+ documentation.
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 33]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Constant Name: DF Election Robustness
+
+ +-------------------------+------------------+-----------------------+
+ | Constant Name | Value | Explanation |
+ +-------------------------+------------------+-----------------------+
+ | Election_Robustness | Default: 3 | Minimum number of |
+ | | | election messages |
+ | | | that must be lost |
+ | | | in order for |
+ | | | election to fail. |
+ +-------------------------+------------------+-----------------------+
+
+3.7. BIDIR-PIM Packet Formats
+
+ This section describes the details of the packet formats for BIDIR-
+ PIM control messages. BIDIR-PIM shares a number of control messages
+ in common with PIM-SM [4]. These include the Hello and Join/Prune
+ messages as well as the format for the Encoded-Unicast address. For
+ details on the format of these packets, please refer to the PIM-SM
+ documentation. Here we will only define the additional packets that
+ are introduced by BIDIR-PIM. These are the packets used in the DF
+ election process as well as the Bidirectional Capable PIM-Hello
+ option.
+
+3.7.1. DF Election Packet Formats
+
+ All PIM control messages have IP protocol number 103.
+
+ BIDIR-PIM messages are multicast with TTL 1 to the `ALL-PIM-ROUTERS'
+ group. The IPv4 `ALL-PIM-ROUTERS' group is `224.0.0.13'. The IPv6
+ `ALL-PIM-ROUTERS' group is `ff02::d'.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 34]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ All DF election BIDIR-PIM control messages share the common header
+ below:
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |PIM Ver| Type |Subtype| Rsvd | Checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | RP Address (Encoded-Unicast format) ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sender Metric Preference |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sender Metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ PIM Ver
+ PIM Version number is 2.
+
+ Type
+ All DF-Election PIM control messages share the PIM message Type of
+ 10.
+
+ Subtype
+ Subtypes for DF election messages are:
+
+ 1 = Offer
+ 2 = Winner
+ 3 = Backoff
+ 4 = Pass
+
+ Rsvd
+ Set to zero on transmission. Ignored on receipt.
+
+ Checksum
+ A standard checksum IP checksum is used, i.e., the 16-bit one's
+ complement of the one's complement sum of the entire PIM message.
+ For computing the checksum, the checksum field is zeroed.
+
+ RP Address
+ The bidirectional RPA for which the election is taking place. The
+ format is described in [4], Section 4.9.1.
+
+ Sender Metric Preference
+ Preference value assigned to the unicast routing protocol that the
+ message sender used to obtain the route to the RPA.
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 35]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ Sender Metric
+ The unicast routing table metric used by the message sender to
+ reach the RPA. The metric is in units applicable to the unicast
+ routing protocol used.
+
+ In addition to the fields defined above, the Backoff and Pass
+ messages have the extra fields described below.
+
+3.7.2. Backoff Message
+
+ The Backoff message uses the following fields in addition to the
+ common election message format described above.
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Offering Address (Encoded-Unicast format) ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Offering Metric Preference |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Offering Metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interval |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Offering Address
+ The address of the router that made the last (best) Offer. The
+ format is described in [4], Section 4.9.1.
+
+ Offering Metric Preference
+ Preference value assigned to the unicast routing protocol that the
+ offering router used to obtain the route to the RPA.
+
+ Offering Metric
+ The unicast routing table metric used by the offering router to
+ reach the RPA. The metric is in units applicable to the unicast
+ routing protocol used.
+
+ Interval
+ The backoff interval in milliseconds to be used by routers with
+ worse metrics than the offering router.
+
+3.7.3. Pass Message
+
+ The Pass message uses the following fields in addition to the common
+ election fields described above.
+
+
+
+
+
+Handley, et al. Standards Track [Page 36]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | New Winner Address (Encoded-Unicast format) ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | New Winner Metric Preference |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | New Winner Metric |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ New Winner Address
+ The address of the router that made the last (best) Offer. The
+ format is described in [4], Section 4.9.1.
+
+ New Winner Metric Preference
+ Preference value assigned to the unicast routing protocol that the
+ offering router used to obtain the route to the RPA.
+
+ New Winner Metric
+ The unicast routing table metric used by the offering router to
+ reach the RPA. The metric is in units applicable to the unicast
+ routing protocol used.
+
+3.7.4. Bidirectional Capable PIM-Hello Option
+
+ BIDIR-PIM introduces one new PIM-Hello option.
+
+ o OptionType 22: 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 = 22 | Length = 0 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4. RP Discovery
+
+ Routers discover that a range of multicast group addresses operates
+ in bidirectional mode, and that the address of the Rendezvous-Point
+ address (RPA) is serving the group range either through static
+ configuration or using an automatic RP discovery mechanism like the
+ PIM Bootstrap mechanism (BSR) [7] or Auto-RP.
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 37]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+5. Security Considerations
+
+ The IPsec [5] authentication header MAY be used to provide data
+ integrity protection and group-wise data origin authentication of
+ BIDIR-PIM protocol messages. Authentication of BIDIR-PIM messages
+ can protect against unwanted behaviour caused by unauthorized or
+ altered BIDIR-PIM messages.
+
+5.1. Attacks Based on Forged Messages
+
+ As in PIM Sparse-Mode, the extent of possible damage depends on the
+ type of counterfeit messages accepted. BIDIR-PIM only uses link-
+ local multicast messages sent to the ALL_PIM_ROUTERS address, hence
+ attacks can only be carried out by directly connected nodes, or with
+ the complicity of directly connected routers.
+
+ Some of the BIDIR-PIM protocol messages (Join/Prune and Hello) are
+ identical, both in format and functionality, to the respective
+ messages used in PIM-SM. Security considerations for these messages
+ are to be found in [4]. Other messages (DF-election messages) are
+ specific to BIDIR-PIM and will be discussed in the following
+ paragraphs.
+
+ By forging DF-election messages, an attacker can disrupt the election
+ of the Designated Forwarder on a link in two different ways:
+
+5.1.1. Election of an Incorrect DF
+
+ An attacker can force its election as DF by participating in a
+ regular election and advertising the best metric to reach the RPA.
+ An attacker can also try to force the election of another router as
+ DF by sending an Offer, Winner, or Pass message and impersonating
+ another router. In some cases (e.g., the Offer), multiple messages
+ might be needed to carry out an attack.
+
+ In the case of Offer or Winner messages, the attacker will have to
+ impersonate the node that it wants to have become the DF. In the
+ case of the Pass, it will have to impersonate the current DF. This
+ type of attack causes the wrong DF to be recorded in all nodes apart
+ from the one that is being impersonated. This node typically will be
+ able to detect the anomaly and, possibly, restart a new election.
+
+ A more sophisticated attacker might carry out a concurrent DoS attack
+ on the node being impersonated, so that it will not be able to detect
+ the forged packets and/or take countermeasures.
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 38]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ All attacks based on impersonation can be detected by all routers and
+ avoided if the source of DF-election messages can be authenticated.
+ When authentication is available, spoofed messages MUST be discarded
+ and a rate-limited warning message SHOULD be logged.
+
+ A more subtle attacker could use MAC-level addresses to partition the
+ set of recipients of DF-election messages and create an inconsistent
+ DF view on the link. For example, the attacker could use unicast MAC
+ addresses for its forged DF-election messages. To prevent this type
+ of attack, BIDIR-PIM routers SHOULD check the destination MAC address
+ of received DF-election messages. This however is ineffective on
+ links that do not support layer-2 multicast delivery.
+
+ Source authentication is also sufficient to prevent this kind of
+ attack.
+
+5.1.2. Preventing Election Convergence
+
+ By forging DF election messages, an attacker can prevent the election
+ from converging, thus disrupting the establishment of multicast
+ forwarding trees. There are many ways to achieve this. The simplest
+ is by sending an infinite sequence of Offer messages (the metric used
+ in the messages is not important).
+
+5.2. Non-Cryptographic Authentication Mechanisms
+
+ A BIDIR-PIM router SHOULD provide an option to limit the set of
+ neighbors from which it will accept Join/Prune, Assert, and DF-
+ election messages. Either static configuration of IP addresses or an
+ IPsec security association may be used. Furthermore, a PIM router
+ SHOULD NOT accept protocol messages from a router from which it has
+ not yet received a valid Hello message.
+
+5.2.1. Basic Access Control
+
+ In a PIM-SM domain, when all routers are trusted, it is possible to
+ implement a basic form of access control for both sources and
+ receivers: Receivers can be validated by the last-hop DR and sources
+ can be validated by the first-hop DR and/or the RP.
+
+ In BIDIR-PIM, this is generally feasible only for receivers, as
+ sources can send to the multicast group without the need for routers
+ to detect their activity and create source-specific state. However,
+ it is possible to modify the standard BIDIR-PIM behaviour, in a
+ backward compatible way, to allow per-source access control. The
+ tradeoff would be protocol simplicity, memory, and processing
+ requirements.
+
+
+
+
+Handley, et al. Standards Track [Page 39]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+5.3. Authentication Using IPsec
+
+ Just as with PIM-SM, the IPsec [5] transport mode using the
+ Authentication Header (AH) is the recommended method to prevent the
+ above attacks against BIDIR-PIM.
+
+ It is recommended that IPsec authentication be applied to all BIDIR-
+ PIM protocol messages. The specification on how this is done is
+ found in [4]. Specifically, the authentication of PIM-SM link-local
+ messages, described in [4], applies to all BIDIR-PIM messages as
+ well.
+
+5.4. Denial-of-Service Attacks
+
+ The denial-of-service attack based on forged Join messages, described
+ in [4], also applies to BIDIR-PIM.
+
+6. IANA Considerations
+
+ IANA has assigned OptionType 22 to the "Bidirectional Capable"
+ option.
+
+7. Acknowledgments
+
+ The bidirectional proposal in this document is heavily based on the
+ ideas and text presented by Estrin and Farinacci in [6]. The main
+ difference between the two proposals is in the method chosen for
+ upstream forwarding.
+
+ We would also like to thank John Zwiebel at Cisco, Deborah Estrin at
+ ISI/USC, Bill Fenner at AT&T Research, as well as Nidhi Bhaskar,
+ Yiqun Cai, Toerless Eckert, Apoorva Karan, Rajitha Sumanasekera, and
+ Beau Williamson at Cisco for their contributions and comments to this
+ document.
+
+8. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+ Thyagarajan, "Internet Group Management Protocol, Version 3", RFC
+ 3376, October 2002.
+
+ [3] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
+ Discovery (MLD) for IPv6", RFC 2710, October 1999.
+
+
+
+
+
+Handley, et al. Standards Track [Page 40]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+ [4] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol
+ Independent Multicast - Sparse Mode (PIM-SM): Protocol
+ Specification (Revised)", RFC 4601, August 2006.
+
+ [5] Kent, S. and R. Atkinson, "Security Architecture for the Internet
+ Protocol", RFC 2401, November 1998.
+
+9. Informative References
+
+ [6] Estrin, D. and D. Farinacci, "Bi-directional Shared Trees in
+ PIM-SM", Work in Progress, May 1999.
+
+ [7] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap
+ Router (BSR) Mechanism for PIM", Work in Progress, February 2007.
+
+ [8] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol
+ Extensions for BGP-4", RFC 4760, January 2007.
+
+Index
+
+ DF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5,18
+ Downstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ DownstreamJPState(G,I). . . . . . . . . . . . . . . . . . . . . . 10
+ ET(G,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33
+ ET(RPA,I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ I_am_DF(RPA,I). . . . . . . . . . . . . . . . . . . . . . . .10,12,14
+ J/P_HoldTime. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
+ J/P_Override_Interval . . . . . . . . . . . . . . . . . . . . . 16,33
+ JoinDesired(G). . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ joins(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ JT(*,G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ JT(G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9,33
+ local_receiver_include(G,I) . . . . . . . . . . . . . . . . . . . 10
+ MFIB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ NLT(N,I). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ Offer_Period. . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ olist(G). . . . . . . . . . . . . . . . . . . . . . . . . . .10,12,18
+ Bidirectional Capable OptionType . . . . . . . . . . . . . . . . 37
+ pim_include(G). . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ PPT(G,I). . . . . . . . . . . . . . . . . . . . . . . . . . . 9,14,33
+ RPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ RPF_interface(RPA). . . . . . . . . . . . . . . . . . . . . . . 10,12
+ RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ TIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ t_override. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
+ t_periodic. . . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
+ t_suppressed. . . . . . . . . . . . . . . . . . . . . . . . . . 17,33
+ Upstream. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+
+
+
+Handley, et al. Standards Track [Page 41]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+Authors' Addresses
+
+ Mark Handley
+ Computer Science Department
+ University College London
+ EMail: M.Handley@cs.ucl.ac.uk
+
+ Isidor Kouvelas
+ Cisco Systems
+ EMail: kouvelas@cisco.com
+
+ Tony Speakman
+ Cisco Systems
+ EMail: speakman@cisco.com
+
+ Lorenzo Vicisano
+ Digital Fountain
+ EMail: lorenzo@digitalfountain.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 42]
+
+RFC 5015 Bidirectional PIM October 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Handley, et al. Standards Track [Page 43]
+