PIM-SM Forward state expiration timer

[turbo_engine26]

Hello,

As a PIM-SM rule of thumb says, "To prevent an outgoing interface's Forward state to be stuck on a PIM-SM router, a countdown timer (3 minutes) is started. If no Join/Prune message arrive from downstream neighbor, the timer reaches 0 and the outgoing interface is removed from the OIL".

My question is:

What are the situations that causes the OIL Forward state to be stuck on a PIM-SM router? ... A simple Prune message would arrive from a downstream neighbor and causes the upstream neighbor to remove the interface from the OIL. Why this rule exists in the first place?

Thanks in advance

AM

[Peter Paluch]

Hello,

Are you quoting an RFC or is this your formulation of the rule? If you are quoting a document, can you provide a link to it? I do have an idea but first I would like to get the bigger context of the statement.

Best regards,

Peter

[turbo_engine26]

Hi Peter, thx for your reply and good to see you.

This statement was taken from the "Developing IP Multicast Networks", Page 148 in "PIM-SM State-Refresh" section.

I understand the part that a PIM-SM router must maintain a refresh interval for OIL interfaces with Forward/Sparse state to prevent it from being expired and deleted. I didn't look to the RFC yet but it is worth a look in there. In PIM-DM, the router just deletes the Forward/Dense state when a Prune message is received without waiting any interface to expire because the Forward/Dense's expiration timer is always 00:00:00.

But i don't understand Why PIM-SM put this rule of a countdown timer in the first place? ... Isn't receiving a Prune message enough?

Regards,

AM

[Peter Paluch · Accepted solution]

Hello my friend,

Receiving a Prune message is enough indeed to remove an interface from the OIL.

Personally, I see this mechanism as a built-in security brake in case something goes wrong with your peer. Because of whatever reasons, it may become stuck - it will still send PIM Hello messages but it won't be capable of sending neither Joins nor Prunes. The Joins effectively create what is called a "soft state" - a state that is valid only for a period of time, and must be periodically refreshed.

This is, to a certain point, similar to IGMPv2 Membership Report and Leave Group messages - while a well-behaved implementation should send Leave message whenever it leaves a group, it may not do it for whatever reason. Therefore, as a safety net, IGMP group states automatically expire on a router after a certain time. Granted, the PC may have been turned off or disconnected and the router has no way of knowing that. In PIM, it would not be as easy because if your neighbor goes away, you'll stop receiving PIM Hello messages from it - but the basic idea is still there - to disallow some state lurking in your router forever just because some message (which is even unacknowledged and therefore dangerous in PIM!) did not arrive.

Best regards,

Peter

[turbo_engine26]

Thx Peter

This leads to a second question.

If this expiration timer is treated as a Safety procedure, why then isn't it applied to PIM-DM? .. Forward/Dense state never expires. So, if a PC get disconnected, its PIM-DM local router won't know and the state get stuck in the router.

Regards,

AM

[Peter Paluch]

Hello,

If this expiration timer is treated as a Safety procedure, why then  isn't it applied to PIM-DM? .. Forward/Dense state never expires. So, if  a PC get disconnected, its PIM-DM local router won't know and the state  get stuck in the router.

The PIM-DM uses a different paradigm - instead of router joining the multicast distribution tree explicitly, PIM-DM assumes that everyone wants to receive the multicast (and if not, Prune messages will be used to eliminate those branches that do not contain any receivers). The Forward state is therefore the natural stable state. That is why the Forward state does not actually expire in PIM-DM.

What expires in PIM-DM, though, is the Prune state. The assumption that everyone wants the multicast is obviously too general. If a router has an empty OIL, or if it receives a multicast stream via a non-RPF interface, it will sent a Prune message appropriately. A router that receives this Prune message moves the receiving interface into Pruned state. Again, this Prune state expires after 3 minutes, and the process of flood-and-prune repeats.

Or better said, it does not For some years now, PIM-DM has a State Refresh extension that allows routers to refresh their Prune states without reflooding the entire multicast stream all over the network again and again. But as you can see, it is only an optimization of refreshing the Prune state - but if it was not refreshed, it would expire.

So in PIM-SM, Forward states expire. In PIM-DM, Prune states expire. For each of these protocols, the state that expires is the "non-natural" state that had to be signalled, and has to be re-signalled to not become stuck.

Best regards,

Peter

[turbo_engine26]

Good point.

So put it this way.

Because PIM-DM uses a Flood-and-Prune approach (or implicit joins), all OIL's interfaces (with no exception) are always in Forward/Dense state until a Prune is received. (i imagine PIM-DM's source as water tap that is opened to let the water flow until the receivers block it by their Prunes   but the water keep flowing endlessly)

Because PIM-SM uses expicit joins, all OIL's interfaces are in Forward/Sparse until the timer expires or a Prune is received. (i imagine PIM-SM's source as water tap that is opened only as per the request of the receiver until the receiver Prunes it or water flow timer expires)

Regards,

AM