Subject: [Roll] Moving forward with the protocol work

From: JP Vasseur <[email-masked]>
Date: Tue, 28 Jul 2009 18:34:24 +0200

Dear WG,

First of all, thanks for all the time and energy you all have devoted  
during the past few weeks on the protocol work. There was excellent  
followup discussion at the physical WG meeting.

To the question "Do you think that RPL provides an adequate foundation  
for the ROLL routing protocol work", there was clearly a good  
consensus in the WG meeting. It was also recognized there are still  
several open issues for which we WILL need help from many WG  
contributors, including the authors of other documents.

Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01  
as a WG document ?

Then we will of course move to the next step.

Thanks,

JP and David

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 28 Jul 2009 09:59:36 -0700

Hi JP,

I am in support of adopting the RPL proposal as the foundation for the ROLL
routing protocol work.

Best Regards,

Don Sturek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur
Sent: Tuesday, July 28, 2009 9:34 AM
To: ROLL WG
Subject: [Roll] Moving forward with the protocol work

Dear WG,

Thanks,

JP and David

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

---

From: [email-masked]
Date: Tue, 28 Jul 2009 12:40:00 -0500

I cannot yet affirm RPL as a working group draft since it hasn't yet 
stated how P2P communication will operate within the DAG. 

As I have noted in my review comments, connectivity to every node within 
the DAG is not assured.  The traffic patterns within the LLN are also 
suspect since most packets must travel upward toward the LBR before 
finding their intended destination lower in the DAG.  This imbalance will 
create network traffic congestion in the higher layers of the DAG. Hopping 
many hops up the DAG and back down the DAG to talk to a node that is in 
direct radio range seems totally inefficient.

Latency and convergence time are also a concern.  However, I can wait for 
simulation or implementations to ferret out these issues.

Regards,

Jerry Martocci

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
07/28/2009 11:36 AM

To
ROLL WG <[email-masked]>
cc

Subject
[Roll] Moving forward with the protocol work

Dear WG,

Thanks,

JP and David

---

From: Mischa Dohler <[email-masked]>
Date: Wed, 29 Jul 2009 01:41:00 +0200

Jerry, I am not sure this was already discussed at the meeting in person 
but I think we are a little in a catch22 situation here since - as far 
as I remember - none of the requirement docs explicitly required (MUST) 
p2p situations. I gather that the design team did take these documents 
as their working basis which is why p2p is not efficiently supported. In 
our urban requirements draft, we actually did go as far as saying that 
p2p should not be the main design thrust but rather the highly 
directional data flows towards a few sinks. Mischa.

[email-masked] wrote:
> finding their intended destination lower in the DAG.  This imbalance 
> will create network traffic congestion in the higher layers of the DAG. 
>  Hopping many hops up the DAG and back down the DAG to talk to a node 
> that is in direct radio range seems totally inefficient.
> 
> Latency and convergence time are also a concern.  However, I can wait 
> for simulation or implementations to ferret out these issues.
> 
> Regards,
> 
> Jerry Martocci
> 
> 
> 
> 
> 
> *JP Vasseur <[email-masked]>*
> ------------------------------------------------------------------------
>

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 28 Jul 2009 19:13:46 -0500 (CDT)

Mischa,

I am not speaking for Jerry but P2P flows are important in LLN applications I am familiar with (which happen to be in commercial building domain). I will have to go back to all the requirements drafts but I would be surprised if other domains will not benefit from an efficient P2P solution.

The main question is why are we insisting on "one solution fits all" approach??? Why can't we recognize that different applications have different requirements and offer multiple solutions (including RPL).

Let RPL be used by applications that find it useful but we should not force RPL as the only solution available.

In my view, RPL has the following three shortcomings:

1) Does not offer optimal/good P2P routing
2) Does not allow destinations other than LBRs to be advertised. Note that this point and the previous one are independent.
3) Insistence on using DAG as the loop prevention mechanism.

RPL is a good MP2P solution but we should not force it down the throats of people who want good P2P routing as well.

IETF has a long history of offering multiple solutions for a given routing problem. We has multiple interior gateway protocols, multiple MANET solutions, multiple OSPF-MANET solutions. Why can't, and why should not, we have multiple ROLL solutions??

I asked this question to JP right at the time the ROLL WG got a new charter. The answer I got was - we will work on one solution for now but we do not exclude other solutions.

I think ROLL should offer multiple solutions and let an application choose what fits it best.

Thanks
Mukul

---

From: JP Vasseur <[email-masked]>
Date: Wed, 29 Jul 2009 05:25:04 +0200

Hi Mukul,

I would really like to get your answer on whether you support the  
adoption of RPL as good foundation to move forward, adopting it as a  
WG ID. Your comments are extremely valid, see in line:

On Jul 29, 2009, at 2:13 AM, Mukul Goyal wrote:

> Mischa,
>
> I am not speaking for Jerry but P2P flows are important in LLN  
> applications I am familiar with (which happen to be in commercial  
> building domain). I will have to go back to all the requirements  
> drafts but I would be surprised if other domains will not benefit  
> from an efficient P2P solution.
>
> The main question is why are we insisting on "one solution fits all"  
> approach??? Why can't we recognize that different applications have  
> different requirements and offer multiple solutions (including RPL).
>
> Let RPL be used by applications that find it useful but we should  
> not force RPL as the only solution available.
>
> 2) Does not allow destinations other than LBRs to be advertised.  
> Note that this point and the previous one are independent.
> RPL is a good MP2P solution but we should not force it down the  
> throats of people who want good P2P routing as well.
>
> IETF has a long history of offering multiple solutions for a given  
> routing problem. We has multiple interior gateway protocols,  
> multiple MANET solutions, multiple OSPF-MANET solutions. Why can't,  
> and why should not, we have multiple ROLL solutions??
>
> I asked this question to JP right at the time the ROLL WG got a new  
> charter. The answer I got was - we will work on one solution for now  
> but we do not exclude other solutions.
>

Few things:

1) The ROLL routing protocol will have to support a good solution for  
P2P, this is a MUST requirement. For the time being a solution such as  
RPL is optimized for P2MP and P2MP and does support P2P but that MUST  
be improved. This was discussed and agreed yesterday during the WG  
meeting and on the mailing list. Next step is to work on this and your  
help will be greatly appreciated.
2) The DT will reply but RPL support the advertisements of destination  
other than LBRs
3) Loop detection: fully agree, I had proposed myself a solution but  
others may have other ideas. I personally think that this is one of  
the areas where we can borrow some ideas also from the DADR proposal.  
Again to be discussed on the list.
4) With regards to having more protocols, we are chartered to design  
one protocol for the time being. There is still lot of work to do, and  
the solution will continue to evolve. It is thus premature to think  
more than one protocol at this stage.

Thanks.

JP.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Wed, 29 Jul 2009 09:50:07 +0200

+1.
Best,
Julien 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Don Sturek
> Sent: mardi 28 juillet 2009 19:00
> To: JP Vasseur (jvasseur); 'ROLL WG'
> I am in support of adopting the RPL proposal as the 
> foundation for the ROLL routing protocol work.
> 
> Best Regards,
> 
> Don Sturek
> 
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JP Vasseur
> First of all, thanks for all the time and energy you all have 
> devoted during the past few weeks on the protocol work. There 
> was excellent followup discussion at the physical WG meeting.
> 
> To the question "Do you think that RPL provides an adequate 
> foundation for the ROLL routing protocol work", there was 
> clearly a good consensus in the WG meeting. It was also 
> recognized there are still several open issues for which we 
> WILL need help from many WG contributors, including the 
> authors of other documents.
> 
> Could you please confirm (or not) the adoption of 
> draft-dt-roll-rpl-01 as a WG document ?
>

---

From: "Robert Power" <[email-masked]>
Date: Wed, 29 Jul 2009 04:16:32 -0400

Hello JP & WG,

While we all acknowledge that the draft-dt-roll-rpl-01 document is not
complete, it is a solid framework and has the main elements that are
required from the protocol and presents a solid document from which to
move forward.  

I think we all realize that the current P2P solution is non optimal and
we will strive to improve it.  In the networks we have deployed, the
main traffic pattern is P2MP and I am satisfied that we have a solid
solution there and am OK with us moving forward and committing to find a
better P2P solution.   I do believe that P2P can be improved within RPL
and does not require an entirely new protocol. 

In my opinion, moving this draft forward as a WG document is the best
path forward to allow us to focus our efforts and drive toward
completion.

-regards, Bob

> Sent: Tuesday, July 28, 2009 6:34 PM
> To: ROLL WG
> devoted  
> foundation

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 29 Jul 2009 02:17:19 -0700

Hi JP/David,

Based on yesterdays presentations, it makes sense to me for RPL draft to
move forward and work with DADR team to take advantage of their work on
loop-detection and the cost based on historical information on packet
forwarding.
But, I am not sure if we want to adopt this as standards track wg document,
as some of the ideas need more experiments to prove that would work
correctly.

But, I agree with Mukul that RPL draft has weaknesses and for that matter
multiple protocol might be needed in the future. So, is it possible to adopt
RPL-draft+some of DADR ideas as an experimental wg draft? Once we have more
data on RPL design we can move that to standards track with changes based on
test results?
That way, we can make sure that the design is solid and the standard
documentation will be a mature one.

Thanks,
-Samita

> Sent: Tuesday, July 28, 2009 8:25 PM
> To: Mukul Goyal
> Cc: ROLL WG
> I would really like to get your answer on whether you support the adoption
> of RPL as good foundation to move forward, adopting it as a WG ID. Your
> comments are extremely valid, see in line:
> 
> > drafts but I would be surprised if other domains will not benefit from
> > an efficient P2P solution.
> >
> > Let RPL be used by applications that find it useful but we should not
> > force RPL as the only solution available.
> >
> > routing problem. We has multiple interior gateway protocols, multiple
> > MANET solutions, multiple OSPF-MANET solutions. Why can't, and why
> > should not, we have multiple ROLL solutions??
> >

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 29 Jul 2009 11:18:54 +0200

Hi JP, All,

I also support the RPL proposal as the foundation for the ROLL routing
protocol work. 

I think the current RPL proposal is very promising and we should all
work towards improving it. Maybe a good start would be to better
highlight the key basic mechanisms on which RPL is based in order to
propose a simple foundation layer on which to build and solve the
remaining issues.

I would personally want to see more discussion on 3 topics where I'm
still not fully convinced:
- the role of siblings: this adds quite some extra complexity to the
routing but what does it really bring in practice?
- if the choice of possible metrics is specified in the metric draft,
why not impose the right conditions on these metrics so that we can base
the DAG construction and the loop avoidance on a single metric rather
than have a separate hop count or depth?
- interaction between timers: I'm thinking in particular of the
interaction of the RA timers and the DAG hop timers. In the loop
avoidance example given by Jonathan yesterday can we guarantee the right
sequencing of RA / DAG Hop timer firing?

Best,
Mathilde

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
JP Vasseur (jvasseur)
Sent: mardi, 28. juillet 2009 18:34
To: ROLL WG
Subject: [Roll] Moving forward with the protocol work

Dear WG,

To the question "Do you think that RPL provides an adequate foundation
for the ROLL routing protocol work", there was clearly a good consensus
in the WG meeting. It was also recognized there are still several open
issues for which we WILL need help from many WG contributors, including
the authors of other documents.

Thanks,

JP and David

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 29 Jul 2009 11:27:31 +0200

Hi,

I agree, sibling can be viewed as an exception to RPL. P2P routing can be
viewed the same way. We need a common protocol to guaranty interoperability
between the nodes and RPL can be this protocol. When a group of node wants a
different behavior, another routing protocol can be used. I'm also in favor
to push RPL as a wg document.
Laurent

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 29 Jul 2009 11:56:36 +0200

Hi JP, WG,

I support the adoption of RPL as WG document.

I'll sync up with my work on Autoconf, I think I have some
improvements, ready for stealing. For example, I suggested
multi-path routing based on source address. This brings in
address generation and address selection. This is not
work for ROLL, but ROLL should provide the routing building 
blocks for multi-path. As RPL provides a DAG, this is doable.

Regards, Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens JP
|Vasseur
|Verzonden: dinsdag 28 juli 2009 18:34
|Aan: ROLL WG
|Onderwerp: [Roll] Moving forward with the protocol work
|
|Dear WG,
|
|First of all, thanks for all the time and energy you all have devoted
|during the past few weeks on the protocol work. There was excellent
|followup discussion at the physical WG meeting.
|
|To the question "Do you think that RPL provides an adequate foundation
|for the ROLL routing protocol work", there was clearly a good
|consensus in the WG meeting. It was also recognized there are still
|several open issues for which we WILL need help from many WG
|contributors, including the authors of other documents.
|
|Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01
|as a WG document ?
|
|Then we will of course move to the next step.
|
|Thanks,
|
|JP and David
|
|
|_______________________________________________
|Roll mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/roll

---

From: Tzeta Tsao <[email-masked]>
Date: Wed, 29 Jul 2009 03:06:47 -0700 (PDT)

Hi JP, WG,

I am in favor of adopting the protocol draft as the WG document. As expressed during the presentation, this move will give incentive for people to start experimenting and provide "real world" experience feedback.

Regards,
Tzeta

----- Original Message ----
From: JP Vasseur <[email-masked]>
To: ROLL WG <[email-masked]>
Sent: Tuesday, July 28, 2009 12:34:24 PM
Subject: [Roll] Moving forward with the protocol work

Dear WG,

First of all, thanks for all the time and energy you all have devoted during the past few weeks on the protocol work. There was excellent followup discussion at the physical WG meeting.

To the question "Do you think that RPL provides an adequate foundation for the ROLL routing protocol work", there was clearly a good consensus in the WG meeting. It was also recognized there are still several open issues for which we WILL need help from many WG contributors, including the authors of other documents.

Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 as a WG document ?

Thanks,

JP and David

---

From: Zach Shelby <[email-masked]>
Date: Wed, 29 Jul 2009 14:15:00 +0300

I am in favor!

-- 
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: Richard Kelsey <[email-masked]>
Date: Wed, 29 Jul 2009 07:23:49 -0400

Hi JP, All,

I also support the adoption of draft-dt-roll-rpl-01 as a WG
document, while acknowledging that there is still a lot of
work to do on P2P and loop detection.

                                -Richard Kelsey

---

From: Robert Cragie <[email-masked]>
Date: Wed, 29 Jul 2009 12:49:52 +0100

I am in favour of moving forward whilst acknowledging there is work to
be done, especially with regard to P2P and security. I also have some
concerns regarding subDAG orphaning in certain topologies.

Robert

Robert Cragie, Principal Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

---

From: JP Vasseur <[email-masked]>
Date: Wed, 29 Jul 2009 14:02:30 +0200

Hi Mathilde,

> I also support the RPL proposal as the foundation for the ROLL routing

I'll strop processing there for now for the sake of the process. What  
follows is highly relevant
and will be answered right after.

Thanks.

JP.

> consensus

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 29 Jul 2009 12:20:58 +0200

In support too.
 
At the same time wishes to support Jerry's comment that it is important that we end up with a good solution for P2P traffic patterns. These also apply a lot to home control networks.
 
Cheers,
  Anders

________________________________

Fra: [email-masked] på vegne af JP Vasseur
Sendt: ti 28-07-2009 18:34
Til: ROLL WG
Emne: [Roll] Moving forward with the protocol work

Dear WG,

Thanks,

JP and David

---

From: [email-masked]
Date: Wed, 29 Jul 2009 08:14:12 -0500

Mischa,

Thanks for the comment.  I was going to look at the other requirements 
regarding P2P.  I'm very surprised that the other requirements have no 
need to communicate amongst themselves.  The Building Requirements were 
very clear about p2p.  Here's the excerpt from the Building Requirement ID 
...

5.2.2. Peer-to-Peer Communication 

   The data domain for commercial FMS systems may sprawl across a vast 
   portion of the physical domain.  For example, a chiller may reside in 
   the facility's basement due to its size, yet the associated cooling 
   towers will reside on the roof.  The cold-water supply and return 
   pipes serpentine through all the intervening floors.  The feedback 
   control loops for these systems require data from across the 
   facility. 

   A network device MUST be able to communicate in a peer-to-peer manner 
   with any other device on the network. Thus, the routing protocol MUST 
   provide routes between arbitrary hosts within the appropriate 
   administrative domain. 

Jerry

Mischa Dohler <[email-masked]> 
07/28/2009 06:42 PM

To
[email-masked]
cc
JP Vasseur <[email-masked]>, ROLL WG <[email-masked]>
Subject
Re: [Roll] Moving forward with the protocol work

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Jul 2009 15:37:22 +0200

+1.

There are certainly a number of issues on this draft, but they only can
be solved properly by the WG if the doc belongs to the WG in the first
place.

I've sensed a degree of frustration from people outside the design team
and it's time to open the door for comments and improvements originated
from the WG.

It's also time to use the formal process to track issues and get WG
consensus on how to deal with them. So I think it's fair to transfer
ownership to the WG and apply the appropriate processes to fix what need
fixing, add what must be added etc...

Pascal

JP Vasseur (jvasseur)
>Sent: mardi 28 juillet 2009 18:34
>To: ROLL WG

---

From: Jaudelice de Oliveira <[email-masked]>
Date: Wed, 29 Jul 2009 09:55:15 -0400

I support the adoption of the RPL draft as a WG document... Looking  
forward to looking into the remaining issues as a WG document...

Jau.

On Jul 28, 2009, at 12:34 PM, JP Vasseur wrote:

> devoted during the past few weeks on the protocol work. There was  
> excellent followup discussion at the physical WG meeting.
>
> foundation for the ROLL routing protocol work", there was clearly a  
> good consensus in the WG meeting. It was also recognized there are  
> still several open issues for which we WILL need help from many WG

---

From: "Theodore Zahariadis" <[email-masked]>
Date: Wed, 29 Jul 2009 17:30:56 +0300

Dear Pascal,

Monitoring externally your discussions, I think it 
worth adopting the RPL draft as a WG document... 

Best Regards,
Theodore

---

From: Tim Winter <[email-masked]>
Date: Wed, 29 Jul 2009 10:48:10 -0400

+1

---

From: Umair Bussi <[email-masked]>
Date: Wed, 29 Jul 2009 08:36:34 -0700 (PDT)

Plus ONE.

Regards,
Umair

--- On Wed, 7/29/09, Pascal Thubert (pthubert) <[email-masked]> wrote:

> From: Pascal Thubert (pthubert) <[email-masked]>
> To: "JP Vasseur (jvasseur)" <[email-masked]>, "ROLL WG" <[email-masked]>
> Date: Wednesday, July 29, 2009, 1:37 PM
> +1.
> 
> >From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of
> JP Vasseur (jvasseur)

---

From: Kris Pister <[email-masked]>
Date: Wed, 29 Jul 2009 08:53:11 -0700

-exp(j pi)

ksjp

Umair Bussi wrote:
>>> First of all, thanks for all the time and energy you
>>>       
>> all have devoted
>>     
>>> during the past few weeks on the protocol work. There
>>>       
>> was excellent
>>     
>>> To the question "Do you think that RPL provides an
>>>       
>> adequate foundation
>>     
>>> for the ROLL routing protocol work", there was clearly
>>>       
>> a good
>>     
>>> consensus in the WG meeting. It was also recognized
>>>       
>> there are still
>>     
>>> several open issues for which we WILL need help from
>>>       
>> many WG
>>     
>>> contributors, including the authors of other
>>>       
>> documents.
>>     
>> draft-dt-roll-rpl-01

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 29 Jul 2009 17:56:21 +0200

+1

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Jul 2009 18:12:35 +0200

FWIW, that makes for +1, as explained in the attached image.

Alex

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Wed, 29 Jul 2009 13:10:55 -0700

Hi Pascal,

I am forwarding this mail to Roll. Your point is taken; I did not think of
Industrial usage dependency on this RFC.

In that case, I certainly think that IETF should help deploy its own
protocol by speeding it up with a slight risk.

I assume we are going to be careful on the reviews and will have some
implementations plus interop testing before standardization in that case. In
case, we find a major issue later, we can always produce another RFC.

So here is a complete +1 :-)

Thanks for pointing it out.
-Samita

> From: Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Wednesday, July 29, 2009 9:42 AM
> To: Samita Chakrabarti
> Subject: RE: [Roll] Moving forward with the protocol work
> 
> Hi Samita :)
> 
> You must understand that the industrial constraints do not leave us the
> years that would be needed to make an experimental protocol, play with it,
> and then make a standard track. So we'll have accept some risk, manage it
> and a utilize a conservative solution with well understood techniques.
> 
> As you figured, the main risk in this draft is the new assembly of those
> well known components. Also being conservative in the methods employed
(for
> instance detach the Dag rather than risk a meltdown) yields temporary
> unreachabilities that could be avoided on some research floors
> - at what risk?
> 
> Considering that there is no way to make it experimental, your vote is an
> abstain right now. Would you please reconsider?
> 
> Pascal
> 
> Samita Chakrabarti
> >Sent: mercredi 29 juillet 2009 11:17
> >To: JP Vasseur (jvasseur); 'Mukul Goyal'
> >Cc: 'ROLL WG'
> adoption
> not
> multiple
> >> > Jerry, I am not sure this was already discussed at the meeting in
> >> > person but I think we are a little in a catch22 situation here
> >> > since - as
> far
> >> > as their working basis which is why p2p is not efficiently
> >> > supported. In our urban requirements draft, we actually did go as
> >> > far as saying
> that
> >> >> As I have noted in my review comments, connectivity to every node
> >> >> within the DAG is not assured.  The traffic patterns within the
> >> >> LLN are
> also
> >> >> foundation for the ROLL routing protocol work", there was clearly
> >> >> a good consensus in the WG meeting. It was also recognized there
> >> >> are
> still

---

From: Mischa Dohler <[email-masked]>
Date: Wed, 29 Jul 2009 23:16:42 +0200

JP, all,

We should use this early design stage to come up with one solution - one 
solution which is not necessarily optimum for all cases but for the 
(e.g.) 95% quantile. The PHY guys learned to live with such an approach. 
The MAC folks are getting there and we should take our chance now. 95% 
means clearly to concentrate on the core issues, of which loop 
detection/avoidance, p2p and security are somehow still open.

I do understand the concept of loops arising. I have doubts that with 
the dynamics of typical ROLL networks, these will give us headaches 
within this 95% application quantile. I have read tons of papers 
produced in the last decade on routing in ROLL-type networks. Loop 
detection and avoidance was clearly not something people (including 
those doing practical rollouts and running their companies today) were 
worried about too much. Unless somebody provides me with a convincing 
study, I propose to merely adopt some simple and possibly sub-optimum 
heuristics and then forget about it.

P2P seems to worry some of us (sorry, Jerry, for having forgotten about 
the p2p paragraph). However, again, are we talking about the 95% 
quantile here? Furthermore, how much p2p exactly are you talking about? 
Any node truly to any node? Are we back to pure ad hoc then? I guess if 
IETF couldn't provide us with a magic ultra low power solution for ad 
hoc networks in past years, then chances are slim that this will work 
out now. Unless somebody provides me with a convincing study that 
adopting a general p2p ROLL protocol will not jeopardize the efficiency 
of the 95% quantile applications, I propose to adopt some simple and 
possibly sub-optimum heuristics and then forget about it.

Security is an important issue.

Now that we are at it, I sampled quite a large number of companies at an 
  M2M event in Paris a few months ago organized by Orange where we met 
with JP and others. The large majority of companies present there 
explicitly told me that - for a very varying set of reasons - they would 
never let IP run over their ROLL-type networks. The sheer majority did 
suprise me. We still have a lot of work ahead.

I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Mischa.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Jul 2009 00:03:59 +0200

Hi Samita,

There are three parts in your email.

> Hi JP/David,

Part 1.

> loop-detection and the cost based on historical information on packet

OK.

Part 2

> as some of the ideas need more experiments to prove that would work

Bear in mind that WG document adoption is the first step and we are  
far from being done.
We will definitely need to work on various open issues as a WG and  
considering the amount
of energy and willingness to work, I am highly confident that we will  
be able to quickly move
forward as a group. We will of course take the time to build  
confidence on the protocol
before publication submission and (according to our charter) we will  
follow the Std track.

Part 3

> multiple protocol might be needed in the future.

As mentioned in my reply to Mukul this morning let's wait until we  
know what the final protocol
potential weaknesses are.

Thanks.

JP.

> So, is it possible to adopt
>> Behalf Of JP
>>> person
>>> supported. In
>>>> within

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 30 Jul 2009 15:24:14 +0900

+1.

we really need a base draft to move forward.  it doesn't matter to choose
one among some protocols.  it means current original RPL may not be a final
roll protocol as is.  we have a time to improve it till WGLC.
I take JP's comment.

> Bear in mind that WG document adoption is the first step and we are far 
> from being done.
> of energy and willingness to work, I am highly confident that we will be 
> able to quickly move
> forward as a group. We will of course *take the time to build confidence 
> on the protocol *
> *before *publication submission* and (according to our charter) we will 
> follow the Std track.*

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 30 Jul 2009 00:24:24 -0700

Hi JP,

Bear in mind that WG document adoption is the first step and we are far from
being done.

forward as a group. We will of course take the time to build confidence on
the protocol 

before publication submission and (according to our charter) we will follow
the Std track.

Part 3

 Thanks for the explanation. I agree with your viewpoint.

Regards,

-Samita

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Jul 2009 10:54:34 +0200

You are most welcome.

Thanks.

JP.

On Jul 30, 2009, at 9:24 AM, Samita Chakrabarti wrote:

> of energy and willingness to work, I am highly confident that we  
> will be able to quickly move

---

From: [email-masked]
Date: Thu, 30 Jul 2009 05:28:13 -0400

> Robert Cragie wrote:

That's almost precisely what I'd have written.  In addition to the subDAG 
orphaning (e.g. when a DAG detaches but the RA-DIO isn't heard by all 
children), the Objective Function also has some security considerations 
that haven't yet been discussed or addressed.  In particular, in a 
non-homogenous network, a misbehaved node could either become a black hole 
or violate the rules and deliberately route through a battery powered 
node. 

Ed Beroset

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 30 Jul 2009 14:12:35 +0200

Hi JP, Hi David,
RPL is indeed an interesting approach. Other approaches that were put
forward are also interesting, such as draft-goyal-roll-dv, and
draft-iwao-roll-dadr.

However, we all agree: neither is mature. The first priority is indeed
*protocol work*. It is paramount to develop these different approaches
further, to identify if and how they could work/benefit from one another.

Therefore at this point, I do not understand the urgency regarding changing
the status of RPL to working group document. It may rightfully become such,
down the road, once it's trade-offs are better understood and the document
is more fleshed out -- possibly incorporating some ideas from other
approaches. But for now it seems a tad too early to be fully justified.

Changing the status of RPL to working group document in a hurry has nothing
to do with speeding up the actual technical progress, so defering a little
is not likely to slow down in any way the top priority: I mean protocol
work.

In a nutshell:

1- defering change to WG status will not slow down protocol development,
which is priority number 1,
2- some concerns were expressed regarding RPL, in its current premature
state,
3- there's nothing to lose yet with a more conservative attitude, instead of
a rush, concerning official procedures.

What do you think?

Regards,

Emmanuel

On Tue, Jul 28, 2009 at 6:34 PM, JP Vasseur <[email-masked]> wrote:

> during the past few weeks on the protocol work. There was excellent followup
> discussion at the physical WG meeting.
>
> To the question "Do you think that RPL provides an adequate foundation for
> the ROLL routing protocol work", there was clearly a good consensus in the
> WG meeting. It was also recognized there are still several open issues for
> which we WILL need help from many WG contributors, including the authors of
> other documents.
>

---

From: [email-masked]
Date: Thu, 30 Jul 2009 10:57:48 -0500

Hi Mischa,

Nearly all communication in a commercial building facility management 
system is point to point.  I'm surprised the other three requirements 
don't also have a strong p2p requirement.  Back in the early 80's prior to 
processor based sensors, we deployed 'dumb sensors' that would simply 
upload their current environmental information to a centralized 
minicomputer.  This centralized model was not scalable nor fault tolerant. 
 That is if the minicomputer 'blew a gasket', the entire building went out 
of control.

As soon as it was economically viable, we decentralized control by moving 
it down into the rooms.  Now each room was controlled independently with 
an array of room sensors and room controllers.  Now if a controller 
failed, only the room might lose control, not the entire complex.  The 
room controllers were then further controlled by higher level controllers. 
 This distributed architecture has been in place for 25 years and is the 
mainstay of building control. 

My point is that is the Commercial Market the LLN is not just a path for 
moving data nortbound.  Most of the packets sent on the LLN are destined 
to other nodes on the LLN.  They all require application ACKs.  About 20% 
of the packets are destined to the LBR and onwards.  These are event 
packets being sent to the higher layers for further analysis.

If we don't support a robust p2p protocol option in ROLL, we will knock 
out the Building Market in its entirety which means at best you will only 
solve 75% of the need.

Jerry

07/29/2009 04:18 PM

To

JP, all,

Mischa.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Jul 2009 18:02:58 +0200

Hi Jerry,

Just jumping to the point.

On Jul 30, 2009, at 5:57 PM, [email-masked] wrote:

>
>
> Hi Mischa,
>
> Nearly all communication in a commercial building facility  
> management system is point to point.  I'm surprised the other three  
> requirements don't also have a strong p2p requirement.  Back in the  
> early 80's prior to processor based sensors, we deployed 'dumb  
> sensors' that would simply upload their current environmental  
> information to a centralized minicomputer.  This centralized model  
> was not scalable nor fault tolerant.  That is if the minicomputer  
> 'blew a gasket', the entire building went out of control.
>
> As soon as it was economically viable, we decentralized control by  
> moving it down into the rooms.  Now each room was controlled  
> independently with an array of room sensors and room controllers.   
> Now if a controller failed, only the room might lose control, not  
> the entire complex.  The room controllers were then further  
> controlled by higher level controllers.  This distributed  
> architecture has been in place for 25 years and is the mainstay of  
> building control.
>
> My point is that is the Commercial Market the LLN is not just a path  
> for moving data nortbound.  Most of the packets sent on the LLN are  
> destined to other nodes on the LLN.  They all require application  
> ACKs.  About 20% of the packets are destined to the LBR and  
> onwards.  These are event packets being sent to the higher layers  
> for further analysis.
>
> If we don't support a robust p2p protocol option in ROLL, we will  
> knock out the Building Market in its entirety which means at best  
> you will only solve 75% of the need.
>

There NO question about this. P2P is a MUST and our solution will have  
to support it in an efficient way.

Cheers.

JP.

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 30 Jul 2009 18:07:46 +0200

Hi Jerald,
 
just to understand better the setup in commercial buildings: in a
typical scenario,  which devices / how many are present in a room, what
is the layer 2 topology and the p2p application flows?
 
Thank you,
Julien

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
	Sent: jeudi 30 juillet 2009 17:58
	To: Mischa Dohler
	Cc: ROLL WG; [email-masked]
	Subject: Re: [Roll] Moving forward with the protocol work

	Hi Mischa, 
	
	Nearly all communication in a commercial building facility
management system is point to point.  I'm surprised the other three
requirements don't also have a strong p2p requirement.  Back in the
early 80's prior to processor based sensors, we deployed 'dumb sensors'
that would simply upload their current environmental information to a
centralized minicomputer.  This centralized model was not scalable nor
fault tolerant.  That is if the minicomputer 'blew a gasket', the entire
building went out of control. 
	
	As soon as it was economically viable, we decentralized control
by moving it down into the rooms.  Now each room was controlled
independently with an array of room sensors and room controllers.  Now
if a controller failed, only the room might lose control, not the entire
complex.  The room controllers were then further controlled by higher
level controllers.  This distributed architecture has been in place for
25 years and is the mainstay of building control.   
	
	My point is that is the Commercial Market the LLN is not just a
path for moving data nortbound.  Most of the packets sent on the LLN are
destined to other nodes on the LLN.  They all require application ACKs.
About 20% of the packets are destined to the LBR and onwards.  These are
event packets being sent to the higher layers for further analysis. 
	
	If we don't support a robust p2p protocol option in ROLL, we
will knock out the Building Market in its entirety which means at best
you will only solve 75% of the need. 

	Jerry 

07/29/2009 04:18 PM 

To

	JP, all,
	
	We should use this early design stage to come up with one
solution - one 
	solution which is not necessarily optimum for all cases but for
the 
	(e.g.) 95% quantile. The PHY guys learned to live with such an
approach. 
	The MAC folks are getting there and we should take our chance
now. 95% 
	means clearly to concentrate on the core issues, of which loop 
	detection/avoidance, p2p and security are somehow still open.
	
	I do understand the concept of loops arising. I have doubts that
with 
	the dynamics of typical ROLL networks, these will give us
headaches 
	within this 95% application quantile. I have read tons of papers

	produced in the last decade on routing in ROLL-type networks.
Loop 
	detection and avoidance was clearly not something people
(including 
	those doing practical rollouts and running their companies
today) were 
	worried about too much. Unless somebody provides me with a
convincing 
	study, I propose to merely adopt some simple and possibly
sub-optimum 
	heuristics and then forget about it.
	
	P2P seems to worry some of us (sorry, Jerry, for having
forgotten about 
	the p2p paragraph). However, again, are we talking about the 95%

	quantile here? Furthermore, how much p2p exactly are you talking
about? 
	Any node truly to any node? Are we back to pure ad hoc then? I
guess if 
	IETF couldn't provide us with a magic ultra low power solution
for ad 
	hoc networks in past years, then chances are slim that this will
work 
	out now. Unless somebody provides me with a convincing study
that 
	adopting a general p2p ROLL protocol will not jeopardize the
efficiency 
	of the 95% quantile applications, I propose to adopt some simple
and 
	possibly sub-optimum heuristics and then forget about it.

	Now that we are at it, I sampled quite a large number of
companies at an 
	 M2M event in Paris a few months ago organized by Orange where
we met 
	with JP and others. The large majority of companies present
there 
	explicitly told me that - for a very varying set of reasons -
they would 
	never let IP run over their ROLL-type networks. The sheer
majority did 
	suprise me. We still have a lot of work ahead.
	
	I am in favour of adopting draft-dt-roll-rpl-01 as a WG
document.
	
	Mischa.

	
devoted 
foundation 
consensus 
draft-dt-roll-rpl-01

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 30 Jul 2009 09:12:31 -0700

Hi Jerry,

I think RPL does support P2P but does not optimize the number of hops. I
think that is the central issue you and Mukul are bringing up.

I do question whether optimizing hops is really necessary.  I think most
applications (including building controls) can take advantage of a solution
that well supports MP2P and P2MP with extensions to provide P2P capability
(admittedly not optimized for hop count/cost but then also without nearly
the overhead of packet flooding or storage of state information that
optimized P2P solutions impose).  

I really don't see that trying (once again as they have in MANET for some
time) to find a single protocol that efficiently implements P2P and scales
while addressing the various data transmission patterns will result in
anything other than the same set of solutions we have today (distance vector
with flooding, link state routing and its derivatives, source routing and
its derivatives).  

Don

Sent: Thursday, July 30, 2009 8:58 AM

Hi Mischa, 

Nearly all communication in a commercial building facility management system
is point to point.  I'm surprised the other three requirements don't also
have a strong p2p requirement.  Back in the early 80's prior to processor
based sensors, we deployed 'dumb sensors' that would simply upload their
current environmental information to a centralized minicomputer.  This
centralized model was not scalable nor fault tolerant.  That is if the
minicomputer 'blew a gasket', the entire building went out of control. 

As soon as it was economically viable, we decentralized control by moving it
down into the rooms.  Now each room was controlled independently with an
array of room sensors and room controllers.  Now if a controller failed,
only the room might lose control, not the entire complex.  The room
controllers were then further controlled by higher level controllers.  This
distributed architecture has been in place for 25 years and is the mainstay
of building control.   

My point is that is the Commercial Market the LLN is not just a path for
moving data nortbound.  Most of the packets sent on the LLN are destined to
other nodes on the LLN.  They all require application ACKs.  About 20% of
the packets are destined to the LBR and onwards.  These are event packets
being sent to the higher layers for further analysis. 

If we don't support a robust p2p protocol option in ROLL, we will knock out
the Building Market in its entirety which means at best you will only solve
75% of the need. 

Jerry 

07/29/2009 04:18 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

		

JP, all,

Mischa.

---

From: [email-masked]
Date: Thu, 30 Jul 2009 11:44:24 -0500

Hi Don,

As I read the draft, RPL doesn't currently guarantee p2p communication 
regardless of hop count.  Only if some node higher in the DAG elects to 
provide a path back down the DAG to the destination then there is p2p 
path.  RPL doesn't mandate this even for the LBR.  Hence a packet could 
squirt all the way up to the LBR and still be dropped since the LBR itself 
has no route defined to the destination.  You need to keep in mind that 
the LLN devices are primarily a building controllers that 'moonlight' as a 
router; it's not a router that happens to also do building control.  The 
likelihood that a controller sitting higher in the DAG being altruist and 
defining pathways to all possible sub-DAG devices is nil.

As for hops, this is very important too.  Not so much for latency.  The 
time constant for most building HVAC  control loops is in minutes so 
having a packet arrive at its destination a tad late is not too 
concerning. (NOTE: Fire and lighting applications are much more time 
critical).  The problem is that the source device, typically a battery 
powered sensor must stay awake and leave its receiver active until the 
packet has migrated to its destination and the application ACK has been 
received.  This will reduce battery life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a 
floor which may require upwards to 250 LLN nodes.  Sure we could have 
defined the PAN to be the entire complex and then require 10K nodes as do 
the other requirement specs.  Empirical testing however determined that 
managing 250 nodes on a single wireless domain was difficult enough with 
regard to channel management, interference and hop count.  Limiting PAN 
size to a floor seems to be the right balance point for complexity and 
flexibility.

Jerry

"Don Sturek" <[email-masked]> 
07/30/2009 11:12 AM
Please respond to
<[email-masked]>

To
<[email-masked]>, "'Mischa Dohler'" <[email-masked]>
cc
"'ROLL WG'" <[email-masked]>, <[email-masked]>
Subject
RE: [Roll] Moving forward with the protocol work

Hi Jerry,

I do question whether optimizing hops is really necessary.  I think most 
applications (including building controls) can take advantage of a 
solution that well supports MP2P and P2MP with extensions to provide P2P 
capability (admittedly not optimized for hop count/cost but then also 
without nearly the overhead of packet flooding or storage of state 
information that optimized P2P solutions impose). 
 
I really don?t see that trying (once again as they have in MANET for some 
time) to find a single protocol that efficiently implements P2P and scales 
while addressing the various data transmission patterns will result in 
anything other than the same set of solutions we have today (distance 
vector with flooding, link state routing and its derivatives, source 
routing and its derivatives). 
 
Don

Hi Mischa, 

Jerry 

To

JP, all,

Mischa.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 30 Jul 2009 09:59:50 -0700

Hi Jerry,

I may have misread the RPL proposal.  I thought the Destination Address
notifications allowed the DAG root to route back down to a device in the DAG
and that feature enabled P2P in all cases.  I thought also the Destination
Address notifications for devices with lower depth/rank could be used by
devices within a DAG to more efficiently reroute P2P traffic within the DAG
(not optimally, just "more efficiently than sending the packet all the way
to the DAG root first).  I thought in all cases P2P was supported (just
without a mechanism to minimize the hop count).

Could someone from the DT comment on the assumptions above?

Did I understand that optimizing P2P for building controls is mainly about
minimizing hop counts?   If a building controls solution could choose
between optimizing hop count for P2P and flooding the network to find the
optimal P2P hop count, would it choose to flood the network?  I think it is
the lack of network flooding to establish routes and the minimal storage of
route state information along the route that I found so attractive about
RPL...

Don

From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, July 30, 2009 9:44 AM
To: [email-masked]
Cc: 'Mischa Dohler'; 'ROLL WG'; [email-masked]
Subject: RE: [Roll] Moving forward with the protocol work

Hi Don, 

As I read the draft, RPL doesn't currently guarantee p2p communication
regardless of hop count.  Only if some node higher in the DAG elects to
provide a path back down the DAG to the destination then there is p2p path.
RPL doesn't mandate this even for the LBR.  Hence a packet could squirt all
the way up to the LBR and still be dropped since the LBR itself has no route
defined to the destination.  You need to keep in mind that the LLN devices
are primarily a building controllers that 'moonlight' as a router; it's not
a router that happens to also do building control.  The likelihood that a
controller sitting higher in the DAG being altruist and defining pathways to
all possible sub-DAG devices is nil. 

As for hops, this is very important too.  Not so much for latency.  The time
constant for most building HVAC  control loops is in minutes so having a
packet arrive at its destination a tad late is not too concerning. (NOTE:
Fire and lighting applications are much more time critical).  The problem is
that the source device, typically a battery powered sensor must stay awake
and leave its receiver active until the packet has migrated to its
destination and the application ACK has been received.  This will reduce
battery life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a
floor which may require upwards to 250 LLN nodes.  Sure we could have
defined the PAN to be the entire complex and then require 10K nodes as do
the other requirement specs.  Empirical testing however determined that
managing 250 nodes on a single wireless domain was difficult enough with
regard to channel management, interference and hop count.  Limiting PAN size
to a floor seems to be the right balance point for complexity and
flexibility. 

Jerry 

07/30/2009 11:12 AM 

Please respond to
<[email-masked]>

To

cc

Subject

		

Hi Jerry, 

  
  
Don 

Hi Mischa, 

Jerry 

07/29/2009 04:18 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

  

JP, all,

Mischa.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Jul 2009 19:16:47 +0200

Hi Jerry

As I read the draft, RPL doesn't currently guarantee p2p communication
regardless of hop count.  Only if some node higher in the DAG elects to
provide a path back down the DAG to the destination then there is p2p
path.  RPL doesn't mandate this even for the LBR.  Hence a packet could
squirt all the way up to the LBR and still be dropped since the LBR
itself has no route defined to the destination.  You need to keep in
mind that the LLN devices are primarily a building controllers that
'moonlight' as a router; it's not a router that happens to also do
building control.  The likelihood that a controller sitting higher in
the DAG being altruist and defining pathways to all possible sub-DAG
devices is nil. 

This is a product /deployment issue. The protocol enables P2P and then
you use it or not. If the use case (say building) requires the P2P
routes then I suspect you'll design devices that can afford the
necessary states and setup the devices to use them. OTOH the protocol
should not force anything because that would have the counterproductive
effect of forcing small devices to store states that they do not need in
other use cases.

This looks a lot like a APP layer mingling with routing affairs. The
routing delays will be what they will be, whether they are optimized or
not, and you'll have to deal with that. It is not unheard of for upper
layers to measure a turn around trip (TAT) delay - aka Round trip Time
(RTT) and be smart about it. TCP does that (see RFC 2988). ISA100.11a
applications that actually need a application layer ack also do that
(over UDP). 

I suspect that after some exchanges, the node can learn what a typical
TAT is, what the variance is, and go to sleep until the ack has a fair
chance to be back. But do not accuse the routing for every pain in the
world.

As for scalability, a typical PAN in a commercial building is limited to
a floor which may require upwards to 250 LLN nodes.  Sure we could have
defined the PAN to be the entire complex and then require 10K nodes as
do the other requirement specs.  Empirical testing however determined
that managing 250 nodes on a single wireless domain was difficult enough
with regard to channel management, interference and hop count.  Limiting
PAN size to a floor seems to be the right balance point for complexity
and flexibility. 

I'd like to figure what a typical depth (rank?) that would cause. Say
your 250 nodes create a matrix of 16*16. 

If the sink is in the middle of the matrix the max depth is about 8.

That a node's transmission power enables a rank stripe to be about 2
nodes deep then the max depth goes down to 4.

We'd have to run a computer simulation  to get stats, but it appears
that in many cases, RPL does not add that much stretch.

We can improve P2P by a number of techniques, the question being to
prove that this addition is required.

It's good nevertheless to be prepared and discuss those additions so you
get a reasonable idea that it is doable

Cheers

Pascal

Jerry 

07/30/2009 11:12 AM 

Please respond to
<[email-masked]>

To

cc

Subject

		

Hi Jerry, 

  
I really don't see that trying (once again as they have in MANET for
some time) to find a single protocol that efficiently implements P2P and
scales while addressing the various data transmission patterns will
result in anything other than the same set of solutions we have today
(distance vector with flooding, link state routing and its derivatives,
source routing and its derivatives).   
  
Don 

Hi Mischa, 

Nearly all communication in a commercial building facility management
system is point to point.  I'm surprised the other three requirements
don't also have a strong p2p requirement.  Back in the early 80's prior
to processor based sensors, we deployed 'dumb sensors' that would simply
upload their current environmental information to a centralized
minicomputer.  This centralized model was not scalable nor fault
tolerant.  That is if the minicomputer 'blew a gasket', the entire
building went out of control. 

My point is that is the Commercial Market the LLN is not just a path for
moving data nortbound.  Most of the packets sent on the LLN are destined
to other nodes on the LLN.  They all require application ACKs.  About
20% of the packets are destined to the LBR and onwards.  These are event
packets being sent to the higher layers for further analysis. 

If we don't support a robust p2p protocol option in ROLL, we will knock
out the Building Market in its entirety which means at best you will
only solve 75% of the need. 

Jerry 

07/29/2009 04:18 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

  

JP, all,

Mischa.

consensus

---

From: [email-masked]
Date: Thu, 30 Jul 2009 13:18:06 -0400

So I agree with both Don and Jerry.  Certainly within a PAN, someone has 
to be able route packets within that PAN to support P2P. I thought the DAG 
roots were required to do this, but in reading the RPL draft again, I 
don't see that. 

That said having all nodes able to route to all neighbor nodes is probably 
not going to work due to the limitations of the nodes themselves (IEEE 
802.15.5 provides a design for this if anyone would like to read it). 
These are low power and usually resource limited devices.

Perhaps making the DAG roots - which will have to be more powerful than 
the majority of the nodes in the LLN - be required to route within the 
PAN's should be made a requirement.   As Don said, this won't optimize hop 
count and it would be unfortunate if two side-by-side nodes have to 
communicate thru a DAG root 7 hops away - but it may be a reality of these 
networks.  At a "solution level", if your PAN can afford more DAG roots to 
minimize the hops, you put them in.  If you can't, you deal with less than 
optimized routing.  But at a protocol level, we may have to make some 
sacrifices - as long as we ensure the protocol does ensure that P2P is 
enabled in some form.

From:
[email-masked]
To:
<[email-masked]>
Cc:
'ROLL WG' <[email-masked]>, [email-masked]
Date:
07/30/2009 06:44 PM
Subject:
Re: [Roll] Moving forward with the protocol work
Sent by:
[email-masked]

Hi Don, 

Jerry 

Please respond to
<[email-masked]>

To

Hi Jerry, 

  
I really don’t see that trying (once again as they have in MANET for some 
  
Don 

Hi Mischa, 

Jerry 

To

JP, all,

Mischa.

______________________________________________________________________
This email has been spam and virus checked by Elster IT Services.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Jul 2009 19:29:48 +0200

Hi Don:

You're correct. If the DAO states are enabled everywhere, the first
common parent will route down to the destination.

But the doc cannot MUST keeping states in all nodes at the protocol
level because there are some use cases where that makes no sense.

There might even be a case where no data whatsoever is unicast to the
devices, in which case even storing source route paths at the root would
be ridiculous. An example of that would be environmental monitoring
using widespread cheap sensors. 

It seems to me that this discussion is caused by a confusion between
what belongs to protocol and what belongs to product and deployment. The
protocol gives you tools, and then you have to use them intelligently in
the products you build.

Another confusion I've seen here is that between the rough consensus to
get WG Doc and a ballot at IEEE or others. The call here is NOT a
ballot. This is just to create a foundation for the WG to work on. So
obviously the doc does not have everything ironed out. The question is
rather whether the doc is a good foundation for that work at it appears
that many people agree on that.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Don Sturek
Sent: jeudi 30 juillet 2009 19:00
To: [email-masked]
Cc: 'ROLL WG'; [email-masked]
Subject: Re: [Roll] Moving forward with the protocol work

Hi Jerry,

I may have misread the RPL proposal.  I thought the Destination Address
notifications allowed the DAG root to route back down to a device in the
DAG and that feature enabled P2P in all cases.  I thought also the
Destination Address notifications for devices with lower depth/rank
could be used by devices within a DAG to more efficiently reroute P2P
traffic within the DAG (not optimally, just "more efficiently than
sending the packet all the way to the DAG root first).  I thought in all
cases P2P was supported (just without a mechanism to minimize the hop
count).

Did I understand that optimizing P2P for building controls is mainly
about minimizing hop counts?   If a building controls solution could
choose between optimizing hop count for P2P and flooding the network to
find the optimal P2P hop count, would it choose to flood the network?  I
think it is the lack of network flooding to establish routes and the
minimal storage of route state information along the route that I found
so attractive about RPL.....

Don

Hi Don, 

Jerry 

07/30/2009 11:12 AM 

Please respond to
<[email-masked]>

To

cc

Subject

		

Hi Jerry, 

  
  
Don 

Hi Mischa, 

Jerry 

07/29/2009 04:18 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

  

JP, all,

Mischa.

consensus

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Jul 2009 19:42:41 +0200

On Jul 30, 2009, at 7:29 PM, Pascal Thubert (pthubert) wrote:

> Hi Don:
>
> You’re correct. If the DAO states are enabled everywhere, the first  

this is where smart route aggregation techniques will help.

> There might even be a case where no data whatsoever is unicast to  
> the devices, in which case even storing source route paths at the  
> root would be ridiculous. An example of that would be environmental  
> monitoring using widespread cheap sensors.
>
> what belongs to protocol and what belongs to product and deployment.  
> The protocol gives you tools, and then you have to use them  
> intelligently in the products you build.
>
> Another confusion I’ve seen here is that between the rough consensus  
> to get WG Doc and a ballot at IEEE or others. The call here is NOT a  
> ballot. This is just to create a foundation for the WG to work on.  
> So obviously the doc does not have everything ironed out. The  
> question is rather whether the doc is a good foundation for that  
> work at it appears that many people agree on that.
>
> Cheers,
>
> Pascal
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Don Sturek
> I may have misread the RPL proposal.  I thought the Destination  
> Address notifications allowed the DAG root to route back down to a  
> device in the DAG and that feature enabled P2P in all cases.  I  
> thought also the Destination Address notifications for devices with  
> lower depth/rank could be used by devices within a DAG to more  
> efficiently reroute P2P traffic within the DAG (not optimally, just  
> “more efficiently than sending the packet all the way to the DAG  
> root first).  I thought in all cases P2P was supported (just without  
> a mechanism to minimize the hop count).
>
> choose between optimizing hop count for P2P and flooding the network  
> to find the optimal P2P hop count, would it choose to flood the  
> network?  I think it is the lack of network flooding to establish  
> routes and the minimal storage of route state information along the  
> route that I found so attractive about RPL…..
>
> Don
>
>
> As I read the draft, RPL doesn't currently guarantee p2p  
> communication regardless of hop count.  Only if some node higher in  
> the DAG elects to provide a path back down the DAG to the  
> destination then there is p2p path.  RPL doesn't mandate this even  
> for the LBR.  Hence a packet could squirt all the way up to the LBR  
> and still be dropped since the LBR itself has no route defined to  
> the destination.  You need to keep in mind that the LLN devices are  
> primarily a building controllers that 'moonlight' as a router; it's  
> not a router that happens to also do building control.  The  
> likelihood that a controller sitting higher in the DAG being  
> altruist and defining pathways to all possible sub-DAG devices is nil.
>
> As for hops, this is very important too.  Not so much for latency.   
> The time constant for most building HVAC  control loops is in  
> minutes so having a packet arrive at its destination a tad late is  
> not too concerning. (NOTE: Fire and lighting applications are much  
> more time critical).  The problem is that the source device,  
> typically a battery powered sensor must stay awake and leave its  
> receiver active until the packet has migrated to its destination and  
> the application ACK has been received.  This will reduce battery  
> life at least 10x.
>
> As for scalability, a typical PAN in a commercial building is  
> limited to a floor which may require upwards to 250 LLN nodes.  Sure  
> we could have defined the PAN to be the entire complex and then  
> require 10K nodes as do the other requirement specs.  Empirical  
> testing however determined that managing 250 nodes on a single  
> wireless domain was difficult enough with regard to channel  
> management, interference and hop count.  Limiting PAN size to a  
> floor seems to be the right balance point for complexity and  
> flexibility.
>
> Jerry
>
>
> I think RPL does support P2P but does not optimize the number of  
> hops. I think that is the central issue you and Mukul are bringing up.
>
> I do question whether optimizing hops is really necessary.  I think  
> most applications (including building controls) can take advantage  
> of a solution that well supports MP2P and P2MP with extensions to  
> provide P2P capability (admittedly not optimized for hop count/cost  
> but then also without nearly the overhead of packet flooding or  
> storage of state information that optimized P2P solutions impose).
>
> I really don’t see that trying (once again as they have in MANET for  
> some time) to find a single protocol that efficiently implements P2P  
> and scales while addressing the various data transmission patterns  
> will result in anything other than the same set of solutions we have  
> today (distance vector with flooding, link state routing and its  
> derivatives, source routing and its derivatives).
>
> Don
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of [email-masked]

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 30 Jul 2009 19:53:26 +0200

comment inline ...
 
Cheers,
  Anders

Fra: [email-masked] på vegne af Pascal Thubert (pthubert)
Sendt: to 30-07-2009 19:29
Til: [email-masked]; [email-masked]
Cc: ROLL WG; [email-masked]
Emne: [Roll] MUSTing P2P states [was RE: Moving forward with the protocolwork]

Hi Don:

You're correct. If the DAO states are enabled everywhere, the first common parent will route down to the destination.

But the doc cannot MUST keeping states in all nodes at the protocol level because there are some use cases where that makes no sense.

There might even be a case where no data whatsoever is unicast to the devices, in which case even storing source route paths at the root would be ridiculous. An example of that would be environmental monitoring using widespread cheap sensors. 

It seems to me that this discussion is caused by a confusion between what belongs to protocol and what belongs to product and deployment. The protocol gives you tools, and then you have to use them intelligently in the products you build.

ABR> But will a smart product have access to the tools needed to determine some transit nodes
       and build some (more optimal) source routes to avoid having to walk all the way to the top?
       I agree with Jerry that battery life time will be severely affected if not having some (relatively)
       direct connections between sensor and controller. This also applies to the home control domain.

Another confusion I've seen here is that between the rough consensus to get WG Doc and a ballot at IEEE or others. The call here is NOT a ballot. This is just to create a foundation for the WG to work on. So obviously the doc does not have everything ironed out. The question is rather whether the doc is a good foundation for that work at it appears that many people agree on that.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Sturek

Hi Jerry,

I may have misread the RPL proposal.  I thought the Destination Address notifications allowed the DAG root to route back down to a device in the DAG and that feature enabled P2P in all cases.  I thought also the Destination Address notifications for devices with lower depth/rank could be used by devices within a DAG to more efficiently reroute P2P traffic within the DAG (not optimally, just "more efficiently than sending the packet all the way to the DAG root first).  I thought in all cases P2P was supported (just without a mechanism to minimize the hop count).

Did I understand that optimizing P2P for building controls is mainly about minimizing hop counts?   If a building controls solution could choose between optimizing hop count for P2P and flooding the network to find the optimal P2P hop count, would it choose to flood the network?  I think it is the lack of network flooding to establish routes and the minimal storage of route state information along the route that I found so attractive about RPL.....

Don

Hi Don, 

As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count.  Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path.  RPL doesn't mandate this even for the LBR.  Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination.  You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control.  The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil. 

As for hops, this is very important too.  Not so much for latency.  The time constant for most building HVAC  control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical).  The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received.  This will reduce battery life at least 10x.

As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes.  Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs.  Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count.  Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility. 

Jerry 

07/30/2009 11:12 AM 

Please respond to
<[email-masked]>

To

cc

Subject

		

Hi Jerry, 
  
I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up. 
  
I do question whether optimizing hops is really necessary.  I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose).   
  
I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives).   
  
Don 

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, July 30, 2009 8:58 AM
To: Mischa Dohler
Cc: ROLL WG; [email-masked]
Subject: Re: [Roll] Moving forward with the protocol work 

Hi Mischa, 

Nearly all communication in a commercial building facility management system is point to point.  I'm surprised the other three requirements don't also have a strong p2p requirement.  Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer.  This centralized model was not scalable nor fault tolerant.  That is if the minicomputer 'blew a gasket', the entire building went out of control. 

As soon as it was economically viable, we decentralized control by moving it down into the rooms.  Now each room was controlled independently with an array of room sensors and room controllers.  Now if a controller failed, only the room might lose control, not the entire complex.  The room controllers were then further controlled by higher level controllers.  This distributed architecture has been in place for 25 years and is the mainstay of building control.   

My point is that is the Commercial Market the LLN is not just a path for moving data nortbound.  Most of the packets sent on the LLN are destined to other nodes on the LLN.  They all require application ACKs.  About 20% of the packets are destined to the LBR and onwards.  These are event packets being sent to the higher layers for further analysis. 

If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. 

Jerry 

07/29/2009 04:18 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

  

JP, all,

Mischa.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 30 Jul 2009 20:02:10 +0200

> applies to the home control domain.

(co-chair hat off). Completely agreeing and again this is clearly  
spelled out in the requirements documents.

---

From: [email-masked]
Date: Thu, 30 Jul 2009 13:11:14 -0500

I may have misread the draft myself!!!  I saw nothing in the draft that 
mandates that a node provides downward links to its sub-DAG.  It said it 
optional could, it didn't say it must, not even for the LBR.  Hence p2p 
communication seems to be based only on if a node higher in the DAG is 
gracious enough to help.  I too would like to hear from the DT on this.  I 
submitted it as one of my review comments.

Frankly, (I know I am preciously close to being blasphemous now) I have 
not seen flooding the network as a big issue in our current 
implementations.  I would much prefer an algorithm that does not require 
broadcasts.  However, to date I have seen nothing that tells me a 
asynchronous broadcast needed when new route discovery is required is any 
worse than constant 1-hop RAs, DIOs and DAOs on a periodic basis by every 
node.  Again, keep in mind that my PANS only need to have 250 nodes.

Again, as i stated much of the HVAC control in a building can live with 
additional latencies.  If someone resets the temp sensor in a room it's 
not imperative that the A/C gets actuated immediately.  However, this is 
not true for lighting.  If someone turns on the lights, they need the 
lights to kick on in msecs, not seconds.  Same is true for Smoke and Fire 
control.

In the commercial world we have been deploying wired 
sensor/actuator/controller networks for 40 years.  The devices on these 
networks were completely accessible to all other devices.  If I sent a 
message to a device, it was deterministic how long I should wait around 
for a reply.  If I needed to broadcast, I could broadcast.  This network 
had all the same accoutrements as other enterprise networks.  The packets 
were smaller, the security was thinner and the speed was slower; but 
overall connectivity was the same.  As we move toward WSN, we need the 
same communication flexibility.

I apologize to the WG for this continued diatribe.  I am really not trying 
to throw a monkey wrench into the works. 

Jerry

07/30/2009 12:00 PM
Please respond to
<[email-masked]>

To
<[email-masked]>
cc
"'Mischa Dohler'" <[email-masked]>, "'ROLL WG'" <[email-masked]>, 
<[email-masked]>
Subject
RE: [Roll] Moving forward with the protocol work

Hi Jerry,
 
I may have misread the RPL proposal.  I thought the Destination Address 
notifications allowed the DAG root to route back down to a device in the 
DAG and that feature enabled P2P in all cases.  I thought also the 
Destination Address notifications for devices with lower depth/rank could 
be used by devices within a DAG to more efficiently reroute P2P traffic 
within the DAG (not optimally, just ?more efficiently than sending the 
packet all the way to the DAG root first).  I thought in all cases P2P was 
supported (just without a mechanism to minimize the hop count).

Did I understand that optimizing P2P for building controls is mainly about 
minimizing hop counts?   If a building controls solution could choose 
between optimizing hop count for P2P and flooding the network to find the 
optimal P2P hop count, would it choose to flood the network?  I think it 
is the lack of network flooding to establish routes and the minimal 
storage of route state information along the route that I found so 
attractive about RPL?..

Don

Hi Don, 

Jerry 

Please respond to
<[email-masked]>

To

Hi Jerry, 

  
  
Don 

Hi Mischa, 

Jerry 

To

JP, all,

Mischa.

---

From: [email-masked]
Date: Thu, 30 Jul 2009 14:12:10 -0500

Hi Julien,

Section 3 of the Building Requirements ID describes the typical devices 
and device densities in a commercial building; Section 6 describes the 
traffic flow.  Let me try to reiterate here ...

The building control application domain includes Heating Ventilation and 
Air Conditioning (aka HVAC), Physical Security, Lighting, Elevator and 
Fire control.  While each has its nuances, they all fall roughly onto the 
same topology.  The leaf layer for these systems are the sensors.  There's 
a plethora of them including temperature sensors, humidity sensors, 
pressure sensors, tamper switches, C02, C0, smoke detectors, occupancy 
sensors, light switches, and the list goes on.  In a room, you might 
expect a temp sensor, a humidity sensor, an occupancy sensor, solar 
sensor, smoke detector and light switches. 

Now along with the room sensors, there are room actuators and room 
controllers.  The controllers receive the environmental data from the 
sensors, and determine the necessary control based on conditions, system 
overrides, time-of-day, etc and then control the environment by tweaking 
the actuators accordingly.  The HVAC system will modulate the airflow and 
augment heating/cooling.  The shade controller will sense solar load and 
adjust the shades.  The lighting will be adjusted as requested by the 
presentation mode.  When I talk about a room, I am not meaning necessarily 
only a closed door meeting room.  This would also apply to public spaces 
such as an attria, hallways, ballrooms.etc.  The key ingredient in this is 
that each of these areas has a self contained sensor/controller/actuator 
subsystem.

Now, the next layer of controllers are the zone and area controllers. 
These are higher level devices that supply the facility with more global 
control systems.  HVAC will have air handlers that supply fresh air to the 
rooms.  Chillers that support cold air to the rooms, boilers that supply 
heat.  Lighting panels will control whole floors rather than simply rooms. 
 The point being that these higher order devices are also LLN devices 
incorporating another whole set of sensors such as outdoor air temp, 
relative humidity, etc.

With regards to your question about layer 2, at present these devices are 
not IP devices.  They typically reside on an EIA-485 network.

Hope this helps,

Jerry

"Julien Abeille (jabeille)" <[email-masked]> 
07/30/2009 11:07 AM

To
<[email-masked]>, "Mischa Dohler" <[email-masked]>
cc
"ROLL WG" <[email-masked]>, <[email-masked]>
Subject
RE: [Roll] Moving forward with the protocol work

Hi Jerald,
 
just to understand better the setup in commercial buildings: in a typical 
scenario,  which devices / how many are present in a room, what is the 
layer 2 topology and the p2p application flows?
 
Thank you,
Julien

Hi Mischa, 

Jerry 

To

JP, all,

Mischa.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 30 Jul 2009 13:33:07 -0700

Hi Pascal,

Thanks for your note.

I think it needs to be made clear to all contributors of the various
requirements documents (urban, home, building, etc) how their specific
requirements are addressed in the RPL draft.  Otherwise, we won't find
enough consensus on the document to have it as a baseline for ROLL.

Is there a way to clearly state to Jerry and the authors of the building
automation requirements how P2P is enabled (what they have to do in RPL to
make it work) and what impact this has (added resources to hold state
information, re-propagation of Destination Advertisements, etc.).  I think
part of the discussion is pointing out that not everyone can map the RPL
draft to how the various requirements are being met.

Once we understand what is available in terms of P2P support, and what the
implications are, then we can figure out if RPL is acceptable as a baseline
across all market areas and whether more work can then focus on improving
P2P support, loop avoidance, etc.

Don

From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Thursday, July 30, 2009 10:30 AM
To: [email-masked]; [email-masked]
Cc: ROLL WG; [email-masked]
Subject: MUSTing P2P states [was RE: [Roll] Moving forward with the protocol
work]

Hi Don:

You're correct. If the DAO states are enabled everywhere, the first common
parent will route down to the destination.

But the doc cannot MUST keeping states in all nodes at the protocol level
because there are some use cases where that makes no sense.

There might even be a case where no data whatsoever is unicast to the
devices, in which case even storing source route paths at the root would be
ridiculous. An example of that would be environmental monitoring using
widespread cheap sensors. 

It seems to me that this discussion is caused by a confusion between what
belongs to protocol and what belongs to product and deployment. The protocol
gives you tools, and then you have to use them intelligently in the products
you build.

Another confusion I've seen here is that between the rough consensus to get
WG Doc and a ballot at IEEE or others. The call here is NOT a ballot. This
is just to create a foundation for the WG to work on. So obviously the doc
does not have everything ironed out. The question is rather whether the doc
is a good foundation for that work at it appears that many people agree on
that.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Don
Sturek

Hi Jerry,

Don

Hi Don, 

Jerry 

07/30/2009 11:12 AM 

Please respond to
<[email-masked]>

To

cc

Subject

		

Hi Jerry, 

  
  
Don 

Hi Mischa, 

Jerry 

07/29/2009 04:18 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

  

JP, all,

Mischa.

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 30 Jul 2009 13:45:10 -0700

Sorry for the confusion on this...

When I said "in all cases" in terms of P2P support below, I meant to say
that P2P works whether the source/destination are in the same DAG and
different rank/depth or in different DAGs.  I did understand (or at least I
thought I did!) from the RPL draft that these features need to be supported
in a particular deployment instance.

My later note suggests the ROLL DT map some of the major requirements from
the ROLL market area requirements documents (home, urban, industrial,
building controls) to how they are addressed in the draft.  We can then have
a discussion on how well these features are addressed (not whether they are
supported!).  I think the draft is not yet clear enough on which
requirements are met and how.

Don

From: Don Sturek [mailto:[email-masked]] 
Sent: Thursday, July 30, 2009 10:00 AM
To: [email-masked]'
Cc: 'Mischa Dohler'; 'ROLL WG'; [email-masked]'
Subject: RE: [Roll] Moving forward with the protocol work

Hi Jerry,

Don

Hi Don, 

Jerry 

07/30/2009 11:12 AM 

Please respond to
<[email-masked]>

To

cc

Subject

		

Hi Jerry, 

  
  
Don 

Hi Mischa, 

Jerry 

07/29/2009 04:18 PM 

To

cc

ROLL WG <[email-masked]> 

Subject

  

JP, all,

Mischa.

---

From: Mischa Dohler <[email-masked]>
Date: Fri, 31 Jul 2009 01:00:28 +0200

Hi Jerry, my understanding of p2p was slightly different in that I 
thought you assumed a (flat) architecture where every node needs to talk 
to any other node. From your description - and what I also had in mind - 
it seems that some nodes (e.g. sensors) wish to communicate with an 
order of magnitude lower number of nodes (e.g. actuators, distributed 
central units). In my opinion, this difference in order of magnitude 
changes quite a bit in the protocol design. Mischa.

[email-masked] wrote:
> Fire control.  While each has its nuances, they all fall roughly onto 
> the same topology.  The leaf layer for these systems are the sensors. 
>  There's a plethora of them including temperature sensors, humidity 
> sensors, pressure sensors, tamper switches, C02, C0, smoke detectors, 
> occupancy sensors, light switches, and the list goes on.  In a room, you 
> might expect a temp sensor, a humidity sensor, an occupancy sensor, 
> solar sensor, smoke detector and light switches.  
> 
> the actuators accordingly.  The HVAC system will modulate the airflow 
> and augment heating/cooling.  The shade controller will sense solar load 
> and adjust the shades.  The lighting will be adjusted as requested by 
> the presentation mode.  When I talk about a room, I am not meaning 
> necessarily only a closed door meeting room.  This would also apply to 
> public spaces such as an attria, hallways, ballrooms.etc.  The key 
> ingredient in this is that each of these areas has a self contained 
> sensor/controller/actuator subsystem.
> 
>  These are higher level devices that supply the facility with more 
> global control systems.  HVAC will have air handlers that supply fresh 
> air to the rooms.  Chillers that support cold air to the rooms, boilers 
> that supply heat.  Lighting panels will control whole floors rather than 
> simply rooms.  The point being that these higher order devices are also 
> LLN devices incorporating another whole set of sensors such as outdoor 
> air temp, relative humidity, etc.
> 
> With regards to your question about layer 2, at present these devices 
> are not IP devices.  They typically reside on an EIA-485 network.
> 
> Hope this helps,
> 
> Jerry
> 
> 
> 
> 
> *"Julien Abeille (jabeille)" <[email-masked]>*
> 
> 07/30/2009 11:07 AM
> 
> 	
> To
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf 
> Of [email-masked]*
> Sent:* jeudi 30 juillet 2009 17:58*
> To:* Mischa Dohler*
> Cc:* ROLL WG; [email-masked]*
> Subject:* Re: [Roll] Moving forward with the protocol work
> 
> 
> 
> Hi Mischa,
> 
> *Mischa Dohler <[email-masked]>*

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 31 Jul 2009 10:25:48 -0700

+1.

The working group needs something to work with if we want to make  
forward progress...

--
Jonathan Hui

On Jul 29, 2009, at 6:37 AM, Pascal Thubert (pthubert) wrote:

>> Behalf Of