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

Erik Nordmark <nordmark@acm.org> Thu, 14 April 2011 23:29 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 759A2E0794 for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level:
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 RXe4H8G4IAKu for <6lowpan@ietfc.amsl.com>; Thu, 14 Apr 2011 16:29:50 -0700 (PDT)
Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfc.amsl.com (Postfix) with ESMTP id 6686DE06C4 for <6lowpan@ietf.org>; Thu, 14 Apr 2011 16:29:50 -0700 (PDT)
Received: from [128.107.115.94] ([128.107.115.94]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p3ENTlW2017373 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 14 Apr 2011 16:29:47 -0700
Message-ID: <4DA78386.8050609@acm.org>
Date: Thu, 14 Apr 2011 16:30:14 -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: "6lo >> '6lowpan'" <6lowpan@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [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: Thu, 14 Apr 2011 23:29:51 -0000

On 4/13/11 12:53 AM, Pascal Thubert (pthubert) wrote:
> Hi Erik:
>
> The RPL (DAO) sequence number allows the node to increment rapidly in
> case of rapid changes and then lazily when the situation is stable and
> DAO are scarce. The increase is strictly monotonous which is critical to
> us.
>
> A time stamp imposes a synchronization between the routers. We do not
> have such mechanism in RPL. A time unit (a granularity) must be agreed
> upon. Within that unit, movements go undetected so the time unit must be
> thin grained to cover rapid changes. Yet, depending on the medium, the
> time unit, and the size of the network, it is not necessarily
> easy/possible to guarantee a strictly monotonous value with a thin
> grained time unit. And we have limited space (2 octets) and have to deal
> with wrap around, which divides the space by at least 3.
>
> So RPL went for a sequence number.

But the unstated assumption that RPL made is that all host-to-router
protocols have to now be RPL aware. That doesn't sound like good design.
A host isn't aware of whether the routers speak IS-IS or OSPF, so why do
the hosts need to be aware of RPL by passing some TID around?

> I think ND has the same need as MIP for a TID == Sequence # . We know of
> MIP; We know of RPL. We know of the backbone router operation. We know
> we'll need the TID and we know exactly why. I think we should have it in
> the 6LowPAN ND spec right away to avoid interop issues when we add RPL
> and BR operations.

I don't see a need in 6lowpan-nd for a TID; the protocol works fine
without it.
I think RPL needs to be improved to deal with reality. Isn't there a
desire for RPL to handle 4861 hosts? Those would never know about a TID.

    Erik