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

From: [email-masked]
Date: Mon, 26 Oct 2009 15:45:01 -0700 (PDT)

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.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 00:28:54 +0100

draft-ietf-roll-rpl-04.txt says:
> 9.1.  RPL Control Message
> 
>    The RPL Control Message is an ICMP information message type that is
>    to be used carry DAG Information Objects, DAG Information
>    Solicitations, and Destination Advertisement Objects in support of
>    RPL operation.
> 
>    IANA has defined a ICMPv6 Type Number Registry.  The suggested type
>    value for the RPL Control Message is 155, to be confirmed by IANA.

Write TBA (To Be Assigned) instead of 155.  One never knows who gets the 
155 first.  For example, 6LoWPAN ND may get it before RPL does, as the 
6lowpan-nd draft implies:
> 13. IANA Considerations
>    This document requires two new ICMPv6 message types:
>    o  Node Registration (TBD1)
>    o  Node Confirmation (TBD2)

Besides, 155 decimal or hexa?  (for future writings of figures, very 
useful to implementer to read hexa or decimal).

Also, I wanted to say: ICMP messages often come in pairs: RS is type 133 
decimal, RA is 134, and so on (EchoReq/Rep, RS/RA, MRA/MRS, etc.)

Why not suggesting the same for RPL: RPL Req - type TBA, and RPL Resp - 
type TBA.  Instead of making them different Codes.

It's strange you talk about DAG Info Sol and Dst Adv Object as two 
different Codes, when they should be two different Types, as I feel it.

It doesn't hurt to paste the URL of the current ICMPv6 assignments - it 
will get removed during IESG reviewing time anyways.

If, by any chance one starts thinking that 155 approaches dangerously 
the limit of 255, and that you seem to apparently need a single 
"control" message (not a req/resp) then a possibility is to extend the 
RA by inventing  a new flag in RA (via RFC5175 - I am a fan), and 
extending it with new options.

> 9.4.  DAG Information Object (DIO) Suboption
> 
>    IANA is requested to create a registry for the DIO Base Option
>    Suboptions
> 
>          +-------+------------------------------+---------------+
>          | Value | Meaning                      | Reference     |
>          +-------+------------------------------+---------------+
>          |   0   | Pad1 - DIO Padding           | This document |
>          |   1   | PadN - DIO suboption padding | This document |
>          |   2   | DAG Metric Container         | This Document |
>          |   3   | Destination Prefix           | This Document |
>          |   4   | DAG Timer Configuration      | This Document |
>          +-------+------------------------------+---------------+
> 
>             DAG Information Option (DIO) Base Option Suboptions

New registry?  How will it be allocated further?  IETF Consensus action 
as the DIO Base Option?  I believe it should be said here too.

I must say I do not have a grasp on RPL overall, these are just simple 
remarks.

Alex

[email-masked] a écrit :
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tim Winter <[email-masked]>
Date: Tue, 27 Oct 2009 09:31:21 -0400

WG,

In this revision we did incorporate much of the recent feedback from the
list, including
	- Remove recommendations for DAG splitting/merging (detach/float/reattach)
	- Remove Held-Up state and related procedures
	- Remove Held-Down state and related procedures
	- Clarified that a DAG Instance is in support of a single application
objective / optimization, and that RPL specifies operation in a single DAG
Instance
	- ICMPv6 message type proposed to carry DIO/DAO message + DIO/DAO revised
(OCP now comes from Metric Container)
	- Updated DIO suboptions to be consistent with metrics draft (16 bit length)
	- Added use of flow label to specify DAG Instance and allow for loop detection
	- Misc. editorial changes

We are still working to provide an FSM presentation of RPL.

Regards

-RPL Authors

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Oct 2009 14:00:55 -0400

>>>>> "Tim" == Tim Winter <[email-masked]> writes:
    Tim> - Added use of flow label to specify DAG Instance and allow for loop detection

  Thanks, I think this will help people link things together.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 19:22:33 +0100

>   Thanks, I think this will help people link things together.

I think calling it a "flow label" may collide with the flow label field 
of IPv6 base header.

Let me tell you why I say so.  I recently went through an implementaiton 
exercise where Route Lifetime and Router Lifetime were mistaken one for 
the other, because they're close enough.

Just a remark.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Oct 2009 14:41:54 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    >>>>>>> "Tim" == Tim Winter <[email-masked]> writes:
    Tim> - Added use of flow label to specify DAG Instance and allow for
    Tim> loop detection
    >> Thanks, I think this will help people link things together.

    Alexandru> I think calling it a "flow label" may collide with the
    Alexandru> flow label field of IPv6 base header.

  That's exactly what we need to use.
  The IPv6 flow label was intended precisely for this purpose.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 19:49:37 +0100

>   The IPv6 flow label was intended precisely for this purpose.

Let's go this way then.

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 29 Oct 2009 19:29:03 +0100

Dear Rollers,

here is some feedback 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