Subject: [Roll] Questions about multiple DAGs

From: "Burnett, Peter" <[email-masked]>
Date: Tue, 14 Jul 2009 16:29:27 +0200

The RPL spec describes the use of multiple DAGs to provide different routing constraints to the same DAG root but doesn't really describe their use to provide collection paths towards multiple roots. It seems that one such use case would be for BACNET concentrators having lots of sensor devices attached. The sensors only talk to one particular BACNET concentrator and each concentrator consolidates the information to be sent elsewhere possibly over the grounded DAG. In this case the BACNET concentrator could start its own DAG for which it is the root. The path from a sensor to the concentrator DAG may have the opposite direction from the path to the grounded DAG root. Is that an intended use case?

Some questions arise:

1.       Given resource constraints how do routers decide which DAGs to attach to and which to ignore? For instance, a sensor may not be within radio range of its BACNET concentrator and so require an intermediate router to join the BACNET concentrator DAG to route its messages even though that intermediate router doesn't need to belong the BACNET concentrator DAG.

2.       If a device has joined several DAGs and requires to send a P2P message how does it decide which DAG root to direct it towards?

Thanks
Peter Burnett

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 14 Jul 2009 14:24:15 -0400

Peter,

> From: "Burnett, Peter" <[email-masked]>
> Date: Tue, 14 Jul 2009 16:29:27 +0200
>
> The RPL spec describes the use of multiple DAGs to provide different
> routing constraints to the same DAG root but doesn't really describe
> their use to provide collection paths towards multiple roots.

The RPL draft doesn't say much about which nodes are the
roots of floating DAGs.  Presumably any node can be a
floating root, although resource constraints may become a
problem if too many nodes become roots.

> Some questions arise:
> 
> 1.  Given resource constraints how do routers decide which DAGs to
> attach to and which to ignore? For instance, a sensor may not be
> within radio range of its BACNET concentrator and so require an
> intermediate router to join the BACNET concentrator DAG to route its
> messages even though that intermediate router doesn't need to belong
> the BACNET concentrator DAG.

Having every node join every DAG clearly won't scale.
My suggestion would be to recommend that nodes join
as many DAGs as resources permit, with preference
given to
  1. joining at least one grounded DAG
  2. DAGs with lower depth
in that order.  It might also make sense to allow a
DAG to have a maximum DAGDepth, either in the DIO Base
or as a suboption.

We might want to consider having a suboption that specifies
a service type.  Currently there is only one service that is
differentiated, namely having a default route.  Having other
service options would allow nodes to differentiate between
DAGs in order to have a complete set of services available.

> 2.  If a device has joined several DAGs and requires to send a P2P
> message how does it decide which DAG root to direct it towards?

Absent any other route information, I would assume it would
be forwarded using the grounded DAG with the least depth.

                        -Richard Kelsey

---

From: "Burnett, Peter" <[email-masked]>
Date: Tue, 14 Jul 2009 23:08:24 +0200

> DAG to have a maximum DAGDepth, either in the DIO Base
For a permanent floating DAG (i.e. not one temporarily detached from the grounded DAG) how about operating a locking scheme using something a bit like datapath feedback. So a router receiving RA-DIO from such a DAG will attach for a timeout period. Then any device wanting to talk to that DAG root will trickle back a DAO containing a path length slightly larger than the path length through its worst parent. This will be decremented en-route. If an intervening router sees that the remaining path length is greater than the path length to the DAG root then it locks the DAG attachment. If it is less it discards the DAO and the DAG attachment will be timed out. This way only the intervening routers on the best routes from the device to the root will remain attached to the DAG. (I know DAOs are not trickled right now but it has to be something like that)

> DAGs in order to have a complete set of services available.

That sounds good

Peter Burnett