Multicast protocols are required to implement data forwarding on a multicast network. Protocol Independent Multicast (PIM) is the most widely used multicast protocol that forwards data between devices in the same domain. Protocol Independent Multicast-Dense Mode (PIM-DM) is one type of PIM.
PIM-DM mainly uses the flood-prune mechanism to implement multicast data forwarding. Specifically, PIM-DM floods a multicast flow to all network segments and then prunes the network segments on which no receivers want the flow. PIM-DM periodically performs flood-prune operations to build up and maintain a shortest path tree (SPT) that connects a multicast source and multicast receivers. Then, PIM-DM forwards multicast data along this unidirectional loop-free SPT. PIM-DM applies to small-scale networks on which multicast receivers are densely located. PIM-DM is not a good choice for large-scale networks because the flood-prune period will be long on such a network. PIM-DM neither suits for networks with sparsely located receivers because excessive Prune messages will be generated on such a network.
This section provides basic PIM-DM concepts. See Figure 1.
PIM device
A multicast router that supports PIM is called a PIM device. A PIM-enabled interface on a PIM device is called a PIM interface.
SPT
A shortest path tree (SPT) is a multicast distribution tree (MDT) with the multicast source at the root and group members at leaves. SPTs can be used in PIM-DM, Protocol Independent Multicast-Sparse Mode (PIM-SM), and Protocol Independent Multicast-Source-Specific Multicast (PIM-SSM) scenarios.
By default, a PIM device permits other PIM control messages or multicast messages from a neighbor, irrespective of whether the PIM device has received Hello messages from the neighbor. However, if a PIM device has the neighbor check function enabled, the PIM device permits other PIM control messages or multicast messages from a neighbor only after the PIM device has received Hello messages from the neighbor.
PIM-DM assumes that at least one multicast group member exists on each network segment, and floods multicast data to all routers on the network. Therefore, all PIM devices on the network can receive multicast data.
After flooding multicast data, PIM-DM prunes network segments that have no multicast data receiver and retains only the network segments that have multicast data receivers. Only PIM devices that require multicast data can receive multicast data.
If a downstream device is in the prune state, the upstream device maintains a prune timer for this device. When the prune timer expires, the upstream device resumes data forwarding to the downstream device, which wastes network resources. To prevent this problem, the state-refresh function can be enabled on the upstream router. This function enables the upstream router to periodically send State-Refresh messages to refresh the status of the prune timers of downstream devices. Downstream devices that do not require multicast data remain in the prune state.
If a node on a pruned network segment has new group members, PIM-DM uses the graft mechanism to enable the node to immediately forward multicast data.
If there are multiple PIM devices on a network segment, the same multicast packets are sent repeatedly across the network segment. The Assert mechanism can be used to select a unique multicast data forwarder, preventing redundant multicast data forwarding.
The detailed PIM-DM implementation process is as follows:
This mechanism is the same as that in PIM-SM. For details about this mechanism, see PIM-SM.
The following example uses the network shown in Figure 2 to describe the flooding function. The source sends a data packet to DeviceA. Then DeviceA floods the packet to all its neighbors. DeviceB and DeviceC also exchange data packets with each other. To prevent data duplication, PIM-DM capable DeviceB uses the reverse path forwarding (RPF) mechanism to ensure that it only permits data packets from one neighbor, DeviceA or DeviceC. (For details about RPF check, see RPF Check.) Finally, data is flooded to DeviceB with receivers, as well as DeviceC without receivers. This process is called flooding.
The following example uses the network shown in Figure 3 to describe the prune function. DeviceC has no receivers, so it sends a Prune message upstream to DeviceA to instruct DeviceA to stop forwarding data to the interface connected to DeviceC. After receiving the Prune message, DeviceA stops forwarding data to the downstream interface connected to DeviceC. This process is called pruning.
Because a downstream interface on DeviceA is connected to DeviceB that has a receiver, DeviceA forwards multicast data to the downstream interface connected to DeviceB. In this manner, a unidirectional and loop-free SPT is set up from the source to User A.
The following example uses the network shown in Figure 3 to describe the state refresh function. After DeviceA prunes the network segment of DeviceC, DeviceA maintains a prune timer for DeviceC. When the prune timer expires, DeviceA resumes data forwarding to DeviceC. This results in a waste of network resources.
The state refresh function can prevent this problem and works as follows: DeviceA periodically floods State-Refresh messages to all its downstream interfaces to reset the prune timers of all the downstream devices.
The following example uses the network shown in Figure 4 to describe the graft function. After DeviceC in the pruned state receives an IGMP Report message from user B, DeviceC uses the graft function to implement fast data forwarding, without waiting a flood-prune period. The graft function works as follows:
DeviceC sends a Graft messages upstream to require DeviceA to restore the forwarding status of the downstream interface connected to DeviceC. After restoring the forwarding the status, DeviceA sends multicast data to DeviceC. Therefore, the graft function implements rapid data forwarding for devices in the pruned state.
Either of the following conditions indicates other multicast forwarders are present on the network segment:
A multicast packet fails the RPF check.
The interface that receives the multicast packet is a downstream interface in the (S, G) entry on the local router.
If other multicast forwarders are present on the network segment, the router starts the Assert mechanism.
The router sends an Assert message through the downstream interface. The downstream interface also receives an Assert message from a different multicast forwarder on the network segment. The destination address of the multicast packet in which the Assert message is encapsulated is 224.0.0.13. The source address of the packet is the downstream interface address. The TTL value of the packet is 1. The Assert message carries the route cost from the PIM device to the source or RP, priority of the used unicast routing protocol, and the group address.
The router that runs a higher priority unicast routing protocol wins.
If the routers have the same unicast routing protocol priority, the router with the smaller route cost to the source wins.
If the routers have the same priority and route cost, the router with the highest IP address for the downstream interface wins.
The router performs the following operations based on the Assert election result:
If the router wins the election, the downstream interface of the router is responsible for forwarding multicast packets on the network segment. The downstream interface is called an Assert winner.
If the router does not win the election, the downstream interface is prohibited from forwarding multicast packets and is deleted from the downstream interface list of the (S, G) entry. The downstream interface is called an Assert loser.
After Assert election is complete, only one upstream router that has a downstream interface exists on the network segment, and the downstream interface transmits only one copy of each multicast packet. The Assert winner then periodically sends Assert messages to maintain its status as the Assert winner. If the Assert loser does not receive any Assert messages from the Assert winner after the timer of the Assert loser expires, the loser re-adds downstream interfaces for multicast data forwarding.
The following example uses the network shown in Figure 5 to describe the assert function. DeviceB and DeviceC can receive multicast packets from the multicast source and the multicast packets that pass the RPF check. (S, G) entries can be created on DeviceB and DeviceC. Because the downstream interfaces of DeviceB and DeviceC are connected to the same network segment, DeviceB and DeviceC can both send multicast data to the network segment. The assert function is used to ensure that only one multicast data forwarder exists on the network segment. The assert process is as follows:
DeviceB receives a multicast packet from DeviceC through a downstream interface, but this packet fails the RPF check and is discarded by DeviceB. At the same time, DeviceB sends an Assert message to the network segment.
DeviceC compares its routing information with that carried in the Assert message sent by DeviceB. DeviceC is denied because the route cost from DeviceB to the source is lower. The downstream interface of DeviceC is prohibited from forwarding multicast packets and deleted from the downstream interface list of the (S, G) entry.
DeviceC receives a multicast packet from DeviceB through the network segment, but the packet fails the RPF check and therefore is discarded.