Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO

[Richard Kelsey <[e-mail]>]

> Date: Wed, 13 Apr 2011 13:35:58 +0200
> From: "Anders Brandt" <[e-mail]>
> 
> Sometimes I cannot recognize topics that I myself initiated!
> 
> If a sleeping node needs to ask a neighbor for a favour,
> it has nothing to do with the routing protocol.

What sort of favour did you have in mind?  I thought that
what the sleeping node wanted was to have messages routed to
it, which could be be imagined to have something to do with
the routing protocol :-).

> The only important issue is that since the sleeping node is (well,
> sleeping), it cannot participate in the routing protocol communication.
> And that also applies to the reactive route discovery introduced with
> RPL P2P.
> Thus, I do not agree that this should be a feature of RPL. In that case
> it should be replicated in RPL, RPL P2P and any future routing protocol
> - as well as any mesh-under solution in use out there.
> 
> 6LoWPAN ND is the right place for this feature. For the above reason AND
> because the message flow is identical to the address registration
> already taking place in 6LoWPAN ND.
> 
> I see no need for any new fancy time stamp mechanism if this is just
> another information conveyed along with the ARO. (Did I miss something
> here?)

As I understand it, the issue has to do with a sleepy node
moving its network connection from one router to another.
One part of this is informing the new router that the sleepy
node is now a neighboring host.  That is clearly a job for
ND.  Assuming that is solved, the new router will send a RPL
DAO which will create a downward route to the sleepy node.

The problem is that the old downward route via the original
neighboring router is still in place.  Creating the new
route cannot remove the old one, because the sleepy device
must be allowed to maintain links to multiple routers.  What
I think should happen is that NUD on the original
neighboring router should detect that the sleepy host is no
longer connected, at which point that router needs to send a
DAO that does not include the sleepy host as a RPL target.
I don't know if RPL describes removing a RPL target in this
fashion.

The only way to do NUD for a node that sleeps is to time it
out if it is not heard from.  It might be better to leave
this to the link layer, because there are link layer issues
involved (does the node wake on a schedule? does it send
polling messages?) and because it needs to be done using a
minimal amount of energy.
                                       -Richard Kelsey