Hello,

Let me try to understand the Hop Limit discussion in 6lowpan-ND context.

Le 13/10/2010 14:30, Daniel Gavelle a écrit :
When the multi-hop NS is sent from the LR to the LBR, its hop limit
is set to 255 and then decremented on each hop. When it arrives at
the LBR, the hop limit=255 check is ignored. There are a couple of
problems with this mechanism:-

(1) If the packet enters a routing loop, it will take a long time to
 die.

Hmm... not sure it is a looping problem because IPv6 nodes are supposed
to drop the packet when its Hop Limit reaches 0.

(2) Some stacks have a rule that packets with a hop limit of 255
should never be forwarded by the routing layer or a hop limit of 254
 should never be transmitted.

I think yes, that is the case of vanilla ND (non 6LoWPAN)
implementations - nodes must drop ND packets whose Hop Limit is less
than 255 (remark "ND packets", not just any packet).

But draft-ietf-6lowpan-nd requires that the vanilla-ND <255 check to not
be performed - thus a Hop Limit implementation according to 6lowpan-ND
would work.  Is this behaviour ok?

(e.g. 6lowpan-ND text says "result the hop_limit=255 check on the
receiver is disabled for such messages.")

These problems could be addressed by setting the hop limit to a more
 typical value, e.g. 64, for the multi-hop messages.

I think it is good to take into account the diameter of a typical
6LoWPAN network (max number of IP hops on shortest path between most
distanced node from LBR) and require the sender's initial Hop Limit to
be set that way, in spec.

What is the typical number of IP nodes in a 6lowpan network? 16?  How
many nodes does 802.15.4 PHYs support in a network?  Implementations?
And the shortest IP path within?

I don't see WPAN networks requiring 255 (Hop Limit) nodes on a personal
area network - it's way too much.  The typical WPAN networks I
experiment are less than 8 nodes, and yes I agree it's only small scale.

I think it is not good for the 6lowpan-ND spec to be vague about it
(currently it says: "255 or smaller number").

And there are other problems with this Hop Limit field:

A Hop Limit field is decremented when forwarding packets across links.
I think here 6lowpan-ND nodes use exclusively link-local addresses as
src and dst (I have to verify spec).  A node is typically prohibited
from forwarding such packets across links.  Thus, if not forwarding, it
would not make sense to decrement the Hop Limit field of 6lowpan-ND
messages by 6lowpan-ND nodes.

What would need to happen to avoid this necessity of not forwarding
link-addressed packets is that each 6lowpan-ND node originates a _new_
6lowpan-ND message upon reception, instead of forwarding it; a new
packet with different src and dst link-scoped addresses.  If a new
packet is thus generated then that new packet would have to have a fresh
Hop Limit value, not the received value decremented.

Just some thoughts.

Alex







Regards,

Daniel.


_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to