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

From: Mukul Goyal <[email-masked]>
Date: Sat, 19 Sep 2009 10:08:14 -0500 (CDT)

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

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 21 Sep 2009 10:40:17 -0400

Mukul,

   Date: Sat, 19 Sep 2009 10:08:14 -0500 (CDT)
   From: Mukul Goyal <[email-masked]>

   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?
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 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.
                             -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Sep 2009 17:12:37 +0200

Hi Mukul:

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?

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.
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll