Subject: [Roll] few questions regarding RPL

From: Calin Crisan <[email-masked]>
Date: Sat, 13 Feb 2010 23:11:52 +0100

Hi,

    I'm working on a RPL simulator and I have some questions with respect to
the version 6 of the RPL draft:
(1) At page 32, the document says "*
During transition to a new DODAG Iteration, a node may decide to
forward packets via ’future parents’...
". My question here is why do we speak about "transition" in this case?
Isn't this process of following a new iteration of the same DODAG immediate?
Everything that has to be done in this case is re-evaluate the
parents/siblings and its own rank, which in my opinion should take place
instantly, based on the already stored information. Further sending of new
DIO info shouldn't affect the routing decision, should it?*
*(2) What's the exact usage of a "multicast DIS message", as mentioned at
the top of the page 37? More precisely, in what situation is it sent?*
*
*
*    Thanks,*
*
*
*    Calin.*
*
*

---

From: Tim Winter <[email-masked]>
Date: Mon, 15 Feb 2010 14:31:44 -0500

Hi Calin,

Calin Crisan wrote:
>     Hi,
> 
>     I'm working on a RPL simulator and I have some questions with
> respect to the version 6 of the RPL draft:
> (1) At page 32, the document says "////
> ////
> //"//. My question here is why do we speak about "transition" in this
> case? Isn't this process of following a new iteration of the same DODAG
> immediate? Everything that has to be done in this case is re-evaluate
> the parents/siblings and its own rank, which in my opinion should take
> place instantly, based on the already stored information. Further
> sending of new DIO info shouldn't affect the routing decision, should
> it?////

Here the spec leaves some room to the implementation.  Some implementations may
choose to immediately transition to the new iteration, others may choose to delay
somewhat.  Consider for example the case where a node hears a DIO for a new iteration
from a candidate neighbor that is not presently in the DODAG Parent set -- perhaps
such a node would benefit by waiting a small delay to hear from present DODAG Parents
before moving.  A node has not necessarily 'committed' to the next DODAG iteration
until it has advertised a DIO to that effect (i.e. with the new sequence number).

> ////(2) What's the exact usage of a "multicast DIS message", as
> mentioned at the top of the page 37? More precisely, in what situation
> is it sent?////

The most common use case might be where a node needs to 'probe' its neighborhood and
does not want to wait for neighbors to send DIOs.  For example, a battery powered
node may benefit from soliciting DIOs from its neighbors (e.g. at
installation/provisioning).

> ////
> ////
> ////    Thanks,////
> ////
> ////
> ////    Calin.////
> ////
> ////

Regards,

-Tim

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

---

From: Calin Crisan <[email-masked]>
Date: Mon, 15 Feb 2010 21:59:36 +0100

Hi Tim,

    Thanks for the answers. For the first question everything is clear now.
Concerning the second one, I guess I was misled by the sentence on page 29:
"*This suboption MAY be included occasionally by the DODAG Root, and MUST be
included in response to a unicast request, e.g. a DODAG Information
Solicitation (DIS) message.*", and the one at page 37: "*When a node
receives a unicast DIS message, it MUST unicast a DIO message in response,
and MUST include the DODAG Configuration Object.*". The only
explicit occurrence of multicast DIS is on the same page 37, which simply
requires a trickle timer reset. Should this timer be reset whenever a new
node probes for nearby DODAGs, anyway?

    Thanks,

    Calin.