So the PIM-DM uses graft message in case a router wishes to re-join a group which it pruned earlier. The question is why not use the join message to send a PIM-join to the RPF neighbor (instead of using a graft message) ?
PIM-DM is based on "flood and prune" mechanism. It doesn't work on explicit Join mechanism.
Explicit join messages are used in Sparse mode implementations only.
The "Join" messages in dense-mode implementations are used for different purpose. Mainly it is used for "Prune Override" feature in multi-access network (Ethernet).
In the above diagram, imagine that R1 is getting a multicast stream and R2 & R3 are having recievers of that multicast group connected to them.
If recievers connected to R2 leave the group ( by sending IGMP leave) , then R2 sends a Prune message through the RPF interface ( LAN segment) and R1 and R3 will see that Prune message. R1 will think that it should stop sending the multicast traffif through the LAN segment by removing the LAN interface from OIL.
If R3, still has recievers connected to it, R1 shouldn't stop sending multicast traffic to the LAN. In order to make this happen, whenever R3 sees a prune message from anyone in the LAN , It will generate a Join message to negate that Prune message and R1 will not prune the LAN interface from sending traffic.
As you mentioned, graft message is specific for re-joining to a group which was pruned by the router earlier.
but then we could've used the same join message for this purpose, no? What I'm trying to say is that the graft message doesn't have any fields that enables it to do something that the join message can't.
Consider the same prune-override example that you mentioned: If R3 can send a join to override R2's prune, then it might as well send a join when a pruned group comes back..
PIM Graft messages use the same format as Join/Prune messages, except that the Type field is set to 6.
But the upstream router responds differently for Graft and Join.
Basically, during a Graft operation, a Graft message will be acknowledged by the upstream router ( our case R1).
Once the Down Strean router sends a Graft message, it will start a timer, wait for an GraftAck and will be in the AckPending state ( not in forwarding state). Once it recieves the GraftAck from upstream, then it will move to Forwarding state.
The following RFC is a good source to understand this mechanism.
Thanks again for the information. I only have limited experience with the IEEE and standards, but from what I know, they're very strict about using different message types etc. The timers that you speak about could've been implemented using one bit in the join message itself (instead of having a different message type).. I'll try to talk to some experts from the software engineering to see what they think about this and if the graft message carries/could have carried some functionality (since it's DM, I'm totally expecting a 'nobody uses this' as the first reaction) let's see if we find out any information about it..