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

From: Richard Kelsey <[email-masked]>
Date: Mon, 03 Aug 2009 11:50:10 -0400

ROLLers,

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?
                                  -Richard Kelsey

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 3 Aug 2009 12:37:31 -0700

Hi Richard,

> 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

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Tue, 4 Aug 2009 09:25:19 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Hui
> Sent: lundi 3 août 2009 21:38
> To: Richard Kelsey
> Cc: [email-masked]
> Subject: Re: [Roll] RA-DIOs and next-door destinations
> 
> 
> Hi Richard,
> 
> 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?
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 04 Aug 2009 10:45:53 +0300

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

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Aug 2009 15:07:49 +0200

Hi Jonathan:

If a node is a router A that owns a prefix A::/64 is near to router B that owns B::/64.

With the current text in the draft, A will advertise A::/64 to its parent using ND-DAO, and B will do the same for B::/64.
If they are lucky and are siblings sharing a same parent, then A::1 (might be A's address on A::/64) could ping B::1 via that parent. But the DAG might provide a path that's a lot worse than that.

An easy addition to the draft is to allow A to also multicast its NA-DAO to all nodes. That way, if B is in line of sight from A, B could install a route to A::/64 via A's link local regardless of their DAG relationship and forward the packets directly.

This is an easy way to address local communication between nodes. Note that if A is a host, A would advertise a host route A::1/128. 

What do you think?

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 4 Aug 2009 08:27:24 -0700

Hi Pascal,

On Aug 4, 2009, at 6:07 AM, Pascal Thubert (pthubert) wrote:
> An easy addition to the draft is to allow A to also multicast its NA- 
> DAO to all nodes. That way, if B is in line of sight from A, B could  
> install a route to A::/64 via A's link local regardless of their DAG  
> relationship and forward the packets directly.
>
> This is an easy way to address local communication between nodes.  
> Note that if A is a host, A would advertise a host route A::1/128.
>
> What do you think?

This is definitely an easy addition. I was also thinking of including  
DAOs in RAs since RAs are already sent using link-local multicast.  
Doing so would definitely reduce transmission overhead for multicast  
traffic that can be significant with some link protocols.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2009 10:09:29 +0200

Hi Jonathan:

I can see the benefit in terms of power of piggy backing things in RAs as your recent mail on DAG explained so well.

OTOH, a DAO can be used by all nodes, routers and hosts, and simplicity would suggest to leave the DAOs in NAs. 

Also, the shortcut that this proposal enables is not required in all cases, and when it is required, then there's usually the power that goes with it. For instance a high priority close control loop cannot be sleeping for eons, and thus there must be some accepted cost about it. 

Also, a deployment might really need a set of unicast link scope DAOs as opposed to a multicast. For instance, a switch and a light bulb need to talk to one another but the stereo gear does not care. IOW, when energy is the real constraint, the service discovery might be multicast but the maintenance and in particular the DAOs could be unicast.

Need more digging but there seems to be a direction there...

Pascal

>From: Jonathan Hui [mailto:[email-masked]]
>Sent: mardi 4 août 2009 17:27
>To: Pascal Thubert (pthubert)
>Cc: Richard Kelsey; [email-masked]