Sources Sending Packets to the Rendezvous Point
PIM-SM uses a two-step process to initially deliver multicast packets from a particular source to
the hosts wanting to receive packets. Later, the process is improved beyond these initial steps. The
steps for the initial forwarding of multicasts with PIM-SM are as follows:
1. Sources send the packets to a router called the rendezvous point (RP).
2. The RP sends the multicast packets to all routers/hosts that have registered to receive packets
for that group. This process uses a shared tree.
NOTE In addition to these two initial steps, routers with local hosts that have sent an IGMP
Join for a group can go a step further, joining the source-specific tree for a particular (S,G) SPT.
This section describes the first of these two steps, in which the source sends packets to the RP. To
make that happen, the router connected to the same subnet as the source host must register with
the RP. The RP accepts the registration only if the RP knows of any routers or hosts that need to
receive a copy of those multicasts.
Figure 17-13 shows an example of the registration process in which the RP knows that no hosts
currently want the IP multicasts sent to group 228.8.8.8—no matter which source is sending them.
The configuration for this example is simple, with all the routers configured with the global
command ip multicast-routing and the interface command ip pim sparse-mode on all the
interfaces. Also, all routers have statically configured R3 as the RP by using the global command
ip pim rp-address 10.1.10.3. Usually, a loopback interface address is used as an RP address. The
loopback network 10.1.10.3/32 of R3 is advertised in the unicast routing protocol so that all the
routers know how to reach the RP.
Sparse-Mode Routing Protocols 611
Figure 17-13 Source Registration Process when RP Has Not Received a Request for the Group from Any
PIM-SM Router
The following three steps, referenced in Figure 17-13, describe the sequence of events for the
Source Registration process when the RP has not received a request for the group from any
PIM-SM router because no host has yet joined the group.
1. Host S1 begins sending multicasts to 228.8.8.8, and R1 receives those multicasts because it
connects to the same LAN.
2. R1 reacts by sending unicast PIM Register messages to the RP. The Register messages are
unicasts sent to the RP IP address, 10.1.10.3 in this case.
3. R3 sends unicast Register-Stop messages back to R1 because R3 knows that it does not have
any need to forward packets sent to 228.8.8.8.
In this example, the router near the source (R1) is attempting to register with the RP, but the RP
tells R1 not to bother any more, because no one wants those multicast messages. R1 has not
forwarded any of the native multicast messages at this point, in keeping with the PIM-SM strategy
of not forwarding multicasts until a host has asked for them. However, the PIM Register message
shown in Figure 17-13 encapsulates the first multicast packet. As will be seen in Figure 17-14, the
encapsulated packet would be forwarded by the RP had any senders been interested in receiving
the packets sent to that multicast group.
The source host may keep sending multicasts, so R1 needs to keep trying to register with the
RP in case some host finally asks to receive the packets. So, when R1 receives the Register-Stop
messages, it starts a 1-minute Register-Suppression timer. 5 seconds before the timer expires,
R1
R4 R5
R2 R3
.10
E0 .1
.1
S0
S1
.2
S0
.2
S1
.3
.5
.5
.1 .3
S1
S0
10.1.4.0/24 10.1.5.0/24
10.1.6.0/24
S0
S1
.4
.4
S0
S1
10.1.1.0/24
10.1.2.0/24 10.1.3.0/24
PIM Register
Unicast Register-Stop
RP
10.1.10.3
3
1
2
Unicast Register
Message
Multicast Packet
(10.1.1.10, 228.8.8.8)
Multicast Traffic
(10.1.1.10, 228.8.8.8)
S1
R1 sends another Register message with a flag set, called the Null-Register bit, without any
encapsulated multicast packets. As a result of this additional Register message, one of two things
will happen:
■ If the RP still knows of no hosts that want to receive these multicast packets, it sends another
Register-Stop message to R1, and R1 resets its Register-Suppression timer.
■ If the RP now knows of at least one router/host that needs to receive these multicast packets,
it does not reply to this briefer Register message. As a result, R1, when its timer expires, again
sends its multicast packets to R3 (RP) encapsulated in PIM Register messages.