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

Erik Nordmark <nordmark@acm.org> Tue, 12 April 2011 20:50 UTC

Return-Path: <nordmark@acm.org>
X-Original-To: 6lowpan@ietfc.amsl.com
Delivered-To: 6lowpan@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8F5CE0903 for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Level:
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xJUazawhlyb for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:50:15 -0700 (PDT)
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id 1F53CE0858 for <6lowpan@ietf.org>; Tue, 12 Apr 2011 13:50:15 -0700 (PDT)
Received: from [128.107.115.157] ([128.107.115.157]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3CKoC4L001920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 13:50:13 -0700
Message-ID: <4DA4BB1E.2050002@acm.org>
Date: Tue, 12 Apr 2011 13:50:38 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: '6lowpan' <6lowpan@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [6lowpan] Fwd: Re: "Advertize on Behalf" flag in ARO
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2011 20:50:16 -0000

On 3/30/11 1:30 AM, Pascal Thubert (pthubert) wrote:
> Hi Carsten:
>
> RPL recognizes a movement when a DAO information has a stale
> DAOSequence. The DAOSequence is an information that the owner of the
> advertised target increments.
> If we define an interaction whereby we redistribute ND-15 into RPL, then
> (probably) the RPL router will inject a host route on behalf of the
> host.
> When the RPL router injects such a route and then maintains that route,
> it still has has to provide an idea of the freshness of the information
> that it is injecting in a DAOSequence.
> When the host moves to an alternate router, it would have to provide
> something so that the new router sets an updated DAOSequence that the
> routing update percolates up the DODAG.
> IOW, without a TID, a host cannot efficiently move from a router to the
> next.

Why couldn't the RPL router take a timestamp when it hears an ARO from a
host, and convey that in RPL? Then that timestamp can be used to
determine the most recent registration i.e., determine the most likely
topological location of the host.

The beauty of such an approach is that it avoids requiring having the
hosts know about routing protocol-specific information like a TID.

    Erik