Subject: PIM-SMv2 functional clarification - join latency

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Tue, 24 Aug 1999 13:47:04 -0500

Hi,
I have a question about Join Latency for new receivers in PIM-SM. The 5th
point in Section 3.8.4 in RFC 2362 talks about the register suppression
timer. There is a line in it that says "A lower value means more frequesnt
register bursts at RP, while a higher value means longer join latency for
new receivers." This leads me to believe that if there is a DR sending a
PIM-Join message to the RP after the source-specific tree has been pruned by
the RP due to no members being present earlier, the time after which data
actually starts flowing to the DR will be dependent on the register
suppression timer value in the sender's DR. 

Let us consider the following scenario with 3 routers, SDR (Source's DR),
RDR (Receiver's DR), and the RP. Let the SDR and the RDR be directly
connected to the RP and not connected with each other. Let us assume that
the sourcing host and the receiving host are connected to the LAN ports of
the SDR and RDR respectively. Now, the scenario is like this:

1. Source starts sending data.
2. SDR register encapsulates the data packet(s) to the RP.
3. RP realizes that it has no downstream members. So, it prunes the
multicast tree back to the SDR. So, the RP must have an (S,G) entry with a
pruned flag.
4. Receiver joins the multicast group.
5. RDR sends a PIM Join to the RP for the same group for which the RP has a
pruned state.

In the above case, when would the receiver start receiving data? Would it
have to wait till the register suppression timer expires in the SDR and it
again sends data to the RP? In that case, if the register suppression timer
is set to the default, the join latency would be anywhere between 30 to 90
seconds. This seems like an awfully long join latency. Should not the PIM
Join message reaching the RP from the RDR trigger the RP to join again on
the earlier pruned tree? 

I am not sure if I am mistaking or missing something here. If this is
explained anywhere in the RFC, can anyone point me to it? If someone could
clarify how this is supposed to work, I would greatly appreciate that.

Thanks!
Vidya

---

From: Ravi <[email-masked]>
Date: Tue, 24 Aug 1999 13:45:37 -0700

Narayanan Vidya-CVN065 writes:

| I have a question about Join Latency for new receivers in PIM-SM. The 5th
| point in Section 3.8.4 in RFC 2362 talks about the register suppression
| timer. There is a line in it that says "A lower value means more frequesnt
| register bursts at RP, while a higher value means longer join latency for
| new receivers." This leads me to believe that if there is a DR sending a
| PIM-Join message to the RP after the source-specific tree has been pruned by
| the RP due to no members being present earlier, the time after which data
| actually starts flowing to the DR will be dependent on the register
| suppression timer value in the sender's DR. 
| 
| Let us consider the following scenario with 3 routers, SDR (Source's DR),
| RDR (Receiver's DR), and the RP. Let the SDR and the RDR be directly
| connected to the RP and not connected with each other. Let us assume that
| the sourcing host and the receiving host are connected to the LAN ports of
| the SDR and RDR respectively. Now, the scenario is like this:
| 
| 1. Source starts sending data.
2. SDR register encapsulates the data packet(s) to the RP.
| 3. RP realizes that it has no downstream members. So, it prunes the
| multicast tree back to the SDR. So, the RP must have an (S,G) entry with a
| pruned flag.
| 4. Receiver joins the multicast group.
| 5. RDR sends a PIM Join to the RP for the same group for which the RP has a
| pruned state.
| 
| In the above case, when would the receiver start receiving data? Would it
| have to wait till the register suppression timer expires in the SDR and it
| again sends data to the RP? In that case, if the register suppression timer
| is set to the default, the join latency would be anywhere between 30 to 90
| seconds. This seems like an awfully long join latency. Should not the PIM
| Join message reaching the RP from the RDR trigger the RP to join again on
| the earlier pruned tree? 
| 
| I am not sure if I am mistaking or missing something here. If this is
| explained anywhere in the RFC, can anyone point me to it? If someone could
| clarify how this is supposed to work, I would greatly appreciate that.

When the <*,G> join is received by the RP from the RDR, it triggers
a join/prune message to the source. 

Refer Section 3.2.1 Sending join/prune Messages. The triggered
join/prune messages paragraph Case 2.3

      2 Receipt of a Join/Prune message for (S,G), (*,G) or
        (*,*,RP) will cause building or modifying corresponding state,
        and subsequent triggering of upstream Join/Prune messages, in
        the following cases:

           3 When there exists a (S,G)RPT-bit with null oif list,
             and an (*,G) Join/Prune message is received, the arriving
             interface is added to the oif list and a (*,G) Join/Prune
             message is triggered upstream.

cheers,
Ravi

---

From: Dave Thaler <[email-masked]>
Date: Tue, 24 Aug 1999 15:31:30 -0700 (PDT)

Vidya writes:
> again sends data to the RP? 

Yes.

> In that case, if the register suppression timer

The RP is not required to keep per-sender state.  (If there are
100's of senders each sending 1 packet every 5 minutes, it may be
a bad idea to keep per-sender state.)  Hence, the RP doesn't know
what to do until the next register arrives.

-Dave