Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

[C Chauvenet <[e-mail]>]

Inline,

-----Message d'origine-----
De : Mukul Goyal [mailto:[e-mail]] 
Envoyé : dimanche 8 avril 2012 23:38
À : C Chauvenet
Cc : [e-mail]; [e-mail]
Objet : Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

Hi Cedric

Please see the response inline.

Thanks
Mukul


#95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

 Resolution: No because multiple DROs would be generated if multiple source  routes are being discovered.

 Discussion:

 p15 :  Stop (S): This flag, when set to one by a target, indicates that  the P2P-RPL route discovery is over.

 [Cedric]
 Is this bit really usefull ? My guess is that it will be always set to 1.
 If you hear a DRO, this indeed means that the RDO has reached the target,  so you could just stop processing RDO when you hear a DRO.
 Do we really need a flag to stop RDO processing or the hearing of a DRO  type message could do the job ?

 [Mukul]
 A P2P-RPL invocation might involve discovery of multiple source routes. In  that case, receipt of a DRO does not mean route discovery is over. Only  when the target sets the stop flag in the DRO, a node could be sure that  the route discovery is over.

[Cedric2]
OK fo multiple discovery.
But if I want to discover a route to a multicast group of target. I set a multicast adress in the target field of the RDO. Then, do I received as many DRO message as the number of target reached ? In that case, would the first DRO with a "S" flag stop the RDO propagation to reach all the target included in the multicast group ?

[Mukul2]
A target cannot set the S flag to one in the DRO if the target address in the P2P-RDO specified a multicast address. See the following text at the end of page 21 in P2P-RPL-9:

"The target MAY set the stop flag inside the DRO message to one if



Goyal, et al.           Expires September 7, 2012              [Page 21]
 
Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012


   o  this router is the only target specified in the corresponding DIO,
      i.e., the corresponding DIO specified a unicast address of the
      router as the Target inside the P2P-RDO with no additional targets
      specified via RPL Target Options; and

" 

[Cedric3] 
So how do you stop the RDO flooding when the target adress is mulicast ? 

-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

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

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