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

Mukul Goyal <mukul@uwm.edu> Wed, 30 March 2011 00:30 UTC

Return-Path: <prvs=063031bf6=mukul@uwm.edu>
X-Original-To: 6lowpan@core3.amsl.com
Delivered-To: 6lowpan@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22DE3A6AF3 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZgt3fm5Z0ZY for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:30:26 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 9983B3A6AF2 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 17:30:26 -0700 (PDT)
Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 29 Mar 2011 19:32:04 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id BE6AC2B3EF2; Tue, 29 Mar 2011 19:29:13 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu
Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rDqVsk3hKEr; Tue, 29 Mar 2011 19:29:13 -0500 (CDT)
Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 508552B3EF3; Tue, 29 Mar 2011 19:29:13 -0500 (CDT)
Date: Tue, 29 Mar 2011 19:32:04 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Erik Nordmark <nordmark@acm.org>
Message-ID: <755301727.1444348.1301445124257.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <4D91BEDA.7080907@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.92]
X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686)
X-Authenticated-User: mukul@uwm.edu
Cc: 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 30 Mar 2011 00:30:27 -0000

Hi Erik

Thanks for clarification. This seems like an issue that falls in the 'no man's land" betwen RPL and 6lowpan.

>If this isn't the case, then a routing protocol would typically find out 
about its neighboring routers IP addresses, and from that it can decide 
to treat those IP addresses differently than the addresses assigned to 
hosts.

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.

Thanks
Mukul
 
----- Original Message -----
From: "Erik Nordmark" <nordmark@acm.org>
To: "Mukul Goyal" <mukul@uwm.edu>
Cc: "Anders Brandt" <abr@sdesigns.dk>, "6lowpan" <6lowpan@ietf.org>
Sent: Tuesday, March 29, 2011 6:13:30 AM
Subject: Re: [6lowpan] "Advertize on Behalf" flag in ARO

On 3/3/11 5:07 AM, Mukul Goyal wrote:
> Hi all
>
> Recently Anders pointed out the need for the "Advertize on Behalf"
> flag in an Address Registration Option (ARO).
>
> We would not have needed this flag if only a host could send a
> unicast NS containing an ARO. However, the way I read Section 6.5.5
> in nd-15, a 6lowpan router (6LR) can also send a unicast NS to
> another 6lowpan router. This means that a registered neighbor cache
> entry (NCE) in a 6LR could refer to either a host or another 6LR. So,
> how does a 6LR know that a registered NCE belongs to an attached host
> and it should advertize reachability to this host in the routing
> protocol, such as RPL, it is running?
>
> The proposed flag will solve this problem. A host would set
> "Advertize on behalf" flag when it sends an ARO inside a unicast NS
> message, whereas a 6LR wont.
>
> I was wondering if ND authors could comment on this.

I didn't see anybody else comment, so let me try.

I don't know what assumptions RPL makes in particular, but if we are 
talking about a general case of a routing protocol, I don't see why 
there would be a need to tell a difference between a host sending an ARO 
and a router (which might be initializing and haven't yet enabled 
routing and forwarding) sending an ARO.

In both cases I'd assume that the unicast address that is registered is 
something that should be reachable, hence it makes sense advertising 
reachability to that address.

If this isn't the case, then a routing protocol would typically find out 
about its neighboring routers IP addresses, and from that it can decide 
to treat those IP addresses differently than the addresses assigned to 
hosts.

    Erik