PIM-DM and PIM-SM

[turbo_engine26]

Hello,

I have two questions regarding the above mentioned Multicast routing protocols.

Question A:

Recall that PIM-DM support and uses Implicit joins through the use of Reverse Path Broadcasting (RPB) or known as flood-and-prune mechanism which is a network conservation's enemy. In the same time, it was stated that the group member doesn't have to wait for that Implicit join from the source because this will cause forever join latency. I understand that everything got a trade-offs but from what i see is that PIM-DM has issues more than just trade-offs.

The Question:

In what situations and scenarios do i need to run this protocol in real life? and If the PIM-SM is the best choice among all of multicasting protocols because of its shared and SPT support as well as Explicit joins, why don't we just implement PIM-SM only? ...

Question B: (consists of multiple questions actually)

Please see attached topology and multicast routing tables of Porkpie and Bowler.

I have a little confusion between the (*,G) and (S,G) entries in the mroute table.

It says that, Porkpie's (*,G) entry shows E0 on the outgoing interface list and in forwaring state and the outgoing interface list of its (S,G) is Null.

At Bowler, however, E0 is on the incoming interface list of the (*,G) entry and the entry's outgoing interface list is Null and E0 is on the outgoing interface list of the (S,G) entry and in forwarding state.

The Question:

1- Why the outgoing interface list of Porkpie's (S,G) entry is Null? .. Is it because Porkpie is part of shared tree not SPT?

2- Why the outgoing interface list of Bowler's (*,G) entry is Null? .. Is it because Bowler is no longer part of shared tree and switched automatically to SPT?

3- If the auto switching from shared tree to SPT is mainly used in case of high traffic rates, why Cisco made it as a default?

Regards,

A.M.

[Eugene Khabarov]

Answer to question A in my opinion is simple. You need to run PIM-DM in case you have simple topology and large number of multicat clients regarding total count of users. PIM-SM hase more complex configuration requirements and should be used in opposite case. Some vendors does not realized PIM-DM even because almost each multicast task can be implemented with help of PIM-SM instead of PIM-DM.

---

HTH. Please rate this post if it was helpful. If this solves your problem, please mark this post as "Correct Answer."

[turbo_engine26]

You need to run PIM-DM in case you have simple topology and large number of multicat clients regarding total count of users. 

Actually, this is the definition of PIM-DM which is already known. I am asking what are the known and popular situations and factors that forces me implement the dense mode. For example, types of multicast apps to use the dense mode, network type (frame relay, MPLS) or any other example not in my mind at the moment. Of course, if PIM generally support all network types and all multicast apps then choosing between SM or DM is a matter of size only. However, i still don't understand when it says that DM is for many routers and SM is for few routers in relation of course with the total number of the internetwork. I mean, why not use sparse with many routers? ... In my opinion, using flood-and-prune in a DM with many routers could cause congestion issues.

Some vendors does not realized PIM-DM even because almost each multicast task can be implemented with help of PIM-SM instead of PIM-DM.

But why some vendors doesn't realize PIM-DM and shifting to PIM-SM? ..

HTH

A.M.

[Peter Paluch]

Hello,

 I am asking what are the known and popular situations that makes me implement the dense mode.

An ease of configuration, a small network (a few routers), a small number of multicast groups, a small number of senders into these groups.

In PIM-DM, the flood-and-prune is not the main problem - it has been solved years ago using the PIM-DM State Refresh feature. The main problem of DM is that for each {S,G) tuple, each and every router in the network has to create and maintain the state in its multicast routing table, even if the router is totally away from the SPT between the sender and the recipients. Having 10 senders to 10 multicast groups will lead to each and every router maintaining 100 entries in its multicast routing table. Such an approach is not scalable, as all routers need to maintain forwarding state about all senders to all multicast groups. The number of multicast routing entries grows quadratically with the count of senders/groups.

However, i still don't understand when it says that DM is for many  routers and SM is for few routers in relation of course with the total  number of the internetwork

You probably want to say "many/few recipients", not "many/few routers". The idea of DM is that it is worth to flood the stream to the entire network and force every router to keep a state record about it in its multicast routing table because the recipients are expected to be present almost everywhere in the network. However, even if that were the case, that is just a very general motivation. Its particular implementation in PIM-DM is strongly unscalable.

Do not search for any extraordinary wisdom behind the PIM-DM. It is simply one of many approaches to make the multicast routing just work - quick, simple and relatively inefficient, yet workable. PIM-SM shows how that process can be optimized, i.e. it is a different way of approaching the same thing. PIM-DM probably exists also because the older dense-mode routing protocol, DVMRP, was working in a very similar way, and PIM-DM could be seen as the next step in the evolution of multicast routing protocols. PIM-DM has nearly the same effect as DVMRP but in comparison to DVMRP, it does not build its own routing table to perform RPF checks, rather, it reuses the existing routing table. But the general idea of flooding the multicast stream to the entire network and pruning the unnecessary parts afterwards still remains.

Best regards,

Peter

[turbo_engine26]

Hi friend,

I don't know why every time you show up, you provide a so talented and intelligent answer. .. I really like such a detailed explanation rather than a two lines only answer.

So let me begin the quoting thing.

The main problem of DM is that for each {S,G) tuple, each and every router in the network has to create and maintain the state in its multicast routing table, even if the router is totally away from the SPT between the sender and the recipients.

So, you say that the main problem is with the source-based tree approach that's why RPT is more preferred since it only creates one entry in the mroute table, I agree with that. 

You probably want to say "many/few recipients", not "many/few routers".The idea of DM is that it is worth to flood the stream to the entire  network and force every router to keep a state record about it in its  multicast routing table because the recipients are expected to be  present almost everywhere in the network.

Oh yes, sorry, many/few group members not routers, exactly! Missed that one ... But what about using sparse with many members? .. Will it harm the network? .. In my opinion, it will be more scalable because routers attached to group members will simply reach an RP (love the Auto-RP) and receive the multicast packets from it even if members located everywhere in the network as well. What do you think?

Do not search for any extraordinary wisdom behind the PIM-DM. It is simply one of many approaches to make the multicast routing just work - quick, simple and relatively inefficient, yet workable.

Sounds good! .. But does it mean that there aren't other factors that forces me to use dense mode?

Hey , what about Question B?

Thx my friend

HTH

A.M.

[Jon Marshall]

Sorry i did answer this but wanted to check something and it's still not entirely clear -

1- Why the outgoing interface list of Porkpie's (S,G) entry is Null? .. Is it because Porkpie is part of shared tree not SPT?

2- Why the outgoing interface list of Bowler's (*,G) entry is Null? .. Is it because Bowler is no longer part of shared tree and switched automatically to SPT?

3- If the auto switching from shared tree to SPT is mainly used in case of high traffic rates, why Cisco made it as a default?

1) I assume so. If Porkpie does not have an interface in the OIL for the (S,G) entry then it suggests that the SPT is -

Bowler -> Fedora - Homburg   which could be verified by checking the mroute tables on these routers.

What i am not entirely sure on, and can't test, is why Porkpie has an (S,G) entry in the first place. I'm sure someone else will be along to explain it soon enough

2) Yes, Bowler is not receiving packets on the shared tree anymore

3)  It's not so much about high traffic rates as it is to do with optimal routing ie. if there is a better path then i guess Cisco decided it was best to use that one. How much traffic is required to switchover is set by the command -

ip pim spt-threshold

if you set the kbps to "infinity" then it should not use SPT but contine to use the shared path.

Jon

[turbo_engine26]

What i am not entirely sure on, and can't test, is why Porkpie has an (S,G) entry in the first place. I'm sure someone else will be along to explain it soon enough 

Exactly! this is the thing that confuses me. Even though it is in prune state, why does it exist in the first place if it is not part of SPT! .. No problem, i expect someone can provide the needed answer.

1) I assume so. If Porkpie does not have an interface in the OIL for the (S,G) entry 

Sorry but what OIL means?

HTH

A.M.

[Jon Marshall]

OIL = Outgoing Interface List

Jon

[Jon Marshall · Accepted solution]

Exactly! this is the thing that confuses me. Even though it is in prune state, why does it exist in the first place if it is not part of SPT! .. No problem, i expect someone can provide the needed answer.

Okay it's to do with the shared tree. Before the SPT is setup Bowler will be receiving the multicast traffic via Porkpie on the shared tree. You can see this is the case on Porkpie because it's (*,G) has an OIL of e0 ie. the connection to Bowler.

So when Bowler switches to the SPT it needs to stop any duplicate traffic being received on the shared tree. It does this by sending RP-Bit prune messages up the shared tree and these eventually get to the RP. Porkpie receives this message and enters this (S,G) entry into it's mroute table.

This is part of the SPT switchover ie. when the path diverges between the shared tree and the SPT the router where the path diverges (in this case Bowler) sends out (S,G) prune messages back up the shared tree. This makes sense because any routers on the shared tree and the RP that are not part of the new SPT have to have a way of knowing not to continue sending the mutlicast stream down the shared tree.

Hope i explained that clearly enough.

Jon

[turbo_engine26]

Thx a lot

Clear now.

[Peter Paluch · Accepted solution]

Hello,

So, you say that the main problem is with the source-based tree approach  that's why RPT is more preferred since it only creates one entry in the  mroute table, I agree with that.  

Yes, and even stronger: PIM-DM creates a SPT but the multicast forwarding state, either prune or forward, must be maintained by all routers in your network, even if not on the SPT. PIM-SM creates only a single state in the mroute table and only on those routers that are part of the RPT, other routers do not even bother.

But what about using sparse with many members? .. Will it harm the  network? .. In my opinion, it will be more scalable because routers  attached to group members will simply reach an RP (love the Auto-RP) and  receive the multicast packets from it even if members located  everywhere in the network as well. What do you think?

Surely, using sparse mode even with many members will not harm the network in any way. It is simply doing the multicast routing from an "opposite" end - instead of flooding the multicast everywhere without anyone explicitly claiming its interest to receive any multicasts, wait for the members to announce themselves and only forward the multicast towards explicitly known member locations.

I guess that the motivations used to explain the SM/DM about the few/many members are just confusing. Forget about them Both DM and SM will work both in small and large networks, though they will differ on the optimality of distribution trees (SPTs are optimal with respect to shortest routes from source to destinations while RPTs do not always provide the shortest paths to deliver data) and the amount of state information in routers (SM is much more conservative than DM).

Regarding the Auto-RP - yes, it's a fine mechanism but a proprietary one, and needing DM to actually work Use BSR mechanism from PIMv2 whenever possible.

Sounds good! .. But does it mean that there aren't other factors that forces me to use dense mode?

No. In my opinion, nothing can really force you to use either DM or SM. It's your choice, and it will always work (it is not like in, say, MPLS-TE where you absolutely need a link-state routing protocol - here, both SM and DM will make your network perform multicast routing, just in different ways).

Hey , what about Question B? 

I believe Jon has already explained it perfectly as usual - but of course, if there are any unclear spots, please feel welcome to ask further!

Best regards,

Peter

[turbo_engine26]

Thx Peter.

Everything clear now.

[Jon Marshall]

edited to check something