Subject: [Roll] closing #36: Feedback from ZigBee interop event

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Jun 2010 11:03:57 +0200

Dear WG:

We just published RPL 08 addressing the Zigbee feedback. I think that we can now close the ticket:

In more details:

>  1. Need clarification on the Rank and DagRank. The root rank has value of
>  1 but not clear if that is just the integer part or not.

[Pascal] 08 says:

"ROOT_RANK  This is the rank for a DODAG root.  ROOT_RANK has a value
         of MinHopRankIncrease (as advertised by the DODAG root), such
         that DAGRank(ROOT_RANK) is 1."

Where

              "DAGRank(rank) = floor(rank/MinHopRankIncrease)"

Where floor(x) = ⌊x⌋ is the largest integer not greater than x.

So the text is consistent. 

JP suggested that we clearly point out that floor is actually this well-known function, which we'll do in 09.

> 
>  2. In OF0, the values for minRankIncrease and maxRankIncrease take value
> of 256 which cannot be represented in the DoDAG config suboption ( which
> allows only 1 byte ). This needs to be fixed in the spec. Also, re-  consider if
> we really need fractional part in the rank, it doesn’t seem to  be very useful.

[Pascal] OF0 will be made clearer that it does not use the lowest order part of the Rank.
08 now has room for the 2-byte rank:
"
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 4    | Option Length |  Resvd  | PCS | DIOIntDoubl.  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  DIOIntMin.   |   DIORedun.   |        MaxRankIncrease        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      MinHopRankIncrease       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 16: Format of the DODAG Configuration Option
"

> 
>  3. Clarify the IP source address for DIS/DAO packets - should this be the  link
> local or global address ( or either ) ?

[Pascal] 08 says:

"   A RPL Control Message has the scope of a link.  The source address is
   a link local address.  The destination address is either all routers
   multicast address (FF02::2) or a link local address.
"

Additionally, we are working on a Reverse RH and a Record Route to be able to use RPL message to learn a source route path, to be published soon.

> 
>  4. Need clarification on flowlabel. Currently it is not possible to  implement as
> defined ( without layer violations ) since a node will need  to know if the next
> hop is the final destination and if the previous hop  was the originator of the
> packet…..current implementations have removed  flow label validation

[Pascal] 08 is a bit vague still about this, and we are waiting for progress on the 6MAN front
08 says "

RPL loop detection uses information that is placed into the packet.
   A future version of this specification will detail how this
   information is carried with the packet (e.g. a hop-by-hop option
   ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow
   label).  For the purpose of RPL operations, the information carried
   with a packet is constructed follows:

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |O|S|R|F|0|0|0|0| RPLInstanceID |          SenderRank           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          RPL Packet Information
"

We are very clear that we want most of the information in the new option, but the instanceID.
Whether the instanceID is in the clear in the flow label or in the option but inferred from the flow label is still under discussion.

> 
>  5. Need clarification on the use of the destination prefix. How many of  them
> can be included in a DIO ? Is this intended to be the prefix of the  6lowpan or
> is this a prefix that can be reached by the root node ( on the  wired side ) ?

[Pascal] 08 now includes ND's RIO and PIO. PIO is the former and RIO is the LATTER.

>  6. Does RPL intend to define messages to allow neighboring nodes to
> exchange bidirectional link quality estimates between themselves ?

[Pascal] there was a long discussion on this. Currently that is out of scope.
Does anyone really want to open this box?

Pascal