Subject: [Roll] [roll] #55: Downward routes in RPL rev -09

From: "roll issue tracker" <[email-masked]>
Date: Mon, 05 Jul 2010 12:39:48 -0000

#55: Downward routes in RPL rev -09
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  pthubert@…        
     Type:  defect           |      Status:  new               
 Priority:  major            |   Milestone:                    
Component:  rpl              |     Version:                    
 Severity:  In WG Last Call  |    Keywords:                    
-----------------------------+----------------------------------------------
 Email from Ralph Droms - June 27

 Some details of the transmission and use of DAOs in a non-storing mode
 LLN are unclear to me...

 1) How are DAO messages delivered from source to destination?  I read
 list item 2 in section 8.7:

  2.  On receiving a unicast DAO, a node MUST forward the DAO upwards.
      This forwarding MAY use any parent in the parent set.

 to mean that:

 a) the sending node sets the IP destination address of the DAO
  to the address of one of its DAO parents
 b) the receiving node, in turn, sends the DAO to one of its (the
  receiving node's) DAO parents

 However, later in section 8.7, this text:

  Nodes aggregate DAOs by sending a single DAO with multiple RPL Target
  Options.

 leads me to believe that the receiving node "consumes" the DAO
 messages it receives (during the delay time specified in section 8.4)
 and constructs a new DAO message that aggregates the information from
 those received DAO messages.

 2) Is the interpretation of RPL Target and Transit Information options
 in a DAO of dependent on the order and context in which those options
 appear?  That is, are a string of consecutive RPL Target options
 considered a set of targets, for which a following string of Transit
 Information options are considered to hold the set of parents?

 3) In the first bullet list item of section 8.1, does "subset of its
 parent set" mean "subset of its DODAG parent set"?

 4) In section 8.3:

  1.  Each time a node generates a new DAO, the DAOSequence field MUST
      increment by at least one since the last generated DAO.

 what does "generates a new DAO" mean?  How does this rule apply to 1),
 above?

 5) In section 8.3:

  2.  Each time a node link-local multicasts a DAO, the DAOSequence
      field MUST increment by one since the last link local multicast
      DAO.

 why does this rule only apply to multicast?
 _______________________________________________
 Roll mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/roll

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/55>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 05 Jul 2010 12:40:18 -0000

Comment(by jpv@…):

 Email from Phil Levis

 On Sun, 2010-06-27 at 16:00 -0400, Ralph Droms wrote:
 Some details of the transmission and use of DAOs in a non-storing mode
 LLN are unclear to me...

 to mean that:

 The second conclusion is correct. The 2. bullet should probably read

 2. On receiving a unicast DAO, a node MUST forward the updated downward
 route information upwards. This forwarding MAY use any parent in the
 parent set. The downward route information in the DAO MAY be aggregated
 with other DAOs before being forwarded upwards.

 Is that better?

 The pattern is

 (Target, Transit+)+

 Yes -- I think -10 reflects this.

 4) In section 8.3:

 "Generates a new DAO" means "send a DAO with different information."
 E.g., different field values, options, option values, etc.
 Retransmitting a DAO with the same information (e.g., due to the lack of
 a DAO-Ack) does not require incrementing the sequence number. This is
 for the case where the DAO parent received the message but the ack was
 lost.

 5) In section 8.3:

 Good question -- I don't know. It should not apply to unicast due to the
 ack mechanism. Pascal, Tim?

 Phil

 __________________

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

---

From: "roll issue tracker" <[email-masked]>
Date: Thu, 22 Jul 2010 19:21:51 -0000

#55: Downward routes in RPL rev -09
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  pthubert@…        
     Type:  defect           |       Status:  closed            
 Priority:  major            |    Milestone:                    
Component:  rpl              |      Version:                    
 Severity:  In WG Last Call  |   Resolution:  fixed             
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by jpv@…):

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

Comment:

 The text below is incorporated in rev-11 of RPL, which closes that ticket:

 1 and 4)  DAO messages are consumed and regenerated by the unicast
          destination.  (Note that in consideration of Ticket 57 that
          destination may the DODAG root)  We updated the text to help
          clarify this in RPL-11 as follows:

   Generation of DAO Messages

   A node might send DAO messages when it receives DAO messages, as a
   result of changes in its DAO parent set, or in response to another
   event such as the expiry of a related prefix lifetime.  In the case
   of receiving DAOs, it matters whether the DAO message is "new," or
   contains new information.  In non-storing mode, every DAO message
   a node receives is "new."  In storing mode, a DAO message is "new"
   if it satisfies any of these criteria for a contained Target:

   1.  it has a newer Path Sequence number,

   2.  it has additional Path Control bits, or

   3.  is a No-Path DAO message that removes the last downward route to
       a prefix.

   A node that receives a DAO message from its sub-DODAG MAY suppress
   scheduling a DAO message transmission if that DAO message is not new.

   ------

   DAO Transmission Scheduling

   Because DAOs flow upwards, receiving a unicast DAO can trigger sending
   a unicast DAO to a DAO parent.

   1.  On receiving a unicast DAO message with updated information,
       such as containing a Transit Information option with a new Path
       Sequence, a node SHOULD send a DAO.  It SHOULD NOT send this DAO
       message immediately.  It SHOULD delay sending the DAO message in
       order to aggregate DAO information from other nodes for which it
       is a DAO parent.

   2.  A node SHOULD delay sending a DAO message with a timer (DelayDAO).
       Receiving a DAO message starts the DelayDAO timer.  DAO messages
       received while the DelayDAO timer is active do not reset the timer.
       When the DelayDAO timer expires, the node sends a DAO.

   3.  When a node adds a node to its DAO parent set, it SHOULD schedule
       a DAO message transmission.

   DelayDAO's value and calculation is implementation-dependent.

 2) RPL-11 clarifies the DAO structure as follows:

   Structure of DAO Messages

   DAOs follow a common structure in both storing and non-storing
   networks.  In the most general form, a DAO message may include
   several groups of options, where each group consists of one or more
   Target options followed by one or more Transit Information options.
   The entire group of Transit Information options applies to the entire
   group of Target options.  Later sections describe further details
   for each mode of operation.

 3) Text is updated as follows for RPL-11:

   o  A node's DAO parent set MUST be a subset of its DODAG parent set.

 4) See #1 above

 5) The rule "Each time a node link-local multicasts a DAO, the DAOSequence
   field MUST increment by one since the last link local multicast
   DAO" is removed for RPL-11

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