PIM

Introduction

IPv4 Protocol-Independent Multicast (PIM) can forward IPv4 multicast packets with a unicast protocol.

IPv4 PIM efficiently routes IPv4 multicast traffic for groups that span wide area (and inter-domain) networks.

It works with all existing unicast routing protocols.

IPv4 PIM supports these modes:

Dense Mode (PIM DM)
Sparse Mode (PIM SM)
Source-Specific Multicast Mode(PIM SSM)

Notes:

You can enable only one mode of IPv4 PIM at a time.
Due to a Gaia Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. OS limitation, a maximum of 31 PIM interfaces can be configured.

If more interface are configured, IPv4 PIM runs only on the first 31 interfaces.
You must configure an Access Control rule Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. that accepts IPv4 PIM traffic.

IPv4 PIM Dense Mode (DM)

This mode is most useful when:

Senders and receivers are in close proximity to one another.
There are few senders and many receivers.
The volume of multicast traffic is high.
The stream of multicast traffic is constant.

PIM Dense Mode State Refresh

The IPv4 PIM Dense Mode State Refresh option can be used in conjunction with dense mode to eliminate the periodic flood-and-prune of multicast data with no active receivers. All PIM routers must have State Refresh enabled to take advantage of this feature.

The IPv4 PIM Dense Mode builds multicast distribution trees that operate on a flood and prune principle. Multicast packets from a source are flooded throughout a PIM dense mode network. PIM routers that receive multicast packets and have no directly connected multicast group members or PIM neighbors send a prune message back up the source-based distribution tree toward the source of the packets. As a result, subsequent multicast packets are not flooded to pruned branches of the distribution tree. However, the pruned state in PIM dense mode times out approximately every three minutes and the entire PIM dense mode network is reflooded with multicast packets and prune messages. This reflooding of unwanted traffic throughout the PIM dense mode network consumes network bandwidth unnecessarily.

Use the IPv4 PIM Dense Mode State Refresh feature to keep the pruned state in PIM dense mode from timing out by periodically forwarding a control message down the distribution tree. The control message refreshes the prune state on the outgoing interfaces of each router in the tree. This saves network bandwidth by greatly reducing the reflooding of unwanted multicast traffic to pruned branches of the PIM dense mode network.

Note - You must enable state refresh on all the IPv4 PIM routers in the distribution tree to take advantage of this feature.

IPv4 PIM Sparse Mode (SM)

This mode is most useful when:

There are few IPv4 receivers in a group.
IPv4 senders and receivers are separated by WAN links.
The type of IPv4 traffic is intermittent.

IPv4 PIM Source-Specific Multicast (SSM) Mode

This mode is most useful when:

Most of IPv4 multicast traffic is from well-known sources.
It is desirable to avoid the overhead of shared tree and rendezvous point processing associated with sparse mode.

IPv4 PIM SSM is a version of IPv4 PIM Sparse Mode. It is used in conjunction with IGMP v3 to request or block multicast traffic from specific sources. For example, when a host requests traffic for a multicast group from a specific source, SSM sends PIM join/prune messages towards the source.

The multicast group range 232.0.0.0/8 is reserved for SSM. When SSM is enabled, Sparse Mode accepts only IGMP v3 reports for groups that fall within this range. Sparse Mode ignores IGMP v1 and IGMP v2 reports in this range.

In addition, only shortest-path-tree (SPT) join/prune messages for these groups are accepted from neighboring routers. All other multicast groups are processed as in native Sparse Mode.

SSM does not need a Rendezvous Point (RP). The presence of an RP for any of the SSM groups does not have any influence on the processing of join/prune messages.