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

Mukul Goyal <mukul@uwm.edu> Wed, 30 March 2011 00:38 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 CF9C63A6AF8 for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:38:07 -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 YpboGnffcE1k for <6lowpan@core3.amsl.com>; Tue, 29 Mar 2011 17:38:06 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 7A3C13A6AF2 for <6lowpan@ietf.org>; Tue, 29 Mar 2011 17:38:06 -0700 (PDT)
Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 29 Mar 2011 19:39:45 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 0682F2B3EF3; Tue, 29 Mar 2011 19:36:54 -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 Vl-6NXPWVjbv; Tue, 29 Mar 2011 19:36:53 -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 9E3A92B3EF2; Tue, 29 Mar 2011 19:36:53 -0500 (CDT)
Date: Tue, 29 Mar 2011 19:39:44 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Esko Dijk <esko.dijk@philips.com>
Message-ID: <2025213060.1444573.1301445584586.JavaMail.root@mail02.pantherlink.uwm.edu>
In-Reply-To: <A337AA36B3B96E4D853E6182B2F27AE2C76B0D57D7@NLCLUEXM03.connect1.local>
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:38:08 -0000

Hi Esko

In RPL, a node can advertise reachability (in DAO messages) to its hosts and addresses in its sub-DAG. A node should (must?) not advertise reachability to any other addresses.

Also, a 6LN (host) need not know any thing about RPL at all. It can simply attach to a RPL router as a host. Any node that runs RPL is a router. An RPL leaf node is also a router.

Thanks
Mukul  

----- Original Message -----
From: "Esko Dijk" <esko.dijk@philips.com>
To: "Erik Nordmark" <nordmark@acm.org>, "Mukul Goyal" <mukul@uwm.edu>
Cc: "6lowpan" <6lowpan@ietf.org>
Sent: Tuesday, March 29, 2011 7:55:48 AM
Subject: RE: [6lowpan] "Advertize on Behalf" flag in ARO

Hello,

as far as I understand RPL reachability is indeed advertised to both 6LR/6LNs, the only distinction is that a 6LN (host) would operate as a RPL leaf node (as in section 8.5 of rpl-19). So a 6LR does not have to 'detect' first whether another node is 6LR or 6LN.

best regards,
Esko Dijk

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Erik Nordmark
Sent: Tuesday 29 March 2011 13:14
To: Mukul Goyal
Cc: 6lowpan
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
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.