Subject: [pim] (S,G) expiration timer for pim-dm

From: "James Huang" <[email-masked]>
Date: Mon, 22 Apr 2002 15:15:58 -0700

Hi all,

The latest pim-dm spec does not have any description for the expiration timer of (S,G) entries.  
Section 5.6 "Timing out multicast forwarding entries" in draft-ietf-idmr-pim-dm-06.txt has some description but the document is more than four years old.
Shouldn't the management of the expiration timer be standardized?  Should the timer be updated only upon receiving (S,G) data packets or should it also be updated when a state-refresh message or prune message is received??  What bothers me is that the following scenario may occur if the expiration timer is not standardized.

Suppose the (S,G) expiration timer in a downstream router R2 is smaller than that in its upstream router R1 and suppose R1's interface toward R2 is in the pruned state. If R2 expires its (S,G) entry first and source S becomes active again before R1 expires its (S,G) entry, then R2 will not be able to receive (S,G) traffic from R1 and re-create (S,G) entry until the prune timer of R1's downstream interface expires.  Now if R2 receives a igmp (*,G) join during this period, it will not be able to send a graft(S,G) message toward the source.  So the receiver will not receive (S,G) traffic either.

Am I missing something?

Regards,
James Huang

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: "James Huang" <[email-masked]>
Date: Mon, 22 Apr 2002 15:48:14 -0700

"draft-ietf-pim-dm-new-v2-01.txt" is the draft that does not have any description for (S,G) expiration timer.
draft-ietf-idmr-pim-dm-06.txt has some description but is out of date.

Regards,
James Huang

> -----Original Message-----
> From: John Zwiebel [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 3:46 PM
> To: James Huang
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [pim] (S,G) expiration timer for pim-dm
> 
> 
> You are looking at the wrong spec.
> 
> Go to "draft-ietf-pim-dm-new-v2-01.txt"
> 
> FWIW: you might want to reexamine your need for
> implementing dense-mode PIM.
> 
> 
> On Monday, April 22, 2002, at 01:21 PM, James Huang wrote:
> 
> > Hi all,
> >
> > The latest pim-dm spec does not have any description for 
> the expiration 
> > timer of (S,G) entries.
> > Section 5.6 "Timing out multicast forwarding entries" in 
> > draft-ietf-idmr-pim-dm-06.txt has some description but the 
> document is 
> > more than four years old.
> > Shouldn't the management of the expiration timer be standardized?  
> > Should the timer be updated only upon receiving (S,G) data 
> packets or 
> > should it also be updated when a state-refresh message or 
> prune message 
> > is received??  What bothers me is that the following 
> scenario may occur 
> > if the expiration timer is not standardized.
> >
> > Suppose a downstream router R2 ages out a (S,G) entry before its 
> > upstream router R1 does. If the source S becomes active 
> again after the 
> > (S,G) entry in R2 is aged out but before R1 ages out its 
> (S,G) entry 
> > and suppose R1's interface toward R2 is in the pruned 
> state, then R2 
> > will not be able to receive (S,G) traffic from R1 and 
> re-create (S,G) 
> > entry until R1 times out the prune timer of its downstream 
> interface.  
> > Now if R2 receives a igmp (*,G) join during this period, it 
> will not be 
> > able to send a graft(S,G) message toward the source.  So 
> the receiver 
> > will not receive (S,G) traffic either.
> >
> >
> > Regards,
> > James Huang
> >

---

From: "Nicholas, Jonathan" <[email-masked]>
Date: Tue, 23 Apr 2002 07:20:17 -0500

PIM-DM has no expiration timer.  This was a conscious choice.

Because the default state for PIM-DM is forwarding, the maintenance of
forwarding entries is left as an implementor choice based on available
processing power and memory resources.  Maintenance of entries as long as
any state machine is not in the default state is mandatory, perhaps this
requirement should be stated more clearly.

The Upstream state machine's default is Forwarding.
The Downstream state machine's default is No Info.
The Assert state machine's default is No Info.
The Originator state machine's default is Not Originator.

All state machines have specific timers describing when they return to the
default state.  None of the state machines can remain indefinitely in a non
default state in the absence of traffic.

In the scenario described below, either R1 erroneously became pruned when R2
desired the traffic (i.e. R1 did not receive R2's Prune Override), or R2
left an Upstream Prune state without sending a Graft, which is an illegal
operation.  In either case, the soon to arrive State Refresh message will
trigger a Prune Override from R2, correcting the condition.

Jonathan Nicholas
Network Systems Engineer
ITT Aerospace/Communications Division

> document is more than four years old.
> Shouldn't the management of the expiration timer be 
> standardized?  Should the timer be updated only upon 
> receiving (S,G) data packets or should it also be updated 
> when a state-refresh message or prune message is received??  
> What bothers me is that the following scenario may occur if 
> the expiration timer is not standardized.
> 
> Suppose a downstream router R2 ages out a (S,G) entry before 
> its upstream router R1 does. If the source S becomes active 
> again after the (S,G) entry in R2 is aged out but before R1 
> ages out its (S,G) entry and suppose R1's interface toward R2 
> is in the pruned state, then R2 will not be able to receive 
> (S,G) traffic from R1 and re-create (S,G) entry until R1 
> times out the prune timer of its downstream interface.  Now 
> if R2 receives a igmp (*,G) join during this period, it will 
> not be able to send a graft(S,G) message toward the source.  
> So the receiver will not receive (S,G) traffic either.
> 
> 
> Regards,
> James Huang

************************************ 
If this email is not intended for you, or you are not responsible for the
delivery of this message to the addressee, please note that this message may
contain ITT Privileged/Proprietary Information.  In such a case, you may not
copy or deliver this message to anyone.  You should destroy this message and
kindly notify the sender by reply email.  Information contained in this
message that does not relate to the business of ITT is neither endorsed by
nor attributable to ITT. 
************************************

---

From: "James Huang" <[email-masked]>
Date: Tue, 23 Apr 2002 10:20:07 -0700

Thanks for replying to me email.
I still have some question with this issue.
Please see the comment below.

Regards,
James Huang

> From: Nicholas, Jonathan [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 5:20 AM
> To: James Huang; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [pim] (S,G) expiration timer for pim-dm
> 
> 
> default state.  None of the state machines can remain 
> indefinitely in a non default state in the absence of traffic.

This is true for the downstram state machine, the assert state machine,
and the originator state machine.  But for the upstream state machine, it
will stay in the pruned state as long as olist(S,G) remains NULL.
To conserve memory resouce, it might be desirable to also clean up this (S,G) entry 
after the traffic has stopped for a long time. But as I describe in my previous 
email, removing a (S,G) entry with its upstream state machine in the pruned state 
may result in the failure of packet delivery to the interested receivers.
So I guess the only way out of it is to send a graft message upstream before such a entry 
is removed.

---

From: "Nicholas, Jonathan" <[email-masked]>
Date: Tue, 23 Apr 2002 14:13:17 -0500

You are correct that the Upstream state machine could remain in the Prune
state indefinitely.  This is only possible for a router with no downstream
PIM routers.  

However, in this case, the Upstream state machine's Prune Limit Timer would
be the indicator used to determine expiration along with the Assert Timer,
if any.  That is, if the Prune Limit Timer is still running, the entry must
be maintained.

Since State Refreshes cause the Prune Limit Timer to restart, when the Prune
Limit Timer expires it is safe for the router to assume its upstream router
is no longer in a Pruned state (in fact, has quite likely expired its own
entry) and the entry may be removed.

Thank you for your comments.  I will add clarifying text to the next draft.

Jonathan Nicholas
Network Systems Engineer