Subject: [Roll] Fw: Next items ... (amended list)

From: [email-masked]
Date: Tue, 4 Aug 2009 11:56:02 -0500

JP,

RPL currently makes no mention of sleepy devices.  These will be very 
commonplace in WSNs.  I would like to amend my list below and add sleepy 
device management.  RPL needs to state what happens to packets routed to 
sleepy devices while they are asleep.  Are they dropped?  Will a proxy 
manage the packet until the device awakens? Will the last router return an 
error to the source?

----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 
11:43 AM -----

[email-masked] 
Sent by: [email-masked]
08/03/2009 01:09 PM

To
JP Vasseur <[email-masked]>
cc
ROLL WG <[email-masked]>
Subject
Re: [Roll] Next items ...

I would like the following questions answered on subsequent revisions of 
the draft: 

a) What is the roll of 'siblings'?  They are in the current RPL document, 
yet seem to be demoted from parental links.  As I read the draft, one 
cannot use a sibling link unless the parental links are exhausted.  The 
nodes don't seem to explicitly define sibling links.   

b) What is the plan on communication to devices within direct radio range? 
 As I read the draft unless a node is made a 'parent', or possibly a 
'sibling' it cannot be communicated with.  However, Anand mentions in his 
memo that at the Stockholm meeting there was discussion on directly 
connected devices.  Unfortunately, I couldn't attend the meeting. 

c) What are the approximate timer values for RPL?  The document gives no 
indication as to these timers, hence I can't calculate how long a floating 
DAG may be dislodged from its network.  In a real-time facility management 
control system, all nodes are monitored for falling off-line.  If the 
convergence time is too long (more than 1 minute), the devices will be 
flagged off-line and reported to the customer. 

d) What is the plan for security?  RPL doesn't currently weigh in on the 
topic.  Are security policies optional or mandatory?  Must the policy be 
consistent with the rest of the enterprise's IT security on other parts of 
the network?  Will security require nodes to keep state info as Rene 
suggests? 

e) What requirements from the 4 requirement drafts are being considered? 
When the DT first was engaged, it said it would publish the list of 
requirements as an appendix and note if the current draft supported which 
requirement.  This hasn't occurred and may be adding to the email angst. 
As a requirement's author, I would rather know up front that some of my 
MUST requirements are not being considered. 

f) What is the expected frame overhead size based on all the above 
criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation, 
UDP/TCP.  We need to add in the encryption and authentication overhead; 
and now maybe source routing.  I realize ROLL is trying to be agnostic to 
L2, however in practice 802.15.4 is the only game in town.  It only 
carries a 128 by packet size.  The DT/WG should at least give an 
accounting of the expected frame overhead so we can determine what L2s are 
feasible for the protocol. 

g) What routing data must persist a warmstart/coldstart?  The overhead to 
establish a DAG is significant.  We should consider what data might be 
able to transcend a network reboot to minimize communication startup 
bottlenecks. 

h) How will packets routed to asleep devices be handled?  will they be 
dropped? buffered by a proxy? will a router return an 'asleep' error to 
the source?  

As Pascal has noted in previous emails, some of these issues may be 
considered out-of bounds for the protocol and should be an implementation 
decision.  That may indeed be true, but RPL should state its case 
explicitly.  In the Building Market, it is multi-disciplined (HVAC, Fire, 
Lighting) and multi-vendor.  Unless some higher authority prescribes 
operation, the chances of LLN node-to-node interoperability are moot. 

Thanks, 

Jerry 

JP Vasseur <[email-masked]> 
Sent by: [email-masked] 
08/03/2009 02:27 AM 

To
ROLL WG <[email-masked]> 
cc

Subject
[Roll] Next items ...

Dear all,

As a reminder, RPL being a WG ID, it now "belongs" to the WG.

Several working items have been listed but before starting to address 
all open items in some unstructured way, I would like to propose the 
following.

It clearly appeared that there were some misunderstandings on how RPL 
works. The DT did an outstanding job but I also understand that 
several areas must be clarified. So before changing RPL, adding new 
mechanisms (e.g. to optimize P2P, support source routing, loop 
detection, ... ), I would first want you to list your questions on the 
mailing list on each area for which you would like to get 
clarification. This will help make sure that everybody is indeed on 
the same page.

>From there, we will continue to quickly move forward, I will track 
the list of open items via the issue tracker.

Many Thanks.

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

---

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

Hi Jerry:

This is a very good point. Long debated at 6LoWPAN, I suggest you dig into the ML'logs on the web to find out what people said.

My own conclusion:

-          This is an adaptation layer problem, not a L3 problem

o   Some MACs are time synchronized or scheduled so it's not an issue there

o   Some MACs use long preamble to wait for sleeping nodes and the methed appears to do well too.

-          Yet L3 has to be designed intelligently to cope with that, in particular by reducing the need of multicast

o   This is what 6LoWPAN ND does with the whiteboard mechanism

o   This is what RPL does with the DAGs and DAOs as Jonathan explained so well in the "why a DAG" discussion

The way I see it, some adaptation layers might want to make multicast a bit more reliable and such an adaptation layer could actually transform multicast in a series of unicast that is adapted to the sleep sequence of the devices. In fact, it makes a lot more sense to cache RAs in a router than it does in a WIFI access point.

DAOs can (and should) be used to advertise mcast listeners. I'm pretty sure this will end up properly spelled out in the spec. The same process could also be used to ask a router to store and forward FF02::1 between its attached nodes.

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: mardi 4 août 2009 18:56
To: JP Vasseur (jvasseur)
Cc: ROLL WG
Subject: [Roll] Fw: Next items ... (amended list)

JP, 

RPL currently makes no mention of sleepy devices.  These will be very commonplace in WSNs.  I would like to amend my list below and add sleepy device management.  RPL needs to state what happens to packets routed to sleepy devices while they are asleep.  Are they dropped?  Will a proxy manage the packet until the device awakens? Will the last router return an error to the source? 

----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 11:43 AM ----- 

08/03/2009 01:09 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

		

I would like the following questions answered on subsequent revisions of the draft: 

a) What is the roll of 'siblings'?  They are in the current RPL document, yet seem to be demoted from parental links.  As I read the draft, one cannot use a sibling link unless the parental links are exhausted.  The nodes don't seem to explicitly define sibling links.   

b) What is the plan on communication to devices within direct radio range?  As I read the draft unless a node is made a 'parent', or possibly a 'sibling' it cannot be communicated with.  However, Anand mentions in his memo that at the Stockholm meeting there was discussion on directly connected devices.  Unfortunately, I couldn't attend the meeting. 

c) What are the approximate timer values for RPL?  The document gives no indication as to these timers, hence I can't calculate how long a floating DAG may be dislodged from its network.  In a real-time facility management control system, all nodes are monitored for falling off-line.  If the convergence time is too long (more than 1 minute), the devices will be flagged off-line and reported to the customer. 

d) What is the plan for security?  RPL doesn't currently weigh in on the topic.  Are security policies optional or mandatory?  Must the policy be consistent with the rest of the enterprise's IT security on other parts of the network?  Will security require nodes to keep state info as Rene suggests? 

e) What requirements from the 4 requirement drafts are being considered?  When the DT first was engaged, it said it would publish the list of requirements as an appendix and note if the current draft supported which requirement.  This hasn't occurred and may be adding to the email angst.  As a requirement's author, I would rather know up front that some of my MUST requirements are not being considered. 

f) What is the expected frame overhead size based on all the above criteria?  6LoWPAN requires subheader overhead for mesh, fragmentation, UDP/TCP.  We need to add in the encryption and authentication overhead; and now maybe source routing.  I realize ROLL is trying to be agnostic to L2, however in practice 802.15.4 is the only game in town.  It only carries a 128 by packet size.  The DT/WG should at least give an accounting of the expected frame overhead so we can determine what L2s are feasible for the protocol. 

g) What routing data must persist a warmstart/coldstart?  The overhead to establish a DAG is significant.  We should consider what data might be able to transcend a network reboot to minimize communication startup bottlenecks. 

h) How will packets routed to asleep devices be handled?  will they be dropped? buffered by a proxy? will a router return an 'asleep' error to the source?  

As Pascal has noted in previous emails, some of these issues may be considered out-of bounds for the protocol and should be an implementation decision.  That may indeed be true, but RPL should state its case explicitly.  In the Building Market, it is multi-disciplined (HVAC, Fire, Lighting) and multi-vendor.  Unless some higher authority prescribes operation, the chances of LLN node-to-node interoperability are moot. 

Thanks, 

Jerry 

08/03/2009 02:27 AM 

To

ROLL WG <[email-masked]> 

cc

Subject

[Roll] Next items ...

Dear all,

Many Thanks.

JP.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 6 Aug 2009 12:04:27 +0200

Hi all,
 
a few more items:
[Packet format] Clarify the rationale to use RAs/NAs. More precisely: 
- are RAs sent for router discovery/prefix discovery the same as those used by ROLL (same timer). 
-- If yes, does it impact the way router discovery/prefix discovery work (preformance, do they really have the same timing constraints?)
-- if yes, what is the approach with regards to update of RFC4861 (6lowpan-nd is not in scope in my opinion as it is L2 dependant, while ROLL is not)?
-- if not, why not using a specific packet?
- NA: 
-- Are NAs sent for ROLL used for anything else? If not why not use a specific packet to carry DAOs?
-- NAs are already pretty overloaded (DAD, NUD, Address resolution), using a different packet may bring NA processing complexity down. 
 
Best,
Julien

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
	Sent: mercredi 5 août 2009 09:59
	To: [email-masked]; JP Vasseur (jvasseur)
	Cc: ROLL WG
	Subject: Re: [Roll] Fw: Next items ... (amended list)

	Hi Jerry:

	My own conclusion:

	Pascal

	
	
	JP, 

	----- Forwarded by Jerald P Martocci/CORP/Johnson_Controls on 08/04/2009 11:43 AM ----- 

08/03/2009 01:09 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

		

	

	

	

	Thanks, 
	
	Jerry 

08/03/2009 02:27 AM 

To

ROLL WG <[email-masked]> 

cc

Subject

[Roll] Next items ...

	

	Dear all,

	

	Many Thanks.
	
	JP.

---

From: Zach Shelby <[email-masked]>
Date: Fri, 07 Aug 2009 09:17:43 +0300

Julien,

Julien Abeille (jabeille) wrote:
> -- If yes, does it impact the way router discovery/prefix discovery work 
> (preformance, do they really have the same timing constraints?)
> -- if yes, what is the approach with regards to update of RFC4861 
> (6lowpan-nd is not in scope in my opinion as it is L2 dependant, while 
> ROLL is not)?

As many 6LoWPAN vendors will be making use of RPL for routing, we should 
definitely define the binding of RPL to 6LoWPAN-ND in addition to 
RFC4861. But I think this was already the plan?

Although 6LoWPAN-ND isn't tied to just IEEE 802.15.4, it does target a 
class of link-layer technologies. The timings might already be more 
appropriate for RPL, but that should be checked as well. We are in the 
process of defining periods and timeouts next week for nd-05 so if ROLL 
has any requirements now is the time. As Jonathan and Pascal are authors 
of both, you guys can already take it into account.

When using RPL with 6LoWPAN-ND we would of course piggyback DAOs on Node 
Registration message flows which are sent periodically to the ER anyways.

Zach

> -- NAs are already pretty overloaded (DAD, NUD, Address resolution), 
> using a different packet may bring NA processing complexity down.

> Best,
> Julien
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Pascal Thubert (pthubert)
>     *Sent:* mercredi 5 août 2009 09:59
>     *To:* [email-masked]; JP Vasseur (jvasseur)
>     *Cc:* ROLL WG
>     *Subject:* Re: [Roll] Fw: Next items ... (amended list)
> 
>     Hi Jerry:
> 
>      
> 
>     This is a very good point. Long debated at 6LoWPAN, I suggest you
>     dig into the ML’logs on the web to find out what people said.
> 
>      
> 
>     My own conclusion:
> 
>     o   Some MACs are time synchronized or scheduled so it’s not an
>     issue there
> 
>     -          Yet L3 has to be designed intelligently to cope with
>     that, in particular by reducing the need of multicast
> 
>     o   This is what RPL does with the DAGs and DAOs as Jonathan
>     explained so well in the “why a DAG” discussion
> 
>      
> 
>     The way I see it, some adaptation layers might want to make
>     multicast a bit more reliable and such an adaptation layer could
>     actually transform multicast in a series of unicast that is adapted
>     to the sleep sequence of the devices. In fact, it makes a lot more
>     sense to cache RAs in a router than it does in a WIFI access point.
> 
>      
> 
>     DAOs can (and should) be used to advertise mcast listeners. I’m
>     pretty sure this will end up properly spelled out in the spec. The
>     same process could also be used to ask a router to store and forward
>     FF02::1 between its attached nodes.
> 
>      
> 
>     Pascal
> 
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of [email-masked]
>     *Sent:* mardi 4 août 2009 18:56
>     *To:* JP Vasseur (jvasseur)
>     *Cc:* ROLL WG
>     *Subject:* [Roll] Fw: Next items ... (amended list)
> 
>      
> 
> 
> 
>     JP,
> 
>     RPL currently makes no mention of sleepy devices.  These will be
>     very commonplace in WSNs.  I would like to amend my list below and
>     add sleepy device management.  RPL needs to state what happens to
>     packets routed to sleepy devices while they are asleep.  Are they
>     dropped?  Will a proxy manage the packet until the device awakens?
>     Will the last router return an error to the source?
> 
> 
>     [email-masked]*
>     a) What is the roll of 'siblings'?  They are in the current RPL
>     document, yet seem to be demoted from parental links.  As I read the
>     draft, one cannot use a sibling link unless the parental links are
>     exhausted.  The nodes don't seem to explicitly define sibling links.  
> 
>     b) What is the plan on communication to devices within direct radio
>     range?  As I read the draft unless a node is made a 'parent', or
>     possibly a 'sibling' it cannot be communicated with.  However, Anand
>     mentions in his memo that at the Stockholm meeting there was
>     discussion on directly connected devices.  Unfortunately, I couldn't
>     attend the meeting.
> 
>     c) What are the approximate timer values for RPL?  The document
>     gives no indication as to these timers, hence I can't calculate how
>     long a floating DAG may be dislodged from its network.  In a
>     real-time facility management control system, all nodes are
>     monitored for falling off-line.  If the convergence time is too long
>     (more than 1 minute), the devices will be flagged off-line and
>     reported to the customer.
> 
>     d) What is the plan for security?  RPL doesn't currently weigh in on
>     the topic.  Are security policies optional or mandatory?  Must the
>     policy be consistent with the rest of the enterprise's IT security
>     on other parts of the network?  Will security require nodes to keep
>     state info as Rene suggests?
> 
>     e) What requirements from the 4 requirement drafts are being
>     considered?  When the DT first was engaged, it said it would publish
>     the list of requirements as an appendix and note if the current
>     draft supported which requirement.  This hasn't occurred and may be
>     adding to the email angst.  As a requirement's author, I would
>     rather know up front that some of my MUST requirements are not being
>     considered.
> 
>     criteria?  6LoWPAN requires subheader overhead for mesh,
>     fragmentation, UDP/TCP.  We need to add in the encryption and
>     authentication overhead; and now maybe source routing.  I realize
>     ROLL is trying to be agnostic to L2, however in practice 802.15.4 is
>     the only game in town.  It only carries a 128 by packet size.  The
>     DT/WG should at least give an accounting of the expected frame
>     overhead so we can determine what L2s are feasible for the protocol.
> 
>     g) What routing data must persist a warmstart/coldstart?  The
>     overhead to establish a DAG is significant.  We should consider what
>     data might be able to transcend a network reboot to minimize
>     communication startup bottlenecks.
> 
>     *h) How will packets routed to asleep devices be handled?* * will
>     they be dropped? buffered by a proxy? will a router return an
>     'asleep' error to the source? * 
> 
>     considered out-of bounds for the protocol and should be an
>     implementation decision.  That may indeed be true, but RPL should
>     state its case explicitly.  In the Building Market, it is
>     multi-disciplined (HVAC, Fire, Lighting) and multi-vendor.  Unless
>     some higher authority prescribes operation, the chances of LLN
>     node-to-node interoperability are moot.
> 
>     Thanks,
> 
>     Jerry
> 
> 
>     *JP Vasseur <[email-masked]>*
> ------------------------------------------------------------------------
> 

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