Subject: [Roll] closing #37: Feed-back from IPSO interop

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Jun 2010 08:33:08 +0200

Dear WG:

We just published RPL 08 (also) addressing the IPSO feedback. I think that we can now close the ticket:

In more details:

> Feedback-I:
 > DAO rank: It seems there very couple of different interpretations for  setting this value.
 > A. Several implementations were setting the DAO rank to be equal to  the node rank (value sent in DIO rank). Each node relays this info in the DAO towards the root. However this does not convey any differentiating info to the receiving nodes when the DAOs are received thru multiple paths in order to install the best route.
> B. The other implementation was to set the value to 0 (or 1) by the  node and have the intermediate nodes increment it as the DAO rides up to the root. The DAO rank in this case is more of a hop count and the receiving nodes can make a decision based on the lowest value received when[Pascal]  installing the DAO route.
 > Pros: Decision is optimized based on hopcount. Relatively simple.
 > Cons: Hopcount does not take link cost into account.
> C. A third proposal was to set the DAO rank equal to the node rank  and a   link cost in the metric container as each nodes propagates the DAO.
 > The receiving nodes would make a decision based on the link cost.
 > Pros: Decision is optimized based on link cost  > Cons: The DAOs would need to carry additional info in the packet  (biggerDAOs) and more processing needed in the nodes to parse and process.
>
 > I think we need some more details the spec for describing the value to  > be set in DAO rank.
 >
 >

[Pascal] The Rank is gone from the DAO entirely. It was replaced by Roger's path control. The rationale is that the routing is computed by the router upon DIO. DAO merely informs the above about that decision. In case of source route, the root is expected to optimize the preference of the path that it is selecting.

> Feedback-II:
 > DIO Sequence number: The issue was what should be the initial value of  this field. The spec is not clear on what should be the initial value  set by the root. This has implications at the LBR in reload/reboot  conditions. For example, if the initial value is set to 1 and is  > incremented to say 10. When the LBR reloads/reboots, it would start the sequence number with 1 but its DIOs will be rejected by the nodes as having stale sequence number. The LBR can store the sequence in persistent memory. An easier option could be use 255 as the starting sequence number. Using this value will make sure that the sequence number is always valid.
 >
 > Comments?

[Pascal] 10 now has a mechanism that derives from Radia Perlman's lollipop. The mechanism includes a simple sequence counter comparison with desync detection.
More at http://tools.ietf.org/html/draft-ietf-roll-rpl-09#section-6

: )

Pascal