Subject: [pim] PIM-DM Response to TTL = 0

From: "Nicholas, Jonathan" <[email-masked]>
Date: Tue, 6 Nov 2001 10:25:04 -0500

All,

We are trying to specify the correct course of action when a PIM-DM router
receives a multicast message with a TTL of 0.

Clearly, the message cannot be propagated.

Should the router assume all messages associated with that (S,G) have the
same TTL, which is likely?
If so, sending a Prune would be the right response.

If not, what actions, if any, should the router take?

I seem to dimly recall PIM-SM having to deal with a similar situation, but
cannot find a description of it.

Opinions? Recommendations?

Jonathan Nicholas
Network Systems Engineer
ITT Aerospace/Communications Division

************************************ 
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: John Zwiebel <[email-masked]>
Date: Tue, 06 Nov 2001 08:47:20 -0800

> receives a multicast message with a TTL of 0.

FWIW: you are going to run into implementation problems for some 
vendors.  You should never actually receive a packet with a TTL of 0,
but you could easily get packets with a TTL of 1.  The problem is
that the TTL is decremented before any other operation on the packet
if it is then 0, then the destination address is checked to see if its
"forus"  (ie the router is the destination) otherwise its dropped.

This is suppose to free up the router input queue for "real work".

Obviously the router can't be a member of all multicast groups, and
decrementing the TTL of a multicast packet before it gets processed by
PIM dense-mode results in a failure to respond with an assert if that
is required.

> cannot find a description of it.

Yes, by default many applications send packets with a TTL of 1.  This
may be "good enough" to get (S,G) state instantiated on the first-hop
and get an encapsulated packet sent to the RP.  Now you have the RP
joining toward the source (if there are members).  With state on the
all the routers between the RP and the first-hop, it gets extremely
confusing to figure out why data isn't getting delivered to the receivers.
Although discussing it in this forum makes it appear "obvious", I can't
tell you how many times I've been bitten by this nor how many times others
have wondered about "what's wrong with PIM" because of this.

There's nothing that PIM-SM can or should do about this.  Trying to 
use TTL to scope multicast has proven to be very difficult, if not 
useless.  

FWIW, I believe the same thing applies to dense-mode.  It will be 
difficult to get everyone on the same page here (I believe) and will
be much better to recommend that multicast apps not use TTL scoping.

This means that things like an "expanding ring search" have to depend
on something other than the TTL to findout how far away a particular 
service is.

I'm not taking a stong position on this.  I'm just pointing out that
its going to be difficult to get vendors to comply with whatever solution
you come up with because they have made some basic assumptions about
how to handle TTL that will be very difficult to change.

So, I don't think you can come up with something that everyone will
agree on.  I could be wrong.

2cents.
 
> _______________________________________________
> Pim-external mailing list
> [email-masked]
> http://mailist.procket.com/mailman/listinfo/pim-external