Subject: [Roll] RPL spec v6: request for multiple clarifications

From: Phoebus Chen <[email-masked]>
Date: Wed, 03 Mar 2010 19:37:15 +0100

Hello RPL authors,

I just wanted to provide a list of suggestions on how to clarify the 
readability of the document.  I was confuse by some points.

I will send a separate email with more "minor" suggestions (nits), so as 
to not mix things up if there turns out to be a discussion thread 
following this email.

Unicast DIS vs. Multicast DIS?
------------------------------
(pg. 37, Section 5.3.5)

This was discussed earlier on the mailing list (also, Ticket item #12 on 
the Trac Issue Tracker), but I don't think the specification makes it 
clear when a node should transmit a unicast DIS and when it should 
transmit a multicast DIS.  It's not even clear to a reader that there 
are two types of DIS when DIS is introduced in Section 5.2 (maybe the 
differentiation between unicast and multicast DIS doesn't belong here 
either, but it's really easy to miss in the document).

I think the motivation was given here:
http://www.ietf.org/mail-archive/web/roll/current/msg02552.html
and the rest of the thread on DIS processing, but that should be hinted 
at in the document instead of asking an RPL implementer to search 
through the mailing list archives, right?

My understanding:
* A node should send a multicast DIS when it joins the network, to 
discover its parents.
* A node sends a unicast DIS message to obtain DIO Configuration Options

But can / should nodes send a DIS message upon detection of 
inconsistencies?  When does it reset its own trickle timer (and push out 
DIOs more frequently), and when does it send a DIS?  I think the former 
is mentioned in the specification but not the latter.

Also, since the responses to a unicast DIS and a multicast DIS are 
different, maybe there should be a message body in the DIS to indicate 
how it a node should respond, instead of the receiver trying to infer it 
from whether the DIS is unicast or multicast?

Which DIO Suboptions must be present in DIOs triggered by Trickle?
------------------------------------------------------------------
(pg. 38, Section 5.3.5.1.2)
"A metric communicated in the DIO message is determined to be 
inconsistent, as according to a implementation specific path
metric selection engine."

 From this, I would expect that the metric suboption should be in all 
DIOs that are periodically broadcast by Trickle.  If only the DIO Base 
option is required, then nodes will have to chose their parents based 
only on rank, which may result in a suboptimal choice of parents (rank 
is primarily for loop-prevention, although there are references 
throughout the document of how it should be "synced" with the cost 
metric).  Perhaps it is only omitted in response to a unicast DIS message?

Invocation of Forwarding Error Correction during Sibling Loop Avoidance
-----------------------------------------------------------------------
(pg. 55, Sec. 7.2.2.4, last paragraph)
"When a router forwards to a sibling: if the Sibling bit was not set 
then the Sibling bit is set.  If the Sibling bit was set then then the 
router SHOULD return the packet to the sibling that that passed it with 
the Forwarding-Error 'F' bit set."

This paragraph is rather confusing.  The last sentence implies that the 
current router is unable to forward to a parent, and thus must forward 
to another sibling.  This could happen because the links to the parent 
happen to be down at the moment.  But it should not forward to a 
sibling, because the sibling bit had already been set.  So it should 
discard the packet.

Instead, as written here the packet is suppose to be sent back to the 
sender with the Forwarding-Error bit set, presumably to evict current 
router from the sender's candidate neighbor set (or sibling set... 
whatever "routing states that caused forwarding to that neighbor" as 
stated in Section 7.2.2.6).  Is this the right action?  What if those 
parent links come up again?  This is not loop-prevention so much as 
pruning the mesh of nodes that have (temporary) bad connectivity.

Reminders of mechanisms that still have not been specified
----------------------------------------------------------
(pg. 32, Section 5.3.3.1)
"Another possibility is that nodes within the LLN have
some means by which they can signal detected routing inconsistencies
or suboptimalities to the DODAG root, in order to request an on-
demand DODAGSequenceNumber increment (i.e. request a global repair of
the DODAG)."

No message formats have been defined for this... I suppose this is still 
under consideration by the Working Group.  Should this be a ticket item?

(pg. 56, Section 7.2.2.5)
"If DAO inconsistency loop recovery is applied, then the router SHOULD 
send the packet to the parent that passed it with the Forwarding-Error 
'F' bit set."

This sentence seems to imply that one can turn off local loop recovery. 
  I don't see any flags or fields in the DIO Base or the DODAG 
Configuration Option that allow you to do this.

-- 
Phoebus Chen
Postdoctoral Researcher
Automatic Control Lab, KTH (Royal Institute of Technology)
http://www.ee.kth.se/~phoebus