Subject: [Roll] [roll] #73: determining downward routes at the root

From: "roll issue tracker" <[email-masked]>
Date: Sat, 24 Jul 2010 16:57:04 -0000

#73: [Roll] determining downward routes at the root
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  wintert@…      
     Type:  defect              |      Status:  new            
 Priority:  major               |   Milestone:                 
Component:  rpl                 |     Version:                 
 Severity:  Active WG Document  |    Keywords:                 
--------------------------------+-------------------------------------------
 ----- Original Message -----
 From: "Mukul Goyal" <[email-masked]>
 To: "Pascal Thubert (pthubert)" <[email-masked]>
 Cc: "roll" <[email-masked]>
 Sent: Tuesday, July 20, 2010 11:40:13 AM
 Subject: Re: [Roll] determining downward routes at the root

 Hi Pascal

 I think, in the absence of any explanation in the text, there is a risk
 of misinterpretation.

 So, this is my interpretation of how it will work:

 Root needs to determine the source route to node N. Root starts with
 node N's DAO, finds its highest preference parent, adds it to the route
 and then repeats the procedure with this parent. This continues until
 the route is complete.

 So, this is a greedy approach to route discovery. The underlying
 assumption seems to be that a more preferred parent is infinitely better
 for downwards routing than a less preferred parent.

 Another possibility is to let the DAG root reverse the path control
 field and use it as link cost to determine shortest paths to a
 destination using dijkstra.

 It seems to me that there needs to be some guidance, perhaps in the
 objective function, regarding how path control is to be used (for
 non-storing operation) and how would the root calculate the downwards
 routes.

 Thanks
 Mukul
 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" <[email-masked]>
 To: "Mukul Goyal" <[email-masked]>, "roll" <[email-masked]>
 Sent: Tuesday, July 20, 2010 6:26:00 AM
 Subject: RE: [Roll] determining downward routes at the root

 Hi Mukul:

 This is a pretty classical recursive route lookup. Only the highest
 preference 1hop route should show up so recursively the root will quite
 naturally build the source route header. Routing protocols usually do
 not describe such operation.

 Do you think there is a risk of misinterpretation?
 Would someone else please shime in?

 Pascal

 -----Original Message-----
 From: [email-masked] [mailto:[email-masked]] On Behalf
 Of
 Mukul Goyal
 Sent: Tuesday, July 20, 2010 11:25 AM
 To: roll
 Subject: [Roll] determining downward routes at the root

 I was wondering if it makes sense to add some text to the RPL draft
 regarding
 how does a root, in non-storing LLN, determine the _shortest_ downward
 routes to different destinations using the "path control" values as
 the (inverse)
 link costs.

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

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

---

From: "roll issue tracker" <[email-masked]>
Date: Sun, 25 Jul 2010 07:55:56 -0000

#73: [Roll] determining downward routes at the root
--------------------------------+-------------------------------------------
 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

Comment:

 Text solving the issue (agreed by Mukul) to be incorporated in revision
 11:

 A node that provisions a DAO route for a Target that has an
   associated Path Control field SHOULD use the content of that Path
   Control field in order to determine an order of preference among
   multiple alternative DAO routes for that Target.  The Path Control
   field assignment is derived from preference (of the DAO parents), as
   determined on the basis of this node's best knowledge of the "end-to-
   end" aggregated metrics in the "downward" direction as per the
   objective function.  In non storing mode the root can determine the
   downward route by aggregating the information from each received DAO,
   which includes the Path Control indications of preferred DAO parents.

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