Subject: [Roll] floating DAGs

From: Mukul Goyal <[email-masked]>
Date: Sun, 6 Sep 2009 22:00:56 -0500 (CDT)

"A DAG may also be floating, in which case the node rooting the DAG is
   not offering a default route.  Floating DAGs may be encountered, for
   example, during coordinated reconfigurations of the network topology
   wherein a node and its sub-DAG breaks off the DAG, temporarily
   becomes a floating DAG, and reattaches to a grounded DAG at a
   different (more optimal) location.  (Such coordination endeavors to
   avoid the construction of transient loops in the LLN).  A DAG, or a
   sub-DAG, may also become floating because of a network element
   failure."

The quoted text (the last paragraph on page 11, rpl-00 draft) gives the impression that the floating DAGs are transient in nature. But, some applications may want to have floating DAGs of permanent nature, i.e. permanent DAGs rooted at popular destination nodes that dont offer default routes outside the LLN. Perhaps, the text quoted above needs to change.

Thanks
Mukul

---

From: Tim Winter <[email-masked]>
Date: Mon, 07 Sep 2009 07:26:54 -0400

Hi Mukul,

> The quoted text (the last paragraph on page 11, rpl-00 draft) gives the impression that the floating DAGs are transient in nature. But, some applications may want to have floating DAGs of permanent…

Yes, you are right- and the scenario you describe is something that needs to be
supported.  The next revision will re-work this text.  There is a need to
convey two orthogonal properties:
	1) Is the DAG root offering a default route?
	2) Is the DAG root permanent/transient?  (e.g. the DAG is permanent/popular to
service an application objective or transient for DAG repair)?

The first property, whether or not the node offers the default route, may be
indicated by grounded/floating.

The second property, whether or not the LLN should be engineered to tend to
join a DAG rooted at the node, may be controlled through the DAGPreference.
Nodes who play a special role in an application scenario such that they are
suited/desired to act as a `permanent' DAG root may advertise a low
DAGPreference, e.g. 0x00.  Nodes who are acting as transient DAG Roots, e.g.
for DAG repair, may advertise a high DAGPreference, e.g. 0xFF.  During DAG
Maintenance nodes may then seek to join DAGs of lower preference.

(Please note that this approach is a slight deviation from that described in
the prior thread `RPL Grounded Flag'
http://www.ietf.org/mail-archive/web/roll/current/msg01594.html)

Regards,

-Tim

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

---

From: "Don Sturek" <[email-masked]>
Date: Mon, 7 Sep 2009 08:46:16 -0700

Hi Tim,

I have been meaning to send in a nice formatted example with a clear picture
but have failed to find the time (so sorry for the poor diagram provided
below).   Here is a question that I have had around the RPL draft for some
time.

Assume devices A, B, C and D where:
	A is the DAG root
	B is a child of A with a depth/rank/cost of 1
	C is a child of A with a depth/rank/cost of 3
	D is a child of B with a depth/rank/cost of 2 

                                                                A
                                                               / \
                                                            1 /   \ 3
                                                             /     \
                                                            B       C
                                                           /        .     
                                                            \      .
                                                            2\    .1 (not a
child link)
                                                              \  .
                                                               D
                                                              / \
                                                            1/   \1
                                                            /     \
                                                           E       F

Suppose E and F are also of lower depth/rank communicating through D

If D loses contact with B (say through permanent failure of B) then I don't
see in the current draft how the ungrounded DAG formed now by D ever is
permitted to restore communication to the DAG root through C.

I know all of the reasons we don't want D, E and F to attempt to reattach to
C on their own and why support for the ungrounded DAG formed by D is desired
for network maintenance reasons but at some point it would be nice to
address this scenario (unless I am wrong and this is supported in the
current proposal).

By the way, this type of problem comes up often in real life in the
following cases:
1)   Building/homes where devices are located down corridors
2)   Commercial buildings around fire escapes
3)   Sparse topologies like smart energy in early deployment where there are
relatively few devices in the home and we need to reach the meter located
outside of the home (through building materials).

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim
Winter
Sent: Monday, September 07, 2009 4:27 AM
To: Mukul Goyal
Cc: ROLL WG
Subject: Re: [Roll] floating DAGs

Hi Mukul,

Mukul Goyal wrote:
> The quoted text (the last paragraph on page 11, rpl-00 draft) gives the
impression that the floating DAGs are transient in nature. But, some
applications may want to have floating DAGs of permanent nature, i.e.
permanent DAGs rooted at popular destination nodes that dont offer default
routes outside the LLN. Perhaps, the text quoted above needs to change.

Yes, you are right- and the scenario you describe is something that needs to
be
supported.  The next revision will re-work this text.  There is a need to
convey two orthogonal properties:
	1) Is the DAG root offering a default route?
	2) Is the DAG root permanent/transient?  (e.g. the DAG is
permanent/popular to
service an application objective or transient for DAG repair)?

Regards,

-Tim

---

From: Tim Winter <[email-masked]>
Date: Tue, 08 Sep 2009 10:36:26 -0400

Hi Don,

Thanks for the question, it does help to see where we can continue to clarify
the draft.

> permitted to restore communication to the DAG root through C.
So Node D becomes root of its own DAG (DAG-D), Node E and F follow.  Node D's
former parent, B, is removed as a DAG Parent and placed temporarily in the
`Held-Down' state to prevent flapping.  With respect to DAG-A, Node D is no
longer a member and no longer has an associated rank.

Now, since the link D--C is serviceable, Node D should be able to hear RA-DIO's
from Node C, advertising DAG-A.  (If the DAG Sequence number is supported, Node
D will ignore the RA-DIO from Node C if the sequence number for DAG-A has not
yet incremented).

Upon hearing the DAG-A RA-DIO Node D needs to determine- is it better to jump
to, or add, DAG-A or to remain exclusively in DAG-D?  The merits of DAG-A and
DAG-D need to be compared.  This is to some degree a matter of implementation
policy, and the configuration at Node D should inform the decision of RPL at
Node D.  For example,
	Does Node D seek to join a grounded DAG?  DAG-A is grounded, DAG-D is not ->
Join DAG-A.
	Does DAG-A offer any additional destination prefixes that Node D has been
configured to seek?  (The discovery/selection/provisioning of such prefixes is
outside the scope of RPL)  Join DAG-A to get to them.
	Does DAG-A offer a better solution (in terms of supported OCP) than DAG-D to
destinations desired by DAG-D (default route or other prefixes)?  Then join DAG-A.
	Does DAG-A have a better (lower) DAGPreference than DAG-D, all else being
equal?  Then join DAG-A.

Now, once Node D has made the decision to rejoin DAG-A based on its policy,
then the specific mechanism provided by RPL is start a DAG Hop timer associated
with DAG-A and Node C, of a duration proportional to 3 (the depth of the
candidate node C).  In this example Node D will not find any better alternative
attachment to DAG-A while the Node C DAG Hop timer is elapsing.  Once the DAG
Hop timer is expired than Node D places Node C as a current DAG Parent for
DAG-A, and DAG-A is rejoined.  Node E and F may follow.

> address this scenario (unless I am wrong and this is supported in the
One of the goals of the next revision is to present these procedures more clearly.

> outside of the home (through building materials).

Did this answer your question?

Regards,

-Tim

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 8 Sep 2009 08:00:01 -0700

Hi Tim,

Yes, this answers my question.  Only question is then working through some
of these scenarios to see how long this process may take.  For the smart
metering application there is not too much concern with support for control
signal timing but for related applications like home control or building
control there could be an issue.

Could the repair process you mentioned be described in more detail in a
revision to RPL?  I did not catch all of the details in the RPL draft you
mentioned below (and I did read it several times.......).

Don

-----Original Message-----
From: Tim Winter [mailto:[email-masked]] 
Sent: Tuesday, September 08, 2009 7:36 AM
To: [email-masked]
Cc: ROLL WG
Subject: Re: [Roll] floating DAGs

Hi Don,

Thanks for the question, it does help to see where we can continue to
clarify
the draft.

Don Sturek wrote:
>                                                             2\    .1 (not
a
> permitted to restore communication to the DAG root through C.
So Node D becomes root of its own DAG (DAG-D), Node E and F follow.  Node
D's
former parent, B, is removed as a DAG Parent and placed temporarily in the
`Held-Down' state to prevent flapping.  With respect to DAG-A, Node D is no
longer a member and no longer has an associated rank.

Now, since the link D--C is serviceable, Node D should be able to hear
RA-DIO's
from Node C, advertising DAG-A.  (If the DAG Sequence number is supported,
Node
D will ignore the RA-DIO from Node C if the sequence number for DAG-A has
not
yet incremented).

Upon hearing the DAG-A RA-DIO Node D needs to determine- is it better to
jump
to, or add, DAG-A or to remain exclusively in DAG-D?  The merits of DAG-A
and
DAG-D need to be compared.  This is to some degree a matter of
implementation
policy, and the configuration at Node D should inform the decision of RPL at
Node D.  For example,
	Does Node D seek to join a grounded DAG?  DAG-A is grounded, DAG-D
is not ->
Join DAG-A.
	Does DAG-A offer any additional destination prefixes that Node D has
been
configured to seek?  (The discovery/selection/provisioning of such prefixes
is
outside the scope of RPL)  Join DAG-A to get to them.
	Does DAG-A offer a better solution (in terms of supported OCP) than
DAG-D to
destinations desired by DAG-D (default route or other prefixes)?  Then join
DAG-A.
	Does DAG-A have a better (lower) DAGPreference than DAG-D, all else
being
equal?  Then join DAG-A.

Now, once Node D has made the decision to rejoin DAG-A based on its policy,
then the specific mechanism provided by RPL is start a DAG Hop timer
associated
with DAG-A and Node C, of a duration proportional to 3 (the depth of the
candidate node C).  In this example Node D will not find any better
alternative
attachment to DAG-A while the Node C DAG Hop timer is elapsing.  Once the
DAG
Hop timer is expired than Node D places Node C as a current DAG Parent for
DAG-A, and DAG-A is rejoined.  Node E and F may follow.

> address this scenario (unless I am wrong and this is supported in the
One of the goals of the next revision is to present these procedures more
clearly.

Regards,

-Tim