Multicast Source-Tree: PIM-Graft - Shared Tree: PIM Join/Prune

[Steph1963]

Hi to Everybody,

1) Multicast Source-Tree

Can someone explain me the logic behind the utilisation of the PIM Prune/PIM Graft messages on a PIM dense mode topology (IP Multicast Source Distribution Tree).

I read that a prune message is used to prune back the distribution of the multicast data but I would like to know if it can also be used to indicate an upstream router that multicast data is requrired.

In the initial case where the multicast data is flood through the entire network, I am trying to understand

a) how a router signals to the upstream neighbor that it request the multicast data (maybe no PIM messages are required to receive multicast data)

b) how a router signals to the upstream neighbor that it does not request the multicast data (I would imagine that this is where prune messages are involved, does it need to be send periodically otherwise multicast data will be receive again.)

In this initial situation where multicast data is flood, I was able to observe the following PIM messagse but it does not make any sense to me.

A routers that need the multicast traffic will only send one PIM prune messages followed by a single PIM graft messages that will be acknowledge by the upstream router.

A router that does not need the mulitcast traffic will send a PIM prune messages followed by a single PIM graft messages that will be acknowledge by the upstream router at every 3 minutes.

In any of these cases, PIM prune messages were followed by PIM graft messages. Graft messages, according to what I read, should indicate that a previously inactive interfaces request the multicast data.  Does a PIM graft messages following a prune messages make any sense.

2) Multicast Shared-Tree

a) PIM DR Join/Prune message to RP

I would like to understand the reason why the PIM DR has to send a PIM Join Prune (SWR) toward the RP even if the RIP is not in the SPT direction as in the following diagram. I have noted that the PIM DR is still sending PIM Join Prune message after the router has find the shortest path to the source and the RP respond with RP-reachable. I really do not understand the reason for this mechanism.

b) Data Encapsulation between the Multicast Source

I also would like to know why the data has to be encapsulated between the Multicast source and the RP during the PIM registration.  I do not see why this the multicast data have to be encapsulated. If my understanding is correct no encapsulated traffic is sent between the source and any receiver.

Thanks for your help

Stephane

[Peter Paluch · Accepted solution]

Hello Stephane,

Lots of questions Let me go over individual thoughts you have opined here.

a) how a router signals to the upstream neighbor that it request the  multicast data (maybe no PIM messages are required to receive multicast  data)

Exactly as you said - in PIM-DM, no PIM messages except regular Hello messages are necessary to receive multicast data. In PIM-DM, the implicit action is to send the multicast traffic to each PIM neighbor without any explicit Joins or Grafts. In other words, if I detect a PIM-DM neighbor through its Hello messages, and I start receiving a new multicast stream, I will automatically and implicitly forward that stream towards the particular neighbor. Explicit signalling is required only if the neighbor does not want to receive that multicast stream, or if it has changed its mind afterwards and wants to receive it after all.

b) how a router signals to the upstream neighbor that it does not  request the multicast data (I would imagine that this is where prune  messages are involved, does it need to be send periodically otherwise  multicast data will be receive again.)

If a router starts receiving a multicast stream that it does not want to receive, it will send the Prune message back to the upstream router. However, such Prune can be sent only after the router starts receiving the unwanted multicast traffic, not before. Historically, the pruned state expired after 3 minutes, after which reflooding of the stream occured, possibly eliciting a new Prune message.

However, since long, the PIM-DM supports a mechanism called State Refresh. This mechanism allows the routers to refresh their Pruned state if necessary, without periodically retransmitting the Prune messages itself. You may want to read more about this mechanism here:

http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_pim_dense_rfrsh_ps6350_TSD_Products_Configuration_Guide_Chapter.html

In any of these cases, PIM prune messages were followed by PIM graft  messages. Graft messages, according to what I read, should indicate that  a previously inactive interfaces request the multicast data.  Does a  PIM graft messages following a prune messages make any sense.

In the context of your description, such behavior makes no sense. If a multicast flow is to be pruned, there is no need for the Graft message at all, and if the flow is wanted then again no messages in PIM-DM are necessary. Are you absolutely sure about your observation?

I would like to understand the reason why the PIM DR has to send a PIM  Join Prune (SWR) toward the RP even if the RIP is not in the SPT  direction as in the following diagram. 

I must admit I haven't seen a similar scenario. What is the content of that Join/Prune message - does it join or prune the tree?

I also would like to know why the data has to be encapsulated between  the Multicast source and the RP during the PIM registration.

Because there is no (S,G) or (*,G) state generally created on routers between the source and RP. The RP does not know beforehand where the source is so it cannot send a Join message towards it. If there was no registering process then the DR would be unable to forward the multicast traffic natively towards the RP, as the multicast traffic cannot flow natively if there is no multicast routing state created for it along the way from DR towards RP.

Best regards,

Peter

[Steph1963]

Hi Peter,

Thanks a lot for your answer,

1) Concerning the PIM Dense-Mode question, I will verify my observation again.

2) For the second question about the PIM Designated Router, I read the following note from Cisco:

Sparse Mode: A Designated Router (DR) sends periodic join/prune message toward a group-specific Rendez-Vous Point (RP) for each group for which it has actvive members.

If my understanding is correct, the DR will forward a few multicast packet from the RP to the receiver but will look at the shorrtest path tree to the source and will used this interrface as a new source of multicast traffic. If this is true, the DR will send join/prune toward the RP and join/prune toward the shortest path tree to the source. My question was why DR keeps sending join/prune toward the RP even if does not used multicast from the RP.

Note: I might be wrong here because I am thinking about a case where an assert mechanism would be used because the PIM DR router is not the closest to the multicast source. First packet would come from the RP through the DR but the assert mechanism would determine that the DR is not the closest to the source. May be there is no shuch thing as an assert mechanism in PIM sparse mode.

3) Data encapsulation between source and RP

This is a very good answer, if I have  understand you correctly: the RP does not know the IP address of the source so multicast traffic must be encapsulated so the RP can find the source IP address and then send a (S,G) register message.

Thanks again for all your help

Stephane

[Peter Paluch]

Hello Stephane,

Thank you - you are welcome.

Sparse Mode: A Designated Router (DR) sends periodic join/prune message  toward a group-specific Rendez-Vous Point (RP) for each group for which  it has actvive members.

In my understanding, this is simply to say that from all routers on a segment, it is precisely the DR that is responsible for sending PIM Joins and Prunes towards the RP - depending on what groups do its directly-connected end hosts subscribe and unsubscribe via IGMP. Naturally, because a sender is not apriori known, each DR must send a Join towards the RP to create a branch of the shared tree. If a source to this group starts sending its stream, it will be delivered to the RP (via the Register process) and may further flow down the shared tree. If a DR did not send any Join towards the RP, the shared tree branch containing the DR would not be created, and the end hosts would not be able to receive the multicast stream.

My question was why DR keeps sending join/prune toward the RP even if does not used multicast from the RP.

My understanding is that this happens because the DR maintains the Prune state that was created after the DR switched away from shared tree to source-based tree.

Best regards,

Peter

[Steph1963]

Hi Peter,

Thanks a lot all your help.

Just found some information in RFC 2362 that might clarified things:

A) Switching from shared tree (RP-tree) to shortest path tree (SPT)

The router can switch to a shortest path tree after receiving packets from that source over the shared RP-Tree.

On the last hop router, the (S,G) entry is initialized with the SPT-bit cleared indicating that shortest path tree branch from S has not yet been set-up completely

When the router starts to receive packet from the source S, the router sends a Join/Prune message toward the RP indicating that the router no longer wants to receive packets from S via the shared-tree.

I could not find if the join/prune toward the RP and toward the source S, if different must be send continuously or not

B) Assert

I also find that under various condition a parallel router connected to the same LAN may take over as the last-hop router in place of the DR. I would think that they would refer here to the assert mechanism for Sparse-Mode when the router is trying to find the shortest path tree.

Thanks again for your very useful help

Stephane