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

Richard Kelsey <> Wed, 13 April 2011 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03F09E073E for <>; Wed, 13 Apr 2011 07:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cLi53G78vx5c for <>; Wed, 13 Apr 2011 07:38:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF6D3E0736 for <>; Wed, 13 Apr 2011 07:38:18 -0700 (PDT)
Received: from unknown [] (EHLO by with ESMTP id (envelope-from <>); Wed, 13 Apr 2011 08:38:19 -0600 (MDT)
X-MXL-Hash: 4da5b55b17a68dbe-ff154ea57ab167132d33c4c9e0f16b16715d0b80
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 10:38:14 -0400
Date: Wed, 13 Apr 2011 10:38:34 -0400
Message-Id: <>
To: Anders Brandt <>
In-reply-to: <6D9687E95918C04A8B30A7D6DA805A3E01CCD8A9@zensys17.zensys.local> (
From: Richard Kelsey <>
References: <> <> <6D9687E95918C04A8B30A7D6DA805A3E01CCD8A9@zensys17.zensys.local>
X-OriginalArrivalTime: 13 Apr 2011 14:38:14.0442 (UTC) FILETIME=[6BAD00A0:01CBF9E8]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-AnalysisOut: [v=1.0 c=1 a=KVkKRpFW1FcA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo]
X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=gO3uh9h2KWvP1CQcc7YA]
X-AnalysisOut: [:9 a=4AYOmu6y-pnZTv2XIccA:7]
Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Apr 2011 14:38:20 -0000

> Date: Wed, 13 Apr 2011 13:35:58 +0200
> From: "Anders Brandt" <>
> 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

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