Subject: [Roll] [roll] #50: Two Clarifications for Rev 09

From: "roll issue tracker" <[email-masked]>
Date: Wed, 09 Jun 2010 14:41:02 -0000

#50: Two Clarifications for Rev 09
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  wintert@…      
     Type:  defect              |      Status:  new            
 Priority:  major               |   Milestone:                 
Component:  rpl                 |     Version:                 
 Severity:  Active WG Document  |    Keywords:                 
--------------------------------+-------------------------------------------
 From: "Mathilde Durvy (mdurvy)" <[email-masked]>
 Date: June 9, 2010 9:12:36 AM CEDT
 To: "Pascal Thubert (pthubert)" <[email-masked]>, <[email-masked]>
 Subject: Re: [Roll] leaf node and DTSN

 Hi Pascal,

 Thanks for your answer. I think it would be worth clarifying these points
 in the next RPL release.
 Best,
 Mathilde

 From: Pascal Thubert (pthubert)
 Sent: mardi, 8. juin 2010 18:58
 To: Mathilde Durvy (mdurvy); [email-masked]
 Subject: RE: [Roll] leaf node and DTSN

 Hi Mathilde

 (Tim correct me if I’m incomplete here J )

 1)      There’s at least the case when a router becomes leaf. It needs a
 DIO to poison. And if it keeps getting unicast DAOs, it needs to repeat
 poisoning. But I do not see a case where it would advertise itself as a
 router.
 2)      That would be when an inconsistency is detected and the node wants
 to refresh its cache. For instance, it has a doubt that a DAO might have
 been missing since a target is not revalidated.

 Pascal

 From: [email-masked] [mailto:[email-masked]] On Behalf Of
 Mathilde Durvy (mdurvy)
 Sent: Tuesday, June 08, 2010 4:30 PM
 To: [email-masked]
 Subject: [Roll] leaf node and DTSN

 Hi All,

 Small questions
 - Section 6.5
 What is the rationale behind a leaf node sending DIOs if nobody can attach
 to it?
 I would rather expect the node to use a DAO to advertize its presence and
 allow packets to be routed to it.
 - Section 7.1.7
 When is the DTSN incremented without having the ‘T’ flag set?

 Best,
 Mathilde

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

---

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

Comment(by jpv@…):

 --------------------------------------------

 - RPL version 10 (to be posted on June 28 or 29) will be updated to
 clarify leaf mode operation as follows:

   Operation as a Leaf Node

   In some cases a RPL node may attach to a DODAG as a leaf node only.
   One example of such a case is when a node does not understand the RPL
   Instance's OF or advertised metric/constraint.  As specified in
   Section 16.6 related to policy function, the node may either join the
   DODAG as a leaf node or may not join the DODAG.  As mentioned in
   Section 16.5, it is then recommended to log a fault.

   A leaf node does not extend DODAG connectivity but in some cases the
   leaf node may still need to transmit DIOs on occasion, in particular
   when the leaf node may not have always been acting as a leaf node and
   an inconsistency is detected.

   A node operating as a leaf node must obey the following rules:

   1.  It MUST NOT transmit DIOs containing the DAG Metric Container.

   2.  Its DIOs MUST advertise a DAGRank of INFINITE_RANK.

   3.  It MAY suppress DIO transmission, except DIO transmission MUST
       NOT be suppressed when DIO transmission has been triggered due to
       detection of inconsistency when a packet is being forwarded or in
       response to a unicast DIS message.

   4.  It MAY transmit unicast DAOs as described in Section 8.2.

   5.  It MAY transmit multicast DAOs to the '1 hop' neighborhood as
       described in Section 8.10.

   A particular case that requires a leaf node to send a DIO is if that
   leaf node was a prior member of another DODAG and another node
   forwards a message assuming the old topology, triggering an
   inconsistency.  The leaf node needs to transmit a DIO in order to
   repair the inconsistency.  Note that due to the lossy nature of LLNs,
   even though the leaf node may have optimistically poisoned its routes
   by advertising a rank of INFINITE_RANK in the old DODAG prior to
   becoming a leaf node, that advertisement may have become lost and a
   leaf node must be capable to send a DIO later in order to repair the
   inconsistency.

   In general it is not expected that such a leaf node would advertise
   itself as a router.

 - The 'T' flag is removed after discussion with the WG.

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

---

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

#50: Two Clarifications for Rev 09
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  wintert@…      
     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

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