PIM Dense Mode
PIM-DM operates on the flood and prune model. Initially, multicast packets are flooded throughout the entire PIM routing domain with the PIM-DM protocol. Unnecessary delivery paths to leaf networks that are without any group memberships are then pruned from the forwarding tree using the PIM Join/Prune messages. This process has been illustrated in Figures 2-7 and 2-8 in Section 2.4.2.
One important difference of PIM from DVMRP is the need for the assert mechanism. Since PIM does not care about network topology, a multicast packet can be duplicated in a single link in the flooding stage. This is detected by PIM routers because the packet arrives on an outgoing interface, and then each router sends a PIM Assert message on the receiving interface. Each router receives Assert messages from other routers, and one of the routers is elected as the "winner" by comparing the preference or metric associated with the unicast routing protocol toward the source or comparing source IP addresses as a tie-breaker (the details of the election process is beyond the scope of this topic and is omitted). Once the winner is determined, only the winner router will forward packets for the source and group pair on to the link. The other router sends Join/Prune messages upward to prune the unnecessary path if necessary.
Figure 2-12 illustrates a situation when the PIM assert mechanism is necessary to eliminate packet duplication. In this figure, routers R1 and R2 both receive a multicast packet from source S. Both R1 and R2 forward the packet downstream to host H, resulting in two copies of the packet appearing on network N2.
FIGURE 2-12
FIGURE 2-13
Both routers detect this packet duplication condition from the multicast packet that arrives on the outgoing interface that was used for transmission of the same packet previously. The two routers then enter the election process by sending out PIM Assert messages as shown in Figure 2-13.
In this example, the PIM assert procedure elects router R1 as the winner. From then on, R1 has the responsibility of forwarding packets from S to the multicast group on N2.
PIM Sparse Mode
PIM-SM operates on the explicit-join model. In PIM-SM, a core router is called a Rendezvous Point (RP). When a router recognizes a host joining a multicast group, it sends a PIM Join/Prune message containing the multicast group address toward the RP for the group address. The Join/Prune message is forwarded to the RP based on the RPF with regard to the RP’s address, making or updating status for the group in each router.
This process will establish a packet distribution tree (called the shared tree) for the group from the RP to leaf networks. It is called "shared" because the same tree is used for all sources to the group.
When a multicast source sends a multicast packet to a particular group, the first hop router encapsulates the packets inside a PIM Register message, and forwards the Register message to the RP through unicast routing. The RP then decapsulates the original multicast packet and distributes it along the shared tree.
Figure 2-14 shows the packet format of a PIM Register message.
Version contains the PIM version number 2.
FIGURE 2-14
Type specifies the type of PIM message. For the PIM Register message, the Type field has the value of 1.
Reserved and Reserved2 must be set to zero by the sender and ignored by the receiver.
Checksum the standard IP checksum covering the entire PIM message except the Multicast Data Packet section of the Register message. The checksum calculation is different depending on whether the PIM message is carried over IPv4 or IPv6. Details of the IPv6 case will be described in Section 2.4.4.
B called the Border bit. The definition and usage of this bit are beyond the scope of this topic.
N called the Null-Register bit. A Register message with this bit on is called a Null-Register message. Unlike normal Register messages, a Null-Register message is exchanged just for a keep alive purpose between the first hop router and the RP, and does not encapsulate a multicast packet.
Multicast data packet holds the original multicast packet sent by the source.
Figure 2-15 illustrates an example of the multicast packet distribution based on the PIM-SM protocol.
In this example, when multicast source S sends out a multicast packet to a particular group, the first hop router R1 encapsulates the packet into a PIM Register message and forwards it to the RP as a unicast packet. The RP decapsulates the Register message and forwards the original multicast packet along the shared tree to the host members residing on the leaf networks.
IPv6 Specific Issues about PIM
Whereas the PIM base protocol is designed to be agnostic about IP versions, there were several issues specific to IPv6 found through implementation and operational experiences. Those issues were then addressed in later versions of the protocol specification. The following summarizes such issues.
Upstream Determination
PIM "neighbors," that is, PIM routers that share a single link, identify each other by periodically exchanging PIM Hello messages. The source address of the Hello message is used as the identifier of the sender. In the case of IPv6, this address is always a link-local unicast address because the protocol specification requires that most PIM messages including Hello have a link-local source address.
FIGURE 2-15
FIGURE 2-16
A PIM router also identifies the neighbor’s address that is the upstream router in RPF using the unicast routing protocol. Those two addresses are usually the same for the same neighbor. Even though IPv6 allows a node’s interface to have multiple addresses, all IPv6 interior routing protocols use link-local addresses for exchanging routes (see, for example, Section 1.4.2), and an interface typically has only one link-local address.
Unfortunately, however, this is not always the case. Figure 2-16 shows one common exceptional case. In this example, the RP’s address shares a subnet prefix (2001 :db8::/64) with downstream routers.
Assume the RP’s link-local address in this link is fe80::1, and a downstream router A tries to send a PIM Join/Prune message toward the RP. The RPF upstream is the RP itself in this case, and the upstream address is an RP’s global address, 2 0 01 :db8::1. For sending a PIM Join/Prune message, router A needs to include the link-local address for the upstream router in the message. However, the downstream router cannot know it is fe80::1, because there is no explicit information that combines the link-local and global addresses.
To address this problem, the IETF decided to introduce an additional option to the PIM Hello message, called the (Interface) Address List option. This option simply lists additional addresses other than the link-local address that the router sending the Hello message assigns to the outgoing interface. In the above example, this option would contain 2 001 :db8::1. Since the source address of the Hello message is the link-local address (fe8 0::1), router A can now identify the link-local address of the upstream router, i.e., the RP.
This issue was found in early experiments with KAME’s IPv6 multicast routing operation, and the Interface Address List option was first introduced as an experimental option specific to KAME’s implementation. It has then been incorporated into the protocol specification, and an official option number (24) is now assigned.
The PIM implementation described in this topic uses the old, experimental option type. Later versions of the implementation supports the official type number as well.
Checksum Calculation
Each PIM message has a common header part, which contains a checksum field. In a former version of the protocol specification, the checksum was calculated through the message data only, that is, without a pseudo-IP header. This is reasonable for IPv4, because IPv4 has an IP layer checksum. Even though the IPv4 header of a PIM message is corrupted, the corruption is detected in the IP layer checksum validation of the receiving node and the message is discarded.
Therefore, recent versions of the specification state that the PIM checksum for IPv6 uses a pseudo-IPv6 header like the checksum for other transport layer protocols over IPv6.This issue was first identified through KAME’s implementation experience of PIM for IPv6 and was addressed in the implementation. The change has then been incorporated into the standard specification.
IPv6 Multicast Future—MLDv2 and SSM
A challenging task in widely deploying PIM-SM is the issue of how to distribute the RP address throughout the PIM routing domain reliably and in time. Manual configuration at each router has the obvious scalability problem.
The IETF has defined a standard RP address distribution mechanism [PIMSM-BSR], but the method is based on flooding and still has limitation in scalability. Another standard that is specific to IPv6 [RFC3956] eliminates the scalability issue with the general distribution mechanism by embedding the address of the RP into the corresponding IPv6 multicast address. But it causes another limitation in that the RP address must be in a specific form to be embedded in the multicast address.
Meanwhile, applications such as Internet TV and Internet Radio based on IP multicasting have the characteristic of having a single packet source. In such cases, if a single distribution tree can be established from the source to the leaf nodes, an RP is not necessary in the first place.
Revised multicast specifications can provide such a possibility. For example, MLDv2, a revised version of MLD, allows a host to specify both the source for a particular multicast group as well as the group itself. Source Specific Multicast (SSM) [RFC4607] is a new notion in multicast routing that allows routers to establish a distribution tree from a single source only. PIM-SM can be easily adapted to SSM; for example, when a router receives a multicast group join request with a source address via MLDv2, the router can simply send the PIM Join/Prune message toward the source directly, instead of toward the RP.
The coverage of these new specifications are beyond the scope of this topic; readers are encouraged to investigate these standards on their own merits.
