Understanding Protocol Independent Multicast (PIM)
Fundamentals of IGMP Version 1, IGMP Version 2, and Reverse Path Forwarding
Before diving into the intricacies of the PIM protocol, you need to understand the concept behind the Internet Group Management Protocol (IGMP) and reverse path forwarding (RPF).
IGMP is the protocol that functions between the host, also called the receiver, and the multicast-enabled router. In short, IGMP allows the router to know that a host is interested in receiving multicast traffic for a specific group. IGMP is enabled on the router whenever PIM is enabled. IGMP messages are sent with a TTL of 1; therefore, IGMP packets are constrained to the local network only.
IGMP Version 1
In IGMP version 1 (defined in RFC 1112), the routers sends IGMP queries to the “all-hosts” multicast address of 184.108.40.206 to solicit multicast groups with active multicast receivers. The multicast receivers also can send IGMP reports to the router to notify it that they are interested in receiving a particular multicast stream. Hosts can send the report asynchron-ously or in response to the IGMP queries sent by the router. If more than one multicast receiver exists for the same multicast group, only one of these hosts sends an IGMP report message; the other hosts suppresses theirs.
For example, in Figure 12-1, the router R1 sends periodic IGMP queries to the 220.127.116.11 address. Only one member per group per subnet sends the IGMP report message to the router—in this case, H2—while the other hosts H1 and H3 suppress theirs.
In IGMP version 1, there is no election of an IGMP querier. If more than one router on the segment exists, all the routers send periodic IGMP queries. IGMP version 1 has no special mechanism by which the hosts can leave the group. If the hosts are no longer interested in receiving multicast packets for a particular group, they simply do not reply to the IGMP query packets sent from the router. The router continues sending query packets. If the router does not hear a response in three IGMP queries, the group times out and the router stops sending multicast packets on the segment for the group. If the host later wants to receive multicast packets after the timeout period, the host simply sends a new IGMP join to the router, and the router begins to forward the multicast packet again.
IGMP Version 2
IGMP version 2 (defined in RFC 2236) introduces several changes to make IGMP more efficient in joining and leaving the group. Some of the important changes are listed here:
- Querier election mechanism— On a multiaccess network, an IGMP querier router is elected based on the IP address. Therefore, only one router per segment sends IGMP queries.
- Leave group message— The host sends a leave message if it is no longer interested in a multicast group. This reduces leave latency when compared to version 1.
- Group-specific query— The router sends a group-specific query before it times out the group. This ensures that there are no more hosts left on the segment that might still be interested in receiving the multicast group.
The IGMP join mechanism in version 2 is the same as in version 1. The leave mechanism is a little different, though. In version 2, when a host wants to leave the group, it sends an IGMP leave message. When the router receives the leave message, it sends an IGMP query packet to see if any more hosts are interested in the group. If hosts still are interested in the group, they send an IGMP join message to override the IGMP leave message; otherwise, the router assumes that there are no more hosts interested in the multicast group, and the group times out.
Figure 12-2 illustrates that host H2 wants to leave the multicast group because it sends an IGMP leave message. When Router R1 receives the leave message, it immediately sends out an IGMP query to make sure that no other hosts are interested in the group. In this case, host H1 is still in the group, and H1 overrides the IGMP leave message by sending an IGMP report message. In this scenario, the group remains active and the router keeps forwarding multicast packets on the segment.
Figure 12-3 depicts the same scenario as in the Figure 12-2. Router R1 sends out an IGMP query after it receives the IGMP leave from the host H2. Because both hosts H1 and H3 are not interested in the group, they simply ignore the IGMP query message sent by the router. When the router doesn’t hear any response from its IGMP query, it times out the group on the segment, and Router R1 stops sending multicast packets for that group.
Multicast Forwarding (Reverse Path Forwarding)
You must understand the way the multicast forwarding mechanism works before understanding how PIM comes into play. Multicast routing is backward from unicast routing. Unicast routing is concerned about where the packet is going, whereas in multicast routing, the concern is where the packets are coming from. Multicast routing uses the concept of reverse path forwarding (RPF) to determine whether a forwarding loop exists. In short, RPF allows the router to forward a multicast packet only if the packet is received on the upstream interface to the source. To be specific, if the router receives a multicast packet on an interface, the unicast routing table is used to check the source address of the multicast packet. If the packet arrives on the interface specified in the unicast routing table for the source address, the RPF check succeeds; otherwise, the RPF check fails and the multicast packets are silently dropped.
In Figure 12-4, the router receives a multicast packet from interface S1, and the source is 192.168.3.1. The router checks its unicast routing table for address 192.168.3.1. The unicast routing table indicates that it learned about network 192.168.3.0/24 from interface S1. The RPF check, in this case, succeeds because the multicast interface and the unicast routing table are congruent. When the RPF check succeeds, the router forwards the multicast packets to its outgoing interfaces—in this case, interfaces E0 and S2. The outgoing interfaces are interfaces that meet any of the following conditions:
- A PIM neighbor is heard on the interface.
- A host on this interface has joined the group.
- The interface has been manually configured to join the group.
In Figure 12-5, the router receives multicast packets from interface S0 with the source address of 192.168.3.1. The router checks its unicast routing table, as in the previous example and finds out that the unicast routing table knows about network 192.168.3.0/24 from interface S1. The unicast routing table, in this case, is not congruent with the interface that the multicast packets are coming from. Therefore, the RPF check fails and the multicast packets are dropped.
PIM Dense Mode
PIM has two modes of operation—dense mode and sparse mode. Dense mode uses a flood-and-prune mechanism to forward multicast packets. The router assumes that every multicast interface is interested in multicast packets, unless it is told otherwise. The router first forwards multicast packets to all the interfaces. Segments that don’t want multicast packets receive prune messages from the neighboring routers, and the branch is pruned.
When the router is first configured for multicast, the router sends periodic PIM query packets to the multicast address of 18.104.22.168 (all routers on this subnet address) to discover its PIM neighbors. The PIM query packets are sent out the interfaces that are configured for PIM. PIM neighbors are established across an interface when PIM queries are received on that interface.
PIM dense mode floods multicast packets on its out interface list (also known as an oilist). PIM dense mode puts an interface in its oilist if the following conditions are true:
- The interface has an established PIM neighbor.
- The interface has hosts joining the multicast group through IGMP.
- The interface has been manually configured to join the group through the ip igmp join-group command.
When a router running PIM dense mode first receives multicast packets, it floods the multicast packets to all interfaces listed in the oilist. The router stops forwarding multicast packets on an interface if it receives a prune packet from its neighbor.
In Figure 12-6, the Router R1 receives incoming multicast packets on interface S0. As R1 is running dense mode, it floods the multicast packets to all its oilist interfaces, E0 and S1. Because Router R2 doesn’t have any hosts interested in multicast traffic, it sends a PIM prune message toward R1. When R1 receives the PIM prune, it waits for three seconds before it stops forwarding multicast packets for the group to interface E0. This three-second delay allows other routers on the segment to override the prune with a PIM join.
When the interface has been pruned, the router stops forwarding multicast packets for the group to the interface. In Figure 12-6, suppose that Router R2 now has a host that wants to receive multicast packets on interface E1. Router R2 sends a PIM graft packet to Router R1. When Router R1 receives the PIM graft message, it puts its interface E0 into a forwarding state, and multicast traffic flows to Router R2.
If there are two routers on the same LAN interface and both routers have a connection to the source of the multicast stream, both routers potentially could forward multicast packets and cause duplicate packets on the LAN interface. PIM dense mode has an assert mechanism to avoid such scenarios. Figure 12-7 illustrates the PIM assert mechanism.
In the absence of the PIM assert process, both routers forward multicast packets onto interface E0. This causes duplicate packets on the LAN interface. With the assert mech-anism, both routers send the PIM assert packet with the unicast routing distance and metric to the source of the multicast stream. The router with the best unicast route to the source wins and starts forwarding the multicast packets. The router that loses the assert battle prunes the outgoing interface. If a tie is on the unicast routing metric, the router with the highest IP address wins the assert. This way, only one router is actively forwarding the multicast traffic.
PIM Sparse Mode
PIM sparse mode works the opposite way of dense mode. PIM dense mode assumes that all the multicast interfaces are interested in multicast packets, unless being told otherwise. In PIM sparse mode, the router assumes that none of the multicast inter-faces is interested in receiving multicast packets, unless a PIM join message is received on the interface. PIM sparse mode is more scalable than PIM dense mode, but the concept is more complex. PIM sparse mode uses the concept of a rendezvous point (RP). The RP is where the sender and the receivers meet first before the shortest-path tree is established. The shortest-path tree is the shortest path between the multi-cast sender and the receiver. For a particular multicast group, only one RP is chosen. The selection of the RP is done by either static configuration or dynamically learned through the Auto-RP mechanism.
PIM sparse mode discovers its neighbor the same way that PIM dense mode works. The PIM routers send out PIM query packets to discover PIM neighbors on the link. In PIM sparse mode, the highest IP address on a LAN segment is elected the designated router. This desig-nated router is used to send PIM joins to the RP for the segment.
In sparse mode, multicast flow has two parts:
- Receivers send PIM joins to the RP.
- The source sends PIM registers to the RP.
In the PIM sparse mode join mechanism, the router that is closest to the receiving station sends the PIM join message to the RP. If more than one router exists on the LAN segment, the PIM DR sends the join to the RP. The PIM joins are then sent hop by hop toward the RP. Figure 12-8 illustrates the PIM sparse mode join mechanism.
In Figure 12-8, the PC sends IGMP joins to its Ethernet interface. Router R2 is the DR because it has a higher IP address on interface E1. Router R2 sends PIM joins toward the RP, so R2 sends PIM joins to Router R1. Router R1 sends the PIM joins toward the RP. Therefore, the PIM joins are sent hop by hop from the leaf router closest to the receiver, all the way to the RP. The leaf router is defined as the outermost edge router that has only receivers connected.
- The second part of the sparse mode operation is the register process, which can be dissected into the following sequence of events:
- The sparse mode register messages are sent by the router that is closest to the sender of the multicast stream. If more than one router exists on the LAN segment, the PIM DR is responsible for sending the PIM register message to the RP.
- When the sender begins sourcing a multicast stream, the first-hop router encapsulates the multicast packets into the PIM register messages and unicasts them to the RP.
- When the RP receives the register message, it first de-encapsulates the multicast packet that it contains.
- The RP then forwards the multicast packet toward any existing receivers and also sends a PIM join message toward the multicast source.
- When the PIM join reaches the first-hop router to the source, the first-hop router starts forwarding native multicast traffic toward the RP, while still sending PIM register messages to the RP.
- When the RP receives two copies of a multicast packet, one from the register message and the other from the native multicast path, the RP sends a register stop message to the first-hop router.
- When the first-hop router receives the register stop message, it stops encapsulating the multicast traffic into the register message and forwards it natively to the RP.
Figure 12-9 illustrates the first part of the sparse mode register process, which corresponds to events 1 through 4 in the previous discussion. (The PC sources the multicast stream, and Router R1 encapsulates the multicast packets into PIM register messages and unicasts the packets to the RP.) When the RP receives the register packets, it de-encapsulates the multicast packets and forwards them downstream to the receivers. At the same time, the RP sends PIM joins toward the source. In this case, the RP sends joins to Router R2, and Router R2 sends PIM joins to R1.
Figure 12-10 is the continuation of the PIM sparse mode register process. When Router R1 receives the join from the RP, R1 begins to send the multicast traffic toward the RP. The register messages from R1 are still forwarded. The RP then receives two copies of the multicast packet, one from the register message and the other from the native multi-cast flow. When the RP sees two copies of the multicast packet, it sends a register stop message to the first-hop router—in this case, Router R1. When R1 receives the register stop message, it stops encapsulating the multicast packets into register messages, and the traffic now flows natively from R1 to R2 and then to the RP. The RP then forwards the multicast stream to its downstream neighbors.
The sparse-mode pruning mechanism is the same as the one used in dense mode. If the router is not interested in the multicast traffic, it sends a PIM prune message to the upstream neighbor toward the source. For a more detailed description on PIM operation, refer to Beau Williamson’s book Developing IP Multicast Networks, Volume 1
IGMP and PIM Packet Format
The packet format of IGMP and PIM is useful in understanding the operation of PIM. Understanding the packet format also helps you in troubleshooting PIM problems, in case sniffer traces need to be looked at. This section covers the important packet format of IMGP and PIM.
IGMP Packet Format
IGMP messages are always sent with a TTL of 1 and are IP-encapsulated with a protocol number of 2. Figure 12-11 shows the IGMP version 2 packet format. The IGMP version 1 packet format is a little different than the format of version 2. The IGMP version 1 packet splits the Type field in version 2 into two parts, to include both the version number and the type.
The Type field indicates different types of IGMP packets:
- Type 11 is the IGMP membership query.
- Type 12 is the IGMP version 1 membership report.
- Type 16 is the IGMP version 2 membership report.
- Type 17 indicates the IGMP version 2 leave group.
The types listed are the most important ones. You can find other Type field information in RFC 2236.
The Maximum Response Time field is used only in membership query messages. It spec-ifies the maximum time in units of 1/10 of a second that a host might wait to respond to a query message.
The Checksum field is the checksum of the IGMP message to verify packet integrity.
The Group Address field contains the multicast group that the receiver is interested in receiving. When the general IGMP query is sent, this group address field is set to 0.
PIM Packet/Message Formats
PIM version 1 packets are encapsulated in IGMP Type 14 packets. PIM version 2 uses its own protocol number of 103 and is not encapsulated into IGMP. PIM version 2 packets are sent to the multicast address 22.214.171.124. Figure 12-12 shows the format for PIM hello messages.
The PIM hello message belongs to the PIM Type 0 packet. Option Type is always set to 1. The PIM hello packets are used to establish the PIM neighbor relationship.
Figure 12-13 shows the PIM register message for PIM sparse mode.
The PIM register message belongs to PIM Type 1 packets. The DR encapsulates the multi-cast packet into the register packet and sends it to the RP. From the packet format, the B bit is set to 1 if the router is a PIM multicast border router for the source. The B bit is set to 0 if the sending router is a DR for a directly connected source. The N bit is the null register, and it is used to prevent unnecessary bursts of traffic being sent to the RP between receiving REGISTER STOP messages. Figure 12-14 shows the REGISTER STOP message format.
The encoded group address contains the groups of multicast addresses being encapsulated into the REGISTER message. The Encoded unicast-source address contains the unicast address of the source of the multicast stream. From the previous discussion, the REGISTER STOP message is sent to the router that sends the REGISTER message, to indicate that a native multicast stream has been received and that the DR can stop sending the REGISTER packets.
Figure 12-15 illustrates the PIM JOIN/PRUNE message that is used in both dense and sparse modes.
In the PIM JOIN/PRUNE packet, the encoded unicast upstream neighbor address is the IP address of the RPF neighbor that performs the join or prune. The number of groups contains the number of multicast group sets in the message. Each set consists of an encoded multi-cast group address, followed by a list of encoded source addresses to join or prune.
Figure 12-16 shows the format for the PIM assert message. The assert mechanism allows the router to select an active router to forward the multicast packets to avoid packet duplication on the LAN.
The encoded group address is the multicast group address. The encoded unicast source address is the IP address of the source of the multicast stream. The metric is the routing metric to the source of the multicast stream associated with the routing protocol used. The metric could be hop count if the routing protocol used is RIP. The R bit is the RPT bit and is set to 1 if the multicast packet that triggered the assert packet is routed down the shared tree. The R bit is set to 0 if the multicast packet is routed down the shortest-path tree.