Subject: [Roll] [roll] #57: Proposed change: Routing DAOs in non-storing DODAGs

From: "roll issue tracker" <[email-masked]>
Date: Tue, 13 Jul 2010 09:11:28 -0000

#57: Proposed change: Routing DAOs in non-storing DODAGs
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  richard.kelsey@…        
     Type:  enhancement      |      Status:  new                     
 Priority:  major            |   Milestone:                          
Component:  rpl              |     Version:                          
 Severity:  In WG Last Call  |    Keywords:                          
-----------------------------+----------------------------------------------
 Email from Richard Kelsey:

 ROLLers,

 After some discussion with Pascal and others, I would like
 to propose that in non-storing DODAGs that DAOs be sent
 directly to the root rather than being processed as RPL
 messages at each hop.  The main reason to do this is that
 the DAO acks can then also be sent end-to-end rather than
 one hop, which avoids some hard-to-handle error cases.
 Using end-to-end acks is both simpler and more robust.

 In general it makes sense to send the DAOs end-to-end, as in
 non-storing DODAGs the intermediate nodes do not make use of
 the information in the DAOs.  Sending them directly reduces
 the amount of processing on intermediate nodes.

 One other change is needed for this to work: in order to
 send a DAO to the root, the root's address must be known.
 Part two of the proposal is that the DODAGID be required to
 be a routable address of the root.  The draft currently
 gives this as a possibility; the change is to make it a
 requirement.  While this would only be needed for
 non-storing DODAGs, it would be cleaner to require it
 always.

 Thoughts?
                             -Richard Kelsey

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

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

---

From: "roll issue tracker" <[email-masked]>
Date: Sat, 24 Jul 2010 08:59:54 -0000

#57: Proposed change: Routing DAOs in non-storing DODAGs
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  richard.kelsey@…        
     Type:  enhancement      |       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:

 RPL-11 has been updated to allow a DAO to be sent to a DODAG root in
 non-storing mode as follows:

 Terminology:

   DODAGID:  The identifier of a DODAG root.  The DODAGID is unique
         within the scope of a RPL Instance in the LLN.  The tuple
         (RPLInstanceID, DODAGID) uniquely identifies a DODAG.

  -----

 DAO Message:

   Destination Advertisement Object (DAO)

   The Destination Advertisement Object (DAO) is used to propagate
   destination information upwards along the DODAG.  In storing mode
   the DAO message is unicast by the child to the selected parent(s).
   In non-storing mode the DAO message is unicast to the DODAG root.
   The DAO message may optionally, upon explicit request or error,
   be acknowledged by its destination with a Destination Advertisement
   Acknowledgement (DAO-ACK) message back to the sender of the DAO.

   .....

   K:    The 'K' flag indicates that the recipient is expected to send a
         DAO-ACK back.  (See Section 9.3

   D:    The 'D' flag indicates that the DODAGID field is present.  This
         flag MUST be set when a local RPLInstanceID is used.

   DAOSequence:  Incremented at each unique DAO message from a node and
         echoed in the DAO-ACK message.

  .....

   A special case of the DAO message, termed a No-Path, is used in storing
   mode to clear downward routing state that has been provisioned through
   DAO operation.  The No-Path carries a Target option and an associated
   Transit Information option with a lifetime of 0x00000000 to indicate
   a loss of reachability to that Target.

  -----

 DAO-ACK message:

   The DAO-ACK message is sent as a unicast packet by a DAO recipient
   (a DAO parent or DODAG root) in response to a unicast DAO message.

   .....

   DAOSequence:  Incremented at each DAO message from a node, and echoed
         in the DAO-ACK by the recipient.  The DAOSequence is used to
         correlate a DAO message and a DAO ACK message and is not to be
         confused with the Transit Information option Path Sequence that
         is associated to a given target down the DODAG.

  -----

 Transit Information option:

   A typical non-storing node will use multiple Transit Information
   options, and it will send the DAO message thus formed directly to
   the root.  A typical storing node will use one Transit Information
   option with no parent field, and will send the DAO message thus formed,
   with additional adjustments to Path Control as detailed later, to
   one or multiple parents.

  -----

 DIO Base Rules:

   3.  The DODAGID field each root sets MUST be unique within the RPL
       Instance and MUST be a routable IPv6 address belonging to the root.

  -----

 Destination Advertisement Parents:

   To establish downward routes, RPL nodes send DAO messages upwards.
   The next hop destinations of these DAO messages are called DAO parents.
   The collection of a node's DAO parents is called the DAO parent set.

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

   2.  In storing mode operation, a node MUST NOT send unicast DAO
       messages to nodes that are not DAO parents.

   3.  In non-storing mode operation, a node MUST NOT send unicast
       DAO messages to nodes that are not DODAG roots.

   4.  A node MUST NOT forward unicast DAO messages to nodes that are
       not DAO parents.

   5.  A node MAY send DAO messages using the all-RPL-nodes multicast
       address, which is an optimization to provision one-hop routing.
       The 'K' bit SHOULD be cleared on transmission of the multicast DAO.

   6.  The IPv6 Source Address of a DAO message MUST be the link local
       address of the sending node.

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