Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-02.txt

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 13 Sep 2011 16:53:41 -0500

Dear WG,

I just added a quick note on storing mode, hoping to capture the
implementation experiences. Please take a look. Thank you.

- om_p

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Sep 13, 2011 at 4:47 PM
Subject: New Version Notification for
draft-gnawali-roll-rpl-recommendations-02.txt
To: [email-masked]
Cc: [email-masked], [email-masked]

A new version of I-D, draft-gnawali-roll-rpl-recommendations-02.txt
has been successfully submitted by Omprakash Gnawali and posted to the
IETF repository.

Filename:        draft-gnawali-roll-rpl-recommendations
Revision:        02
Title:           Recommendations for Efficient Implementation of RPL
Creation date:   2011-09-13
WG ID:           Individual Submission
Number of pages: 6

Abstract:
  RPL is a flexible routing protocol applicable to a wide range of Low
  Power and Lossy Networks.  To enable this wide applicability, RPL
  provides many configuration options and gives implementers choices on
  how to implement various components of RPL.  Drawing on our
  experiences, we distill the design choices and configuration
  parameters that lead to efficient RPL implementations and operations.

The IETF Secretariat

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 13 Sep 2011 15:27:06 -0700

Omprakash,

thanks for the update of the draft. For easier discussion, I have included
the paragraph you have added in the draft:

"A naive implementation of storing mode will have large state
overhead, especially in large networks. However, it is possible for
storing mode to use RAM efficiently by state aggregation,
compression, and other techniques. Current open source
implementations are known to limit the routing table size to 30
(TinyOS on TelosB which has 10KB of RAM) and 100 (Contiki on
MSP430F5438-based platform which has 16K of RAM)."

I think it is useful for implementers to have such a paragraph which
describes the trade-offs and considerations to make before deploying an RPL
network in either of the modes of operation.

I agree that compression and other mechanisms can reduce the state to some
degree. When using compression, I would assume that a constant factor can be
gained (with possible loss of scope of addresses). But the tables will still
grow with O(n) with n being the nodes in the network. Maybe we could add
that to the sentence?
Concerning aggregation, I am not convinced that this always may work
efficiently, in particular when the network is dynamic (some nodes may be
added later, others may be replaced etc). In that case, the address space
could be non-continuous, which would require some additional protocol to
handle the assigned addresses intelligently, or the aggregation would be
much less effective.

Regards
Ulrich

On Tue, Sep 13, 2011 at 2:53 PM, Omprakash Gnawali
<[email-masked]>wrote:

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

---

From: Omprakash Gnawali <[email-masked]>
Date: Sun, 18 Sep 2011 00:42:22 -0500

> handle the assigned addresses intelligently, or the aggregation would be

I think everyone agrees that storing mode may not be the right
solution always. Regarding quantifying scaling assuming certain type
of aggregation, this might not be the best document. I can count how
big an entry is in some open source implementations as Cedric suggests
in another email.

What would be very helpful is people sharing their experiences running
storing and non storing modes. I am happy to update the document so
others can benefit from such experiences.

- om_p