Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-04.txt

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 20 Nov 2009 18:13:35 +0100

Hi all,

I have received no comments on this earlier on when I posted it first so let
me repost, as I think a lot of things we discussed in Hiroshima are in line
with what I propose or talk about in this previous email to the list, i.e.
shorter spec focusing on just one instance and one root, no siblings, being
more explicit about the core set of requirements etc. Please do give some
feedback on this.

So here are some thoughts I had about draft-ietf-roll-rpl-04. Overall I
think we are moving along the right direction compared to -03, but we are
still somewhat far from the spec I think we should aim
for, if we plan on keeping our tight standardization schedule.

I insist on the fact that we should first concentrate on the "overview"
section (currently Section 3) and on an explicit Applicability
section. We should agree once and for all what these sections
should outline, and then re-populate the rest of the document accordingly
(reusing most of the corresponding existing text if possible). This is a
sure way of getting somewhere if we want to converge quickly to a solid and
consise document.

So, focusing on an applicability section and on section 3 (overview of the
protocol), I have hacked the tentative "to-the-bone" text below, during a
recent jabber chat with Thomas Clausen. Essentially it aims at clarifying
some key points, including the following:

- this protocol is about communications from sensors to a sink,
- the core set of requirements is explicit in the applicability section,
- multiple instances of the protocol are not discussed in the document (the
applicability section just states it is out of scope),
- siblings are not considered, only parents.

I think that we need to boil down to such simpler, very explicit goals if we
want a clear spec soon. I note that draft-ietf-roll-rpl-04 is still in the
100 pages ball-park. I think we should aim at a spec that is less than half
this size, more focused, along the above-mentionned lines. The idea is that
additional considerations and companion documents should off-spring from a
simple, rock-solid base.

So here it is. Again, keep in mind that this is tentative text, hacked up in
a hurry, so there is indeed room for improvement -- but maybe not enough
room for 100 pages in my book ;)

Applicability

This protocol is build to support a subset of the requirements from <reqd.
doc's> for routing in low-power sensor networks with lossy links. This
subset corresponds to a core set of functionalities that enable up to a few
thousand fixed sensors to send data to a single, well known data sink. This
protocol provides store-and-forward functionalities at the IP level, in
order to enable such communications. The protocol is designed to work even
when some, or all sensors are very limited in terms of memory (in the order
of a kByte), in terms of radio link capacity (in the order of a kB/s), as
well as in terms of CPU and battery capacity.

Multiple instances of this protocol may be used in order to provide paths to
multiple sinks. For example different traffic classes may require different
paths to be calculated towards the sink, e.g. to accommodate low-latency
requirements or prioritize urgent signaling.  Similarly, there may be
 multiple nodes in the network, each of which having a distinct application
significance, and for each of which a LLN router may have to calculate
paths.

However, the specification of the interaction between multiple instance of
the protocol is out of the scope of this document.

Protocol Overview

As the traffic flows originate from sensors and are directed towards the
sink node, each LLN router must find paths towards that sink node. The union
of all these paths form a directed acyclic graph (DAG), rooted in that the
sink node.

This protocol supports the discovery and maintenance of such a DAG,
identified uniquely by a given DAG ID, rooted at a single sink node in the
network, while respecting some given environmental constraints, i.e. paths
calculated according to a specific well-known path metric. The DAG can thus
be seen as a collection of paths of similar kind towards similar
destination.

The DAG is boot-strapped by the self-aware sink, which signals its presence
via an extension of IPv6 RA signalling. Such signalling spreads hop by
hop, among direct neighbors: each router joining the DAG chooses a
collection of parents which are closer to the root, and starts signalling
the DAG in its own RAs. This signalling contains the necessary local
information about the DAG, including the metric used to compute paths, the
DAG ID, and the distance of the emiting router to the root of the DAG.

Regards,
Emmanuel

On Thu, Oct 29, 2009 at 7:29 PM, Emmanuel Baccelli <
[email-masked]> wrote:
>
>
>
>
>
> On Mon, Oct 26, 2009 at 11:45 PM, <[email-masked]> wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Routing Over Low power and Lossy networks
>> Working Group of the IETF.
>>
>>
>>        Title           : RPL: IPv6 Routing Protocol for Low power and
>> Lossy Networks
>>        Author(s)       : T. Winter, et al.
>>        Filename        : draft-ietf-roll-rpl-04.txt
>>        Pages           : 82
>>        Date            : 2009-10-26
>>
>> Low power and Lossy Networks (LLNs) are a class of network in which
>> both the routers and their interconnect are constrained: LLN routers
>> typically operate with constraints on (any subset of) processing
>> power, memory and energy (battery), and their interconnects are
>> characterized by (any subset of) high loss rates, low data rates and
>> instability.  LLNs are comprised of anything from a few dozen and up
>> to thousands of LLN routers, and support point-to- point traffic
>> (between devices inside the LLN), point-to-multipoint traffic (from a
>> central control point to a subset of devices inside the LLN) and
>> multipoint-to- point traffic (from devices inside the LLN towards a
>> central control point).  This document specifies the IPv6 Routing
>> Protocol for LLNs (RPL), which provides a mechanism whereby
>> multipoint-to-point traffic from devices inside the LLN towards a
>> central control point, as well as point-to-multipoint traffic from
>> the central control point to the devices inside the LLN, is
>> supported.  Support for point-to-point traffic is also available.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-04.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>