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

Erik Nordmark <nordmark@acm.org> Tue, 12 April 2011 20:49 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 8BD63E08AA for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:49:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.266
X-Spam-Level:
X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 yrU9Bx0Xe4uf for <6lowpan@ietfc.amsl.com>; Tue, 12 Apr 2011 13:49:50 -0700 (PDT)
Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfc.amsl.com (Postfix) with ESMTP id AD4CCE06BC for <6lowpan@ietf.org>; Tue, 12 Apr 2011 13:49:50 -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 p3CKnlL7001611 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Apr 2011 13:49:48 -0700
Message-ID: <4DA4BB05.2060502@acm.org>
Date: Tue, 12 Apr 2011 13:50:13 -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="UTF-8"; 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:49:51 -0000

On 3/29/11 5:32 PM, Mukul Goyal wrote:

> A router running RPL would not always know which of its registered
> neighbors are themselves RPL routers. This is because an RPL node
> must ignore any DIOs received from neighbors with higher (in
> numerical value) "rank". Also, a DAG parent may not receive a DAO
> from its child (In non-storing mode operation, it WON'T receive any
> DAO at all unless it is the DAG root and in storing mode, the child
> may decide not to send its DAO to this parent).
>
> Now, we have 2 options:
>
> 1) Define an "Advertize on Behalf" flag in ARO as Anders proposed and
> have hosts set this flag when they send ARO inside a unicast NS to a
> 6LR. If the host later decides to become a 6LR, it can resend the ARO
> with this flag not set.
>
> 2) Lets write a "how to run RPL on a 6lowpan" document (as Pascal has
> suggested) that will specify how a received DIO/DAO from a neighbor
> can be used to mark that neighbor as a router in the registered
> neighbor cache.

Later you wrote:
> I agree. That's why I think 6lowpan ND should provide a mechanism to
> clearly identify a registered neighbor as a 6lowpan host or a 6lowpan
> router.


Sorry for the delay.

I think #1 is both open-ended and undefined. In this case RPL doesn't
care whether the node is a router or a host; it only care whether or not
the node is an RPL speaker. Thus potentially we'd need a different flag
with slightly different semantics for different routing protocols. And
perhaps even need to add multiple flags for different versions or
options in routing protocols (e.g., some future RPLv2, or non-storing,
or something else).

My take is that with 6lowpan-nd we are following the split between
routing protocol and host-router interaction which has served the
internet well for a long time.
If one or more routing protocols need more information about its
neighboring routers, then let's put the onus on providing that in the
routing protocol; there we have the expertize and also we'd avoid having
to revise ND to add more flags just to support a new version or new
routing protocol.

Thus let's do #2 and get this written down, including the assumptions
that RPL makes about hosts, and then see how RPL can be extended to work
correctly in the presence of hosts.

My 2 cents,
     Erik