Chapter 1
Implementing IPv6 Multicast
PIM uses both source trees and RP-rooted shared trees to forward datagrams; the RPF check is
performed differently for each, as follows:
•
•
Sparse-mode PIM uses the RPF lookup function to determine where it needs to send joins and prunes.
(S, G) joins (which are source-tree states) are sent toward the source. (*, G) joins (which are shared-tree
states) are sent toward the RP.
Routable Address Hello Option
When an IPv6 interior gateway protocol is used to build the unicast routing table, the procedure to detect
the upstream switch address assumes the address of a PIM neighbor is always same as the address of the
next-hop switch, as long as they refer to the same switch. However, it may not be the case when a switch
has multiple addresses on a link.
Two typical situations can lead to this situation for IPv6. The first situation can occur when the unicast
routing table is not built by an IPv6 interior gateway protocol such as multicast BGP. The second
situation occurs when the address of an RP shares a subnet prefix with downstream switches (note that
the RP switch address has to be domain-wide and therefore cannot be a link-local address).
The routable address hello option allows the PIM protocol to avoid such situations by adding a PIM hello
message option that includes all the addresses on the interface on which the PIM hello message is
advertised. When a PIM switch finds an upstream switch for some address, the result of RPF calculation
is compared with the addresses in this option, in addition to the PIM neighbor's address itself. Because
this option includes all the possible addresses of a PIM switch on that link, it always includes the RPF
calculation result if it refers to the PIM switch supporting this option.
Because of size restrictions on PIM messages and the requirement that a routable address hello option
fits within a single PIM hello message, a limit of 16 addresses can be configured on the interface.
Bidirectional PIM
Bidirectional PIM allows multicast switches to keep reduced state information, as compared with
unidirectional shared trees in PIM-SM. Bidirectional shared trees convey data from sources to the
rendezvous point address (RPA) and distribute them from the RPA to the receivers. Unlike PIM-SM,
bidirectional PIM does not switch over to the source tree, and there is no register encapsulation of data
from the source to the RP.
A single designated forwarder (DF) exists for each RPA on every link within a bidirectional PIM domain
(including multiaccess and point-to-point links). The only exception is the RPL on which no DF exists.
The DF is the switch on the link with the best route to the RPA, which is determined by comparing
MRIB-provided metrics. A DF for a given RPA forwards downstream traffic onto its link and forwards
upstream traffic from its link toward the rendezvous point link (RPL). The DF performs this function for
all bidirectional groups that map to the RPA. The DF on a link is also responsible for processing Join
messages from downstream switches on the link as well as ensuring that packets are forwarded to local
receivers discovered through a local membership mechanism such as MLD.
Bidirectional PIM offers advantages when there are many moderate or low-rate sources. However, the
bidirectional shared trees may have worse delay characteristics than do the source trees built in PIM-SM
(depending on the topology).
Only static configuration of bidirectional RPs is supported in IPv6.
OL-25303-03
If a PIM switch has source-tree state (that is, an (S, G) entry is present in the multicast routing table),
the switch performs the RPF check against the IPv6 address of the source of the multicast packet.
If a PIM switch has shared-tree state (and no explicit source-tree state), it performs the RPF check
on the RP's address (which is known when members join the group).
Information About Implementing IPv6 Multicast
Catalyst 3750-X and 3560-X Switch Software Configuration Guide
1-9