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

From: "roll issue tracker" <[email-masked]>
Date: Thu, 03 Jun 2010 07:58:26 -0000

#36: Feedback from ZigBee interop event
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  pthubert@…                        
     Type:  defect              |       Status:  closed                            
 Priority:  major               |    Milestone:                                    
Component:  rpl                 |      Version:                                    
 Severity:  Active WG Document  |   Resolution:  fixed                             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 From: "Pascal Thubert (pthubert)" <[email-masked]>
 Date: June 2, 2010 11:03:57 AM CEDT
 To: <[email-masked]>, <[email-masked]>, <[email-masked]>
 Subject: closing #36: Feedback from ZigBee interop event

 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

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/36#comment:1>
roll <http://tools.ietf.org/wg/roll/>