Subject: [Roll] RPL Design Question: DIO/DAO Transport

From: Tim Winter <[email-masked]>
Date: Thu, 15 Oct 2009 13:23:43 -0400

WG,

There has been some feedback regarding the implications of using Neighbor
Discovery RA/NA to carry DIO/DAO for RPL.  The functionality provided by
DIO/DAO may be seen as a natural extension to ND, but there are concerns
regarding the implications of overloading ND for use by RPL.  Another option
would be to request the allocation of ICMP messages to transport the DIO/DAO.

What do you think?
	1) Let RPL use RA/NA for DIO/DAO transport
	2) Allocate 2 new ICMP messages for DIO/DAO and operate independent of ND

Please do keep in mind that this would serve as a base recommendation for
the core protocol, and does not necessarily preclude that another
implementation-specific binding outside of the scope of RPL (e.g. 6LowPAN)
may do things differently.

Thanks,

-RPL Authors

---

From: Michael Richardson <[email-masked]>
Date: Thu, 15 Oct 2009 15:31:00 -0400

>>>>> "Tim" == Tim Winter <[email-masked]> writes:
    Tim> What do you think?

I think that I do not have enough information yet.
I would like to spend some more time understanding how RPL and 6LoWPAN
interact.  

In particular, if we use RA/NA for DIO, will it work to use NR/NC
instead messages in 6LoWPAN, or does it create a chicken/egg problem.

I have an email from Pascal to properly understand and reply to, so can
we defer this decision a week?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 16 Oct 2009 09:11:58 +0200

Hi Tim,

I would vote for 2).
My impression is that it would be more flexible (no contradictory
interaction between ND timers and RPL timers). I also think it would
allow for a cleaner implementation of RPL (clearer separation between
the routing algorithm functionalities and the NS/NA processing).

Best,
Mathilde 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Winter
Sent: jeudi, 15. octobre 2009 19:24
To: ROLL WG
Subject: [Roll] RPL Design Question: DIO/DAO Transport

WG,

There has been some feedback regarding the implications of using
Neighbor Discovery RA/NA to carry DIO/DAO for RPL.  The functionality
provided by DIO/DAO may be seen as a natural extension to ND, but there
are concerns regarding the implications of overloading ND for use by
RPL.  Another option would be to request the allocation of ICMP messages
to transport the DIO/DAO.

What do you think?
	1) Let RPL use RA/NA for DIO/DAO transport
	2) Allocate 2 new ICMP messages for DIO/DAO and operate
independent of ND

Please do keep in mind that this would serve as a base recommendation
for the core protocol, and does not necessarily preclude that another
implementation-specific binding outside of the scope of RPL (e.g.
6LowPAN) may do things differently.

Thanks,

-RPL Authors
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Zach Shelby <[email-masked]>
Date: Fri, 16 Oct 2009 10:21:57 +0300

> 	2) Allocate 2 new ICMP messages for DIO/DAO and operate independent  

I vote for 2.

I agree with many on the list that it is a cleaner separation  
regarding timers and implementation. As there will be some differences  
as well between RFC4861 and 6LoWPAN-ND  - this also makes RPL  
universal for both regarding DIO/DAO.

> may do things differently.

This makes sense. I would find it useful if RPL would specify the DIO/ 
DAO messages in such a way that they could be easily carried as an  
ICMP option piggybacked e.g. on ND messages in an implementation- 
specific binding.

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: Zach Shelby <[email-masked]>
Date: Fri, 16 Oct 2009 10:27:28 +0300

> instead messages in 6LoWPAN, or does it create a chicken/egg problem.

Sure, it would work nicely in my opinion (no chicken/egg problems).  
However it makes the RPL specification much simpler and cleaner,  
avoids timing problems and a mangled implementation if the base  
protocol assumes its own messages. And right now RPL needs serious  
simplification.

That said, the design team has the right approach that if a vendor or  
specific application of RPL wanted to, they could decide to bind DIO/ 
DAO on other ICMP messages such as ND-specific ones. Such a binding  
should be specified in a separate I-D later on if found useful by a  
critical mass.

Zach

>   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE 
> >
> 	               then sign the petition.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 Oct 2009 09:58:57 +0200

Hi Tim:

I vote for reusing what's already there because it may provide a lighter
footprint in additional code and airspace for RPL. That was true for me
but I understand it might not be for every other implementation. So I
vote for 1)

I am not too concerned about the timer mangling because the rate of ND
messages caused by RPL will not cause any damage for which ND throttling
is designed. Just a different order of magnitude in rates.

What I really care for is a protocol that can be bound on several things
like but not limited to RFC 4861. RA is closer in essence to what DIO
needs than NA is for DAO but that's a start.

And I am concerned with the Pandora box effect. Once we go along the
path of having our own messages, we'll start wondering on our own hello
protocol that evaluates links and metrics, and from there where do we
stop? Considering the other issues we have to deal with at this time,
like the loop avoidance and detection mechanisms that are under poll, I
would not waste cycles on opening that box for the time being. Maybe
later when we understand better what we do in fine.

And when/if 6LoWPAN ND comes out, I'll probably be proposing another
binding to replace NA with NR in that space because is it a lot cleaner
semantically.

Pascal

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mathilde Durvy (mdurvy)
>Sent: vendredi 16 octobre 2009 09:12
>To: Tim Winter; ROLL WG
>Subject: Re: [Roll] RPL Design Question: DIO/DAO Transport
>
>Hi Tim,
>
>I would vote for 2).

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 16 Oct 2009 10:09:25 +0200

Hi all,

I also vote for 2 for the same reasons.
Best,
Julien

> independent 
> > of ND
> 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
>

---

From: Owen Kirby <[email-masked]>
Date: Fri, 16 Oct 2009 10:43:01 -0700

Hi Tim,

I would also like to cast my vote for option 2 for the same reasons.

Thanks,
Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Oct 2009 19:55:16 +0200

Tim Winter a écrit :
> Discovery RA/NA to carry DIO/DAO for RPL.

Sorry, what was that feedback?

Which link layer was that feedback using?

(I am not sure here we have a clear idea about the link layers used by
  RPL - or I may have missed something).

> The functionality provided by

How about 3) use RA Flags Option RFC5175?

Alex

---

From: JP Vasseur <[email-masked]>
Date: Mon, 19 Oct 2009 08:05:07 -0700

Hi Tim,

On Oct 15, 2009, at 10:23 AM, Tim Winter wrote:

> Neighbor

Voting for 2) mainly to avoid timers and state machine dependency.

Thanks.

JP.

---

From: Tim Winter <[email-masked]>
Date: Fri, 23 Oct 2009 13:38:33 -0400

WG,

Based on feedback to the list we will proceed to decouple the DIO/DAO
messages from the IPv6 ND transport (RA-DIO -> DIO, NA-DAO -> DAO), and
request the allocation of a new ICMP message to transport the DIO/DAO.

The decoupling in the text will also make it easier for other use cases,
e.g. 6LowPAN, to specify their own bindings when appropriate.

Any further comments/feedback?

Thanks,

-RPL Authors

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Oct 2009 20:19:41 +0200

Tim Winter a écrit :
>  messages from the IPv6 ND transport (RA-DIO -> DIO, NA-DAO -> DAO), 
> and request the allocation of a new ICMP message to transport the 
> DIO/DAO.

Tim, do you mean new ICMP message Types?  Or code fields?  Or both?
The current ICMP types and codes are:
http://www.iana.org/assignments/icmpv6-parameters

"IPv6 ND transport" is actually ICMP because ND is nothing else than an
ICMP message type.

In this sense, you propose to decouple something from ICMP but still use
ICMP(?)

The ICMP message Types have often a Request-Response semantics (NS-NA,
Echo Req-Echo Rep, HAADReq-HAADRep, etc.).  The DIO and DAO are not so -
they seem to be DAG Information Option and Destination Advertisement
Option - simply information.

Or maybe you plan to design new ICMP Types RPL-Request and RPL-Reply
that each may carry both a DIO and a DAO?  (I am purely speculating here).

> The decoupling in the text will also make it easier for other use 
> cases, e.g. 6LowPAN, to specify their own bindings when appropriate.

Errr... but 6LoWPAN does a special "6LoWPAN ND" which is extensions to 
RS-RA and NS-NA, and they also request two new ICMP message types 
Node-Reg/Conf (which I suppose would be different than RPL's).

What do you mean by making it easier for 6LoWPAN to specify their own 
bindings?  Bindings of what?  (6LoWPAN "binding" is also a relationship 
between two addresses in the router).

How about a unique RPL6LoWPAN Req/Response ICMP Type new pair?

Alex

>> Neighbor Discovery RA/NA to carry DIO/DAO for RPL.  The 
>> functionality provided by DIO/DAO may be seen as a natural 
>> extension to ND, but there are concerns regarding the implications 
>> of overloading ND for use by RPL.  Another option would be to 
>> request the allocation of ICMP messages to transport the DIO/DAO.
>> 
>> What do you think? 1) Let RPL use RA/NA for DIO/DAO transport 2) 
>> Allocate 2 new ICMP messages for DIO/DAO and operate independent of
>>  ND
>> 
>> Please do keep in mind that this would serve as a base 
>> recommendation for the core protocol, and does not necessarily 
>> preclude that another implementation-specific binding outside of 
>> the scope of RPL (e.g. 6LowPAN) may do things differently.
>> 
>> 
>> Thanks,
>> 
>> -RPL Authors _______________________________________________ Roll 
>> mailing list [email-masked] 
> _______________________________________________ Roll mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>