Subject: Re: [Roll] Need_Route option/Source initiated route discovery in RPL

From: Mukul Goyal <[email-masked]>
Date: Mon, 21 Sep 2009 12:16:08 -0500 (CDT)

Richard

>>   I was wondering what folks think about a new option to be
>>   carried in RAs - a Need_Route option that carries the
>>   list of destination prefixes to which the advertizing
>>   routers need to reach.

>I am with you so far.

>>   The information in Need_Route options sent by the
>>   neighbor routers would give a router some guidance
>>   regarding which DAGs to join.

>Now you have lost me.  How would this give guidance?

The following example illustrates what I meant by guidance:

Suppose node A needs to reach node B. Node A lists node B in the Need_Route option carried in its RA. Node C receives this RA and stores the need of a neighbor to reach B and perhaps also includes B in the Need_Route option in its own RA. Now, if node C receives a DIO with node B as root it knows that it may join this DAG to help a neighbor (A) reach B.

>Obviously, it makes sense for a node to join a DAG that
>lists that node as a destination.  If a node does not
>join a DAG because it is not a wanted destination, how
>do you find routes?  Perhaps that node is a necessary
>relay for the desired route.

>>   This option will allow AODV-like route discovery without
>>   causing network wide packet broadcasts.

>Only if (1) the root is willing to put up with the latency
>of normal RA transmissions 

True. One option to reduce the latency of route discovery would be reset the trickle timers on receiving RAs with a new/modified Need_Route option.

>and (2) if this, along with all
>the other options, don't cause RAs to overflow a single
>message.  Piggybacking on RAs is not the same thing as
>being free.

Agree.

Thanks,
Mukul
                             -Richard Kelsey

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 21 Sep 2009 12:44:39 -0500 (CDT)

Pascal,

>The way we designed ROLL is a main protocol and then additions, for
>instance in the form of different neighboring protocols and objective
>functions. 

>You might think of an OF which goal is to be reached by someone as
>opposed to reach something. In the OF optional data you'd mention which
>you want to be reached by. So it seems to me that there's a way to get
>there. 

>Whether that OF should be in the base spec is another story. The current
>is really heavy and we already need to cut/simplify. Also we have to
>weight the pro/cons of that methods (that I'd call a pull) vs. the
>method where that destination forks its own DAG (that I'd call a push).
>Do we need both? What's more appropriate to which use case?

I guess I am OK with whether the Need_Route option ends up in base specs or not. Just one clarification. The way I see it, the Need_Route option serves as a guidance to the nodes regarding which DAGs they should join (I gave an example of how this would work in my previous email to Richard). DAGs are still rooted at destinations rather than at sources. I am certainly not suggesting source-rooted DAGs.

Thanks
Mukul

>Anyway the idea is on the table, subject to the support of multiple DAGs
>in the base spec.

>Cheers,

>Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukul Goyal
>Sent: samedi 19 septembre 2009 17:08
>To: roll
>Subject: [Roll] Need_Route option/Source initiated route discovery in
RPL
>
>Hi all,
>
>I was wondering what folks think about a new option to be carried in
RAs - a Need_Route option that carries
>the list of destination prefixes to which the advertizing routers need
to reach. The information in Need_Route
>options sent by the neighbor routers would give a router some guidance
regarding which DAGs to join. This
>option will allow AODV-like route discovery without causing network
wide packet broadcasts.
>
>With this option in place, optimal P2P routing becomes possible in RPL.
>
>Thanks
>Mukul
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll