Subject: [Roll] RPL network size and related details

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 19 Oct 2009 10:57:04 +0100

Looking at draft-ietf-roll-rpl-03, both the summary and the
introduction contain the sentence:

"Furthermore such networks may potentially comprise a large
number of nodes, up to several dozens or hundreds or more
nodes in the network."

I don't think this is a particularly well-written sentence,
and also leaves me unclear what network sizes are covered,
either by intent or by what has been demonstrated in
simulations or otherwise. (If there are such results, and
they've been referenced on the list, my apologies, I'm
afraid I haven't read quite a few of the postings. Pointers
would be welcome.) If we take that as that the protocol
should work with hundreds of nodes, and might work with
thousands (appreciating that issues such as node density
also matter) I believe that matches most of the requirements
documents, but not I think the urban sensor networks one.
Do any members of the Design Team have any comments?

On the latter point, I think since the draft credits the
Design Team, it should list them and their affiliations
(and that of T. Winter) both for information and for credit.

I also raised the use of the word "unique" referring to
the challenges of ROLL at the time of the re-charter, and
it was replaced. I would add the same here (see abstract
and introduction). In fact if the design space is only
hundreds of nodes I would definitely say it is not unique.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 19 Oct 2009 17:38:22 -0400

Date: Mon, 19 Oct 2009 10:57:04 +0100
   From: "Dearlove, Christopher (UK)" <[email-masked]>

   [...] If we take that as that the protocol

I certainly think that the goal is for RPL to work with
hundreds and at least up to a few thousand nodes.  I know of
similar routing protocols working for up to 2000 or so
devices in commercial networks.  We ought to be able to do
as well.
                               -Richard Kelsey

---

From: Tim Winter <[email-masked]>
Date: Mon, 19 Oct 2009 19:01:23 -0400

I concur, based also on the knowledge of successful commercial networks
using DV protocols similar in many key aspects to RPL.  The text should be
updated to read `thousands'.  Although there is still work to do, I do
believe RPL is on track to be capable to meet the requirements of the urban
application scenario [RFC5548].

-Tim

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 20 Oct 2009 09:40:03 +0100

Good, but I think we need to distinguish the aims, the
what we reasonably expect to achieve, and the what we
can demonstrate has been achieved. If the text contains
any non-trivial indication of scale (thousands is
non-trivial, dozens is not) it ought to indicate how
strong that indication is.

However even at thousands I don't think this is any
indication of meeting the full requirements of RFC 5548,
which says:

"The number of sensing nodes deployed in the urban
environment in support of some applications is expected to be in the
order of 10^2 to 10^7"

There's rather a lot of headroom between thousands and 10^7,
even if not all of those 10^7 are routing nodes.

Does anyone have any evidence of the viability of such a network
with, let's say 10^6 routing nodes?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tim Winter
Sent: 20 October 2009 00:01
To: ROLL WG
Subject: Re: [Roll] RPL network size and related details

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

I concur, based also on the knowledge of successful commercial networks
using DV protocols similar in many key aspects to RPL.  The text should
be
updated to read `thousands'.  Although there is still work to do, I do
believe RPL is on track to be capable to meet the requirements of the
urban
application scenario [RFC5548].

-Tim

---

From: Tim Winter <[email-masked]>
Date: Tue, 20 Oct 2009 10:32:45 -0400

To provide some additional background, one of the RFC5548 areas that may
require to operate networks on the order of 10^7 nodes are smart metering
applications in support of a large utility in a dense urban area.

RPL ought to allow a deployment in support of such a large network to
dynamically partition itself into smaller independent operating regions, by
providing for a `divide and conquer' strategy (some have used a `drainage
basin' metaphor).  Depending on the specifics of the deployment,
implementation, number of LBRs, etc. it should be feasible to cause the
partitioning such that each independent region may be operating over a
target size, e.g. on the order of 10^3 nodes.  Specifically, the ability to
provision of LBRs to act as independent DAG roots will allow them to draw
the `closest' nodes to them.  As nodes affiliate themselves with specific
LBR(s), and specific DAGs, they become logically partitioned and may exclude
interaction with other neighboring nodes that are members of other
unaffiliated DAGs.  A large deployment on the order of 10^7 nodes may then
logically be viewed as, e.g., ~10^4 DAGs with ~10^3 nodes each.  This
partitioning is dynamic and autonomous.

Regards,

-Tim

---

From: Roger Alexander <[email-masked]>
Date: Tue, 20 Oct 2009 08:08:49 -0700 (PDT)

Having successfully deployed and maintained multiple urban networks including ones of order 10^4 based on the central principle of autonomous (self-segmenting) network partitioning I can concur with the approach that Tim has discussed and how it can be applied in the context of RPL (though the required mechanisms would need to be further fully specified). 

Our current on-going experience shows that there is no inherent limitation that would prevent scalability from readily extending to networks on the order of 10^7 based on autonomous, dynamic partitioning. An important consideration of course is keeping the routing overhead low so that the partitioned segments can be large enough to limit the number of LBRs that must be deployed.

Regards,

Roger K. Alexander

--- On Tue, 10/20/09, Tim Winter <[email-masked]> wrote:

> From: Tim Winter <[email-masked]>
> To: "ROLL WG" <[email-masked]>
> Date: Tuesday, October 20, 2009, 2:32 PM
> To provide some additional
> background, one of the RFC5548 areas that may
> the `closest' nodes to them..  As nodes affiliate
> themselves with specific

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 20 Oct 2009 11:13:59 -0400

Date: Tue, 20 Oct 2009 10:32:45 -0400
   From: Tim Winter <[email-masked]>

The electric metering network in Gothenburg, Sweden works
this way.  They have 250k 802.15.4/ZigBee nodes of 8k are
DAG roots ('concentrators' in ZigBee-speak), which averages
out to about 32 nodes in each DAG.

As an aside, Gothenburg's population is about 500k, so they
have one node for every two people.  I begin to understand
all the interest in this market.

There are some more details in this presentation by the
Gothenburg utility's project manager:

http://www.zigbee.org/imwp/download.asp?ContentID=16104

                             -Richard Kelsey