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

Richard Kelsey <richard.kelsey@ember.com> Wed, 13 April 2011 14:01 UTC

Return-Path: <richard.kelsey@ember.com>
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 89A6EE0756 for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 07:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 x5Az-HhvM+5z for <6lowpan@ietfc.amsl.com>; Wed, 13 Apr 2011 07:01:26 -0700 (PDT)
Received: from p01c11o143.mxlogic.net (p01c11o143.mxlogic.net [208.65.144.66]) by ietfc.amsl.com (Postfix) with ESMTP id 80271E070B for <6lowpan@ietf.org>; Wed, 13 Apr 2011 07:01:26 -0700 (PDT)
Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o143.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 5bca5ad4.0.42355.00-357.92096.p01c11o143.mxlogic.net (envelope-from <richard.kelsey@ember.com>); Wed, 13 Apr 2011 08:01:26 -0600 (MDT)
X-MXL-Hash: 4da5acb61dcb7e41-5616a159b5c8166c32bb264afdd391e5e5ad9d0a
Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 10:01:22 -0400
Date: Wed, 13 Apr 2011 10:01:42 -0400
Message-Id: <87y63e5jy1.fsf@kelsey-ws.hq.ember.com>
To: Erik Nordmark <nordmark@acm.org>
In-reply-to: <4DA4BB05.2060502@acm.org> (message from Erik Nordmark on Tue, 12 Apr 2011 13:50:13 -0700)
From: Richard Kelsey <richard.kelsey@ember.com>
References: <4DA4BB05.2060502@acm.org>
X-OriginalArrivalTime: 13 Apr 2011 14:01:22.0082 (UTC) FILETIME=[4501A820:01CBF9E3]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <richard.kelsey@ember.com>
X-SOURCE-IP: [216.236.254.3]
X-AnalysisOut: [v=1.0 c=1 a=KVkKRpFW1FcA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo]
X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=N54-gffFAAAA:8 a=04v]
X-AnalysisOut: [VrEUpRax_emHffD4A:9 a=pkOZ4nQjrgbM82pxRl4A:7 a=nAPXUAfsBmE]
X-AnalysisOut: [A:10 a=6S0-Uj1EKwx8YXQy:21 a=XrIsCJ-lWHHn7qQw:21]
Cc: 6lowpan@ietf.org
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: Wed, 13 Apr 2011 14:01:27 -0000

> Date: Tue, 12 Apr 2011 13:50:13 -0700
> From: Erik Nordmark <nordmark@acm.org>
> 
> 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.

Why is this needed?  The 6LoWPAN ND draft seems clear AROs
are sent by hosts.  Are they also sent by routers?  (I find
it very confusing that "host" sometimes is used to mean
hosts and routers and other times to mean hosts that do not
route.)  How is the router/host distinction determined when
using normal, non-6LoWPAN ND?

> > 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.
> 
> 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.

+1.  This would be really helpful.

                            -Richard Kelsey