Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

[C Chauvenet <[e-mail]>]

Hi,

Thank you for the link.

As mentioned in the sentence, this is related to the TinyRPL/BLIP implementation of RPL runing on TelosB nodes.
TelosB offers 48K of ROM and 10K of RAM.
As far as I understand, the 30 nodes limitation is related to the TelosB architecture (RAM size in particular) and not RPL.
Because TelosB has been designed in 2004, we can expect that platforms used for RPL deployments of today may have quite different characteristics.

Author may complete my understanding.

Cédric.

De : [e-mail] [mailto:[e-mail]] De la part de Ulrich Herberg
Envoyé : mardi 6 septembre 2011 06:52
À : Omprakash Gnawali
Cc : roll WG
Objet : Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Omprakash,

I believe the paper he refers to is that:
J. Ko, S. Dawson-Haggerty, O. Gnawali, D. Culler, A. Terzis, "Evaluating the Performance of RPL and 6LoWPAN in TinyOS"
http://hinrg.cs.jhu.edu/joomla/images/stories/TinyRPL.pdf

Omprakash, you are an author of that paper :-)

The paper states: "In our experiments with downstream routing in storing mode, we noticed that the current TinyRPL/BLIP implementations on TelosB motes support up to ∼30 target destinations. This argues that to support routes to all nodes in the RPL network, the network’s size must be limited to ∼30 nodes."

Regards
Ulrich
On Mon, Sep 5, 2011 at 8:41 PM, Omprakash Gnawali <[e-mail]<mailto:[e-mail]>> wrote:
Can someone post a link to the paper being referenced? Thanks.

- om_p

On Mon, Sep 5, 2011 at 6:22 PM, Ietf Roll <[e-mail]<mailto:[e-mail]>> wrote:
> This is good news that Zigbee is making it work.  I guess that since your
> requirements are only 30 nodes then that matches the paper that says RPL for
> constrained devices should be limited to 30 nodes.
> It is also good to be re-affirmed that downward routing is not particularly
> good in RPL.  Others have already stated this and Zigbee seems to confirm
> this.
>
> Rav
> PS - Since many keep pointing at me, I am not putting my full name and
> company in my email for I fear retribution.  I do not want to lose my job
> for asking questions and criticizing parts of the RPL design.  I do not want
> my company or my supervisor called by people like a chair and have my job
> put at risk.
> ________________________________
> From: Don Sturek <[e-mail]<mailto:[e-mail]>>
> To: Ietf Roll <[e-mail]<mailto:[e-mail]>>; JP Vasseur <[e-mail]<mailto:[e-mail]>>; Thomas Heide
> Clausen <[e-mail]<mailto:[e-mail]>>
> Cc: roll WG <[e-mail]<mailto:[e-mail]>>
> Sent: Sunday, September 4, 2011 7:20 AM
> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new
> ROLL WG document
>
> Here are a few points to maybe consider:
> 1)   ZigBee is not "having problems making it work" (referring to ROLL RPL.
>   I chair the group in ZigBee testing "ZigBee IP" and we have had relatively
> good success using RPL for the use cases we are considering.
> 2)   The Smart Energy 2.0 use cases are for only 30 devices in a single home
> area network.   We are testing 30 nodes with 3 hops
> 3)   The upward routing feature in RPL is quite efficient.  The downward
> routing feature either assumes storing mode (which we don't use) or
> non-storing mode with source routing (which does not offer pro-active or
> re-active route establishment).
> 4)   I personally would not use ROLL RPL as it is for low latency
> applications like lighting control, home automation, etc.   I fully support
> the ROLL RPL P2P draft for these applications.
> On additional, perhaps related topics:
> 5)  I don't believe there will be only a single mesh routing protocol
> defined for all applications in IETF.  I fully support the work going on in
> MANET and also think "mesh under" solutions will also be useful for some
> applications
> And finally:
> 6)  All this said, I think ZigBee IP will successfully conclude testing
> using ROLL RPL…………
> Happy to sign my real name,
> Don Sturek
>
>
>
> From: Ietf Roll <[e-mail]<mailto:[e-mail]>>
> Reply-To: Ietf Roll <[e-mail]<mailto:[e-mail]>>
> Date: Sat, 3 Sep 2011 00:54:25 -0700 (PDT)
> To: JP Vasseur <[e-mail]<mailto:[e-mail]>>, Thomas Heide Clausen
> <[e-mail]<mailto:[e-mail]>>
> Cc: roll WG <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new
> ROLL WG document
>
> JP Vasseur wrote:
>
> *if* you think that this not elegant enough (which has to be demonstrated
> IMO), then you must be supportive
> of the P2P IDs work that the WG has been working on ?
> [rav] how about a demonstration that RPL actually works as purported.
> Thomas has said that his group implemented it and it was difficult, complex
> and fraught with inconsistencies in specification.
>          I heard that zigbee is having problems making it work and the only
> paper that I've seen on RPL says that for constrained nodes they recommend
> no more than 30 nodes in a network.  Hardly the scale necessary for some of
> the
>          use cases been suggested (like AMI).
>
>          The P2P is a hack to try to fix the fact the RPL is basically a
> collection tree and as such downward routing is an distant after thought
> (certainly not elegant).
>
>          Without lots of memory, node must use non-storing mode (oh and we
> are talking about constrained devices so lots of memory is then
> inconsistent) and then routing is up to the root and back down.  Not what
> anyone who
>          understands routing would consider elegant P2P.
>
>          In the rush to get RPL out of the working group we all were
> bamboozled by the chair into believing the draft was actually complete and
> the IESG further compounded this error.
>
>          If it were possible to fix things, RPL should be an experimental
> draft until such time as there are working interoperable implementations
> that are shown to provide the services that were required in the various
> Use-case
>          drafts - or even just one of them.
>
>          And now we are rushing to generate and publish a marketing document
> (called an applicability statement) without having any experience with the
> protocol.
>
>          Are we rushing and putting so much pressure and bending the systems
> so that this gets published before we find we've built a house of cards and
> it comes crashing down.
>
>          This will be really counter productive to the industry and the
> Internet (certainly not Thomas's warnings).  When everyone looks at this
> mistake and says, why didn't the IETF do its job and exercise proper
> engineering, then the ROLL WG
>           and the Chairs will be the ones that have hurt the industry and
> the Internet.
>
> Rav
>
> _______________________________________________ Roll mailing list
> [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/roll
>
>
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll