Re: [Roll] RA-DIOs and next-door destinations

Zach Shelby <zach@sensinode.com> Tue, 04 August 2009 07:45 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95EDB3A68B8 for <roll@core3.amsl.com>; Tue, 4 Aug 2009 00:45:56 -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 RbUTKUTX71BA for <roll@core3.amsl.com>; Tue, 4 Aug 2009 00:45:55 -0700 (PDT)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 088E33A6A45 for <roll@ietf.org>; Tue, 4 Aug 2009 00:45:54 -0700 (PDT)
Received: from snl-zach.local ([62.145.172.50]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id n747jqxB022432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <roll@ietf.org>; Tue, 4 Aug 2009 10:45:52 +0300
Message-ID: <4A77E731.90204@sensinode.com>
Date: Tue, 04 Aug 2009 10:45:53 +0300
From: Zach Shelby <zach@sensinode.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: roll@ietf.org
References: <87prbc5231.fsf@kelsey-ws.hq.ember.com> <B8949F83-E028-4CAE-B5E4-E74EC5531F66@archrock.com> <38F26F36EAA981478A49D1F37F474A86036E7CAF@xmb-ams-33d.emea.cisco.com>
In-Reply-To: <38F26F36EAA981478A49D1F37F474A86036E7CAF@xmb-ams-33d.emea.cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [Roll] RA-DIOs and next-door destinations
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2009 07:45:56 -0000

Hi,

I think what many people are a bit confused about is just the concept of 
neighbor communication vs. using a router to forward traffic. In IPv6 a 
node can always communicate directly with its on-link neighbors of 
course! The sending node makes the decision whether to send a packet 
directly to a neighbor or to send it through a router. This is 
independent of the routing algorithm (and a host e.g. isn't even aware 
of routing).

In IPv6 this is called next-hop determination, i.e., is this destination 
on-link (get the link-layer address of the destination and send it to 
L2) or off-link (send it to a router, which is where it is forwarded 
based on the routing table). Next-hop determination is a function of 
Neighbor Discovery. If you are using full IPv6 then see RFC4861, if 
using 6LoWPAN see draft-ietf-6lowpan-nd.

Routing protocol control traffic could of course help in the maintenance 
of the neighbor cache in IPv6, which is what Jonathan is pointing out.

- Zach

Julien Abeille (jabeille) wrote:
> Hi Jonthan,
> 
> To me learning what global addresses are assigned to neighbors is not of great help for routing, hence looks like (layer 5) service discovery. Not sure ROLL should care about this.
> 
> Cheers,
> Julien
> 
> 
>> -----Original Message-----
>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On 
>> Behalf Of Jonathan Hui
>> Sent: lundi 3 août 2009 21:38
>> To: Richard Kelsey
>> Cc: roll@ietf.org
>> Subject: Re: [Roll] RA-DIOs and next-door destinations
>>
>>
>> Hi Richard,
>>
>> On Aug 3, 2009, at 8:50 AM, Richard Kelsey wrote:
>>> In the section on RA-DIO reception, draft-dt-roll-rpl-01 
>> says that a 
>>> RA-DIO from a neighbor that is not a potential parent or a sibling 
>>> should be ignored.  Is it permissable to remember the neighbor in 
>>> order to route messages to it directly?  In other words, 
>> can a packet 
>>> whose destination is a neighbor with a greater depth be 
>> sent directly 
>>> to that neighbor?
>>
>> Let me speak to your comment directly, rather than the draft.
>>
>> I don't see any problem using the RA-DIO to figure out what 
>> neighbors are around you. One issue is that if the RA-DIO 
>> source address is a link-local address, it may not be so 
>> useful if you're trying to talk to that node using its global 
>> address. What is more useful is to allow including some kind 
>> of DAO in the same RA so that you know what addresses (other 
>> than the source address) are assigned to that node's interface.
>>
>> --
>> Jonathan Hui
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.