Subject: [6tsch] time parent selection based on EB priority

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Wed, 21 Aug 2013 11:49:41 -0700

Hi all,

I want to propose to add in the basic TSCH draft the fact that when a node
joins a network, it uses the EB join priority defined in the Slot and Link
IE (Section 5.2.4.13 15.4e std) to select its time parent. This priority is
0 for the PAN coordinator of the network. A node listening several EB
selects as a time parent the node with lowest EB Join Priority. In case of
receiving multiple EBs with the same Join priority then filters by other
metrics e.g RSSI of the link. (note that until a DIO is received nodes don
not know about the gradient).
A node when sends an EB uses the lowest EB Join priority it has heard and
adds 1 to it as its own Join priority.

Current draft section states that RSSI or another metric should be used to
select the initial time parent, this has the problem that loops cannot be
avoided until the first DIO is received. With the proposed approach the
problem is solved and does not introduce anything new, just used what 15.4e
provides to us.

what is your opinion?
thanks!
Xavi

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 Aug 2013 03:20:22 +0800

Hi Xavi,

It is a good idea to use Priority in EB as a factor to choose initial time
parent. But, I think there are several ways to use the Priority, and other
metrics like RSSI. For example,

(1) As you suggested, use Priority first, and then RSSI
(2) or use RSSI first, and then Priority
(3) or use a function of Priority and RSSI.

I'm not sure which is better. What do you think?

Qin

On Thu, Aug 22, 2013 at 2:49 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Wed, 21 Aug 2013 12:23:04 -0700

HI Qin,

as a basic setting we want the most basic approach. I guess that using (1)
first priority and then RSSi will avoid having loops. As you say all this
approaches would work but I bet for (1) to be the simplest.

cheers!
X

On Wed, Aug 21, 2013 at 12:20 PM, Qin Wang <[email-masked]> wrote:

>> I want to propose to add in the basic TSCH draft the fact that when a
>> node joins a network, it uses the EB join priority defined in the Slot and
>> Link IE (Section 5.2.4.13 15.4e std) to select its time parent. This
>> priority is 0 for the PAN coordinator of the network. A node listening
>> several EB selects as a time parent the node with lowest EB Join Priority.
>> In case of receiving multiple EBs with the same Join priority then filters
>> by other metrics e.g RSSI of the link. (note that until a DIO is received
>> nodes don not know about the gradient).
>> Current draft section states that RSSI or another metric should be used
>> to select the initial time parent, this has the problem that loops cannot
>> be avoided until the first DIO is received. With the proposed approach the

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 Aug 2013 04:15:05 +0800

Agree!

Qin

On Thu, Aug 22, 2013 at 3:23 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

>> It is a good idea to use Priority in EB as a factor to choose initial
>> time parent. But, I think there are several ways to use the Priority, and
>> other metrics like RSSI. For example,
>>
>>> A node when sends an EB uses the lowest EB Join priority it has heard
>>> and adds 1 to it as its own Join priority.
>>>
>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 21 Aug 2013 23:06:23 -0700

Qin, Xavi,

Excellent point. I believe that this is exactly what makes this 6TSCH work
so interesting: figuring out how consolidate the views between upper and
lower layers.

In my mind, the join priority as you describe looks very much like a
DAGrank. I believe there are, however, two potential questions we should
not forget:
- what if the joining mote does no get all of the EBs of its neighbor?
- what happens when the topology changes and a node moves up or down in the
DODAG?

I would suggest the following:
- once the node has fully joined, somehow tie the join priority to its RPL
DAGrank. We might have to play with the metric to make the join priority
look like a hop count, but I believe it is important the announced join
priority changes when the mote moves up/down in the topology.
- maybe consider the time source parent identified during the joining as
temporary until the final time source parent is discovered. How the final
one is discovered can through some command from the ME (see Qin's
attachement), or after receiving many DIOs.

Thomas

On Wed, Aug 21, 2013 at 1:15 PM, Qin Wang <[email-masked]> wrote:

>> as a basic setting we want the most basic approach. I guess that using
>> (1) first priority and then RSSi will avoid having loops. As you say all
>> this approaches would work but I bet for (1) to be the simplest.
>>
>> cheers!
>> X
>>
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2013 09:59:28 +0000

Dear all:

As you know, RPL may entail temporary loops, in particular if DAGMaxRankIncrease is not configured to 0.
If as we expect we use the RPL preferred parent tree for time sync, this will lead to time sync loops.
Two questions here:
1) how bad is the effect of such loop? I expect that the clocks  will derive rapidly, as if from the perspective of a node the crystal was real, real bad.
2) can we detect that effect and use it to detect a loop in the routing?

Please see inline:

sch] time parent selection based on EB priority

Qin, Xavi,

Excellent point. I believe that this is exactly what makes this 6TSCH work so interesting: figuring out how consolidate the views between upper and lower layers.

In my mind, the join priority as you describe looks very much like a DAGrank. I believe there are, however, two potential questions we should not forget:
- what if the joining mote does no get all of the EBs of its neighbor?
- what happens when the topology changes and a node moves up or down in the DODAG?

I would suggest the following:
- once the node has fully joined, somehow tie the join priority to its RPL DAGrank. We might have to play with the metric to make the join priority look like a hop count, but I believe it is important the announced join priority changes when the mote moves up/down in the topology.
- maybe consider the time source parent identified during the joining as temporary until the final time source parent is discovered. How the final one is discovered can through some command from the ME (see Qin's attachement), or after receiving many DIOs.

[Pascal] Yes, I read Xavi's proposal as a mechanism parallel to RPL to do like an hop-count-based OF0.
Q: Do we really need to build the time sync tree faster than the RPL graph?

If no, maybe me could use the priority as a boolean to mean that the node is already part of the RPL DAG and may be used as time source.
Initially only the root would be priority 0. All the others would be default 1.
>From there, all nodes that are one hop away from root with good RSSI can sync with the root, and listen to DIOs, and emit their own, and set their own priority to zero.
Children sync to whichever prio 0 neighbor as time source, listen to DIOs, select a parent, migrate to that parent as time source, and then can set their own priority to zero and send DIOs.
Would that fly?
Cheers,
Pascal

On Wed, Aug 21, 2013 at 1:15 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Agree!

Qin

On Thu, Aug 22, 2013 at 3:23 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
HI Qin,

as a basic setting we want the most basic approach. I guess that using (1) first priority and then RSSi will avoid having loops. As you say all this approaches would work but I bet for (1) to be the simplest.
cheers!
X

On Wed, Aug 21, 2013 at 12:20 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Xavi,

It is a good idea to use Priority in EB as a factor to choose initial time parent. But, I think there are several ways to use the Priority, and other metrics like RSSI. For example,

Qin

On Thu, Aug 22, 2013 at 2:49 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

I want to propose to add in the basic TSCH draft the fact that when a node joins a network, it uses the EB join priority defined in the Slot and Link IE (Section 5.2.4.13 15.4e std) to select its time parent. This priority is 0 for the PAN coordinator of the network. A node listening several EB selects as a time parent the node with lowest EB Join Priority. In case of receiving multiple EBs with the same Join priority then filters by other metrics e.g RSSI of the link. (note that until a DIO is received nodes don not know about the gradient).
A node when sends an EB uses the lowest EB Join priority it has heard and adds 1 to it as its own Join priority.

Current draft section states that RSSI or another metric should be used to select the initial time parent, this has the problem that loops cannot be avoided until the first DIO is received. With the proposed approach the problem is solved and does not introduce anything new, just used what 15.4e provides to us.
what is your opinion?
thanks!
Xavi

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Thu, 22 Aug 2013 06:33:56 -0700

Hi Pascal,

my comment inline:

[Pascal] Yes, I read Xavi’s proposal as a mechanism parallel to RPL to do
like an hop-count-based OF0.****

Q: Do we really need to build the time sync tree faster than the RPL graph?*
***

** **

If no, maybe me could use the priority as a boolean to mean that the node
is already part of the RPL DAG and may be used as time source.****

Initially only the root would be priority 0. All the others would be
default 1.****

>From there, all nodes that are one hop away from root with good RSSI can
sync with the root, and listen to DIOs, and emit their own, and set their
own priority to zero.****

Children sync to whichever prio 0 neighbor as time source, listen to DIOs,
select a parent, migrate to that parent as time source, and then can set
their own priority to zero and send DIOs.****

Would that fly?

yes that would work but we are doing the same as the IEEE802-15.4e Join
priority field is for. The 15.4e defines this mechanism and it is inherent
to the networks we address so using it is straightforward. Then as
described by Thomas, we only need to use RPL best parent as soon as we have
one instead of the lowest prio neighbor.

Another question with time sources is the selection of a time source parent
in the case that a node belongs to more than one DODAG. Which parent is
selected then? An more importantly, do the basic draft considers having
more than one DODAG?

thanks!
Xavi

On Thu, Aug 22, 2013 at 2:59 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Dear all:****
>
> ** **
>
> As you know, RPL may entail temporary loops, in particular if
> DAGMaxRankIncrease is not configured to 0.****
>
> If as we expect we use the RPL preferred parent tree for time sync, this
> will lead to time sync loops. ****
>
> Two questions here:****
>
> 1) how bad is the effect of such loop? I expect that the clocks  will
> derive rapidly, as if from the perspective of a node the crystal was real,
> real bad.****
>
> 2) can we detect that effect and use it to detect a loop in the routing?**
> **
>
> ** **
>
> Please see inline:****
>
> ** **
>
> sch] time parent selection based on EB priority****
>
> ** **
>
> Qin, Xavi,****
>
> ** **
>
> lower layers.****
> ** **
> not forget:****
> - what if the joining mote does no get all of the EBs of its neighbor?****
>
> - what happens when the topology changes and a node moves up or down in
> the DODAG?****
>
> ** **
>
> I would suggest the following:****
>
> priority changes when the mote moves up/down in the topology.****
>
> attachement), or after receiving many DIOs.****
>
> ** **
>
> [Pascal] Yes, I read Xavi’s proposal as a mechanism parallel to RPL to do
> like an hop-count-based OF0. ****
>
> Q: Do we really need to build the time sync tree faster than the RPL
> graph? ****
>
> ** **
>
> If no, maybe me could use the priority as a boolean to mean that the node
> is already part of the RPL DAG and may be used as time source.****
>
> Initially only the root would be priority 0. All the others would be
> default 1.****
>
> From there, all nodes that are one hop away from root with good RSSI can
> sync with the root, and listen to DIOs, and emit their own, and set their
> own priority to zero.****
>
> Children sync to whichever prio 0 neighbor as time source, listen to DIOs,
> select a parent, migrate to that parent as time source, and then can set
> their own priority to zero and send DIOs.****
>
> Would that fly?****
>
> Cheers,****
>
> Pascal****
>
> ** **
>
> On Wed, Aug 21, 2013 at 1:15 PM, Qin Wang <[email-masked]> wrote:***
> *
>
> Agree!****
>
> ** **
>
> Qin****
>
> ** **
>
> [email-masked]> wrote:****
>
> HI Qin,
>
> approaches would work but I bet for (1) to be the simplest. ****
>
> cheers!
> X****
>
> ** **
>
> On Wed, Aug 21, 2013 at 12:20 PM, Qin Wang <[email-masked]> wrote:**
> **
>
> Hi Xavi,****
>
> ** **
>
> metrics like RSSI. For example,****
>
> ** **
>
> (1) As you suggested, use Priority first, and then RSSI****
>
> (2) or use RSSI first, and then Priority****
>
> (3) or use a function of Priority and RSSI.****
>
> ** **
>
> I'm not sure which is better. What do you think?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
>    Hi all,
>
> not know about the gradient).****
>
> provides to us.****
> what is your opinion?****
>
> thanks!
> Xavi****
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
> ** **
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 Aug 2013 22:56:58 +0800

Hi All,

I think we likely mix the concepts in the two layers, i.e. 15.4e TSCH and
RPL. The Join Priority is existing in a TSCH network and maintained by
TSCH, no matter RPL is used as upper layer or not. Thus, IMHO, 6top and
upper layer can use the Join Priority, but cannot modify it.

In addition, selecting time source parent is for synchronizing to existing
network and communicating with neighbors in correct time template, which
should happen before a DODAG is established. Thus, I agree with Xavi that
it is necessary to select a time source parent, or called it as temporary
time source parent, before a DODAG is established.

What do you think?

Qin

On Thu, Aug 22, 2013 at 9:33 PM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

> ****
> Another question with time sources is the selection of a time source
> parent in the case that a node belongs to more than one DODAG. Which parent
> is selected then? An more importantly, do the basic draft considers having
> more than one DODAG?
>
> thanks!
> Xavi
>
>
>> 2) can we detect that effect and use it to detect a loop in the routing?*
>> ***
>>
>> ** **
>>
>> Please see inline:****
>>
>> ** **
>>
>> Excellent point. I believe that this is exactly what makes this 6TSCH
>> work so interesting: figuring out how consolidate the views between upper
>> and lower layers.****
>>
>> ** **
>>
>> - once the node has fully joined, somehow tie the join priority to its
>> RPL DAGrank. We might have to play with the metric to make the join
>> priority look like a hop count, but I believe it is important the announced
>> join priority changes when the mote moves up/down in the topology.****
>>
>> Children sync to whichever prio 0 neighbor as time source, listen to
>> DIOs, select a parent, migrate to that parent as time source, and then can
>> set their own priority to zero and send DIOs.****
>>
>> Would that fly?****
>>
>> Cheers,****
>>
>> Pascal****
>>
>> ** **
>>
>> On Wed, Aug 21, 2013 at 1:15 PM, Qin Wang <[email-masked]> wrote:**
>> **
>>
>> Agree!****
>>
>> ** **
>>
>> Qin****
>>
>> ** **
>>
>> this approaches would work but I bet for (1) to be the simplest. ****
>>
>> cheers!
>> X****
>>
>> ** **
>>
>> On Wed, Aug 21, 2013 at 12:20 PM, Qin Wang <[email-masked]> wrote:*
>> ***
>>
>> Hi Xavi,****
>>
>> ** **
>>
>> other metrics like RSSI. For example,****
>>
>> ** **
>>
>> nodes don not know about the gradient).****
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2013 15:11:44 +0000

Hello Xavi:

The problem is that we have 2 mechanisms that establish a distance to the root in order to avoid loops, RPL Rank and 4e priority.
Fact is, RPL is probably more elaborate for loop detection and loop avoidance. I suspect that the priority can easily count to infinity.
So I'd trust RPL Rank rather than priority, and we seem to agree that we want to time sync with RPL parents.

a) My question is whether it makes sense and value to have a transition between a time source based on best (hop count) priority and to one based on best RPL Rank, or if we could use the rank right away. Seems to me that life would be easier if we use the Rank right away, though it may make the network a bit slower to come up. Passing from one mode to the other will demand some specifications, what if one node reboots and goes from one mode to the other, etc...

Now if the question is to reuse the priority field, then we can do actually change the logic to accommodate priority = DAGRank(Rank) for nodes that are not root, still ensuring that only a node that is already part of a RPL DAG may be used as time source.
Initially only the root would be priority 0. All the others would be default 255 (that is DAGRank(INFINITE_RANK) assuming MinHopRankIncrease of 255)
>From there, all nodes that are one hop away from root with good RSSI can sync with the root, and listen to DIOs, and emit their own, and set their own priority to DAGRank(Rank) that is < 255.
Children sync to whichever prio < 255 neighbor as time source, listen to DIOs, select a parent, migrate to that parent as time source, and then can set their own priority to zero and send DIOs. If later they select a better parent the priority will get lower so that's till OK.
Would that fly?
b) about multiple DAGs, there are 2 cases:
- 2 DODAGs in a same instance. We said we want to support that, and that implies that the various DODAGs are closely time sync'd.
- 2 DODAGs in 2 different instances. To be discussed. We have use cases where that could be useful, one instance playing basic slotted aloha and the other doing more critical jobs.

We have not agreed on the latter but with a single radio, it seems problematic if the 2 instances do not share a same sense of time. We'd end up with slot frames that may drift from one another, sometimes overlapping... I suspect that we'd partition time inside a slot frame or using multiple slot frames, but we'd keep them in sync. Probably there is a need for a spanning instance (0) for (autonomic) management etc... that uses something very simple, always on, very much like your basic draft. If there is such a spanning instance, then it can be used to sync everyone, in which casethe Rank from the dependent instances is not used for time sync.
What do others think?

Pascal

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: jeudi 22 août 2013 15:34
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] time parent selection based on EB priority

Hi Pascal,

my comment inline:

Children sync to whichever prio 0 neighbor as time source, listen to DIOs, select a parent, migrate to that parent as time source, and then can set their own priority to zero and send DIOs.
Would that fly?
yes that would work but we are doing the same as the IEEE802-15.4e Join priority field is for. The 15.4e defines this mechanism and it is inherent to the networks we address so using it is straightforward. Then as described by Thomas, we only need to use RPL best parent as soon as we have one instead of the lowest prio neighbor.
Another question with time sources is the selection of a time source parent in the case that a node belongs to more than one DODAG. Which parent is selected then? An more importantly, do the basic draft considers having more than one DODAG?
thanks!
Xavi

On Thu, Aug 22, 2013 at 2:59 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all:

Please see inline:

Qin, Xavi,

Qin

Qin

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Thu, 22 Aug 2013 15:26:31 +0000

Hi All,
Wont allowing RPL tree to influence L2 timing parent may create race conditions?

For example,
If the parent node switches off, the L2 may lose time sync (this will happen with a bad crystal in low traffic scenarios) very soon. The entire subtree may not be able to connect with other nodes at L2 and hence L3 may never be able to converge.

I know we discussed the advantages of using the L3 parent as the timing parent previously. But I think such race conditions will be an unnecessary artifact and probably a more serious problem.

Given this, I think timing parent selection should be completely owned by L2 using its own parameters. Anyway, timing parent is in no way required to be known by L3 nor does it affect routing.

-raghuram

From: Qin Wang <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 22, 2013 7:56 AM
To: Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>>
Cc: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tsch] time parent selection based on EB priority

Hi All,

I think we likely mix the concepts in the two layers, i.e. 15.4e TSCH and RPL. The Join Priority is existing in a TSCH network and maintained by TSCH, no matter RPL is used as upper layer or not. Thus, IMHO, 6top and upper layer can use the Join Priority, but cannot modify it.

In addition, selecting time source parent is for synchronizing to existing network and communicating with neighbors in correct time template, which should happen before a DODAG is established. Thus, I agree with Xavi that it is necessary to select a time source parent, or called it as temporary time source parent, before a DODAG is established.

What do you think?

Qin

On Thu, Aug 22, 2013 at 9:33 PM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal,

my comment inline:

[Pascal] Yes, I read Xavi’s proposal as a mechanism parallel to RPL to do like an hop-count-based OF0.

Would that fly?

thanks!
Xavi

Please see inline:

Qin, Xavi,

[Pascal] Yes, I read Xavi’s proposal as a mechanism parallel to RPL to do like an hop-count-based OF0.
Q: Do we really need to build the time sync tree faster than the RPL graph?

Qin

Qin

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2013 15:27:39 +0000

Hello Qin:

Do you think you need to sync the whole network before RPL DIO/parent selection happens or should we make it so that we sync only with nodes that are already in the DODAG?

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: jeudi 22 août 2013 16:57
To: Xavier Vilajosana Guillen
Cc: Pascal Thubert (pthubert); Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] time parent selection based on EB priority

Hi All,

What do you think?

Qin

my comment inline:

Would that fly?

thanks!
Xavi

Please see inline:

Qin, Xavi,

Qin

Qin

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 Aug 2013 23:41:47 +0800

Hi Pascal,

I think that selecting a temporary time source parent is for establishing a
basic communication channel, on which DIOs can be received. Thus, a joining
node only needs to sync with the nodes already in the DODAG.

Make sense?

Qin

On Thu, Aug 22, 2013 at 11:27 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Qin:****
>
> ** **
>
> Do you think you need to sync the whole network before RPL DIO/parent
> selection happens or should we make it so that we sync only with nodes that
> are already in the DODAG?****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* jeudi 22 août 2013 16:57
> *To:* Xavier Vilajosana Guillen
> *Cc:* Pascal Thubert (pthubert); Thomas Watteyne; [email-masked]
> *Subject:* Re: [6tsch] time parent selection based on EB priority****
>
> ** **
>
> Hi All,****
>
> ** **
>
> upper layer can use the Join Priority, but cannot modify it. ****
>
> ** **
>
> time source parent, before a DODAG is established.****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> Hi Pascal,****
> my comment inline:****
> one instead of the lowest prio neighbor. ****
>
> more than one DODAG? ****
>
> thanks!
> Xavi****
>
> ** **
>
> [email-masked]> wrote:****
>
> Dear all:****
>
>  ****
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 22 Aug 2013 23:53:37 +0800

Hi Pascal,

Is it assumed that 2 DODAG in a same instance must have at least one shared
node?

Thanks
Qin

On Thu, Aug 22, 2013 at 11:11 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Xavi:****
>
> ** **
>
> The problem is that we have 2 mechanisms that establish a distance to the
> root in order to avoid loops, RPL Rank and 4e priority.****
>
> Fact is, RPL is probably more elaborate for loop detection and loop
> avoidance. I suspect that the priority can easily count to infinity.****
>
> So I’d trust RPL Rank rather than priority, and we seem to agree that we
> want to time sync with RPL parents.****
>
> ** **
>
> a) My question is whether it makes sense and value to have a transition
> between a time source based on best (hop count) priority and to one based
> on best RPL Rank, or if we could use the rank right away. Seems to me that
> life would be easier if we use the Rank right away, though it may make the
> network a bit slower to come up. Passing from one mode to the other will
> demand some specifications, what if one node reboots and goes from one mode
> to the other, etc…****
>
> ** **
>
> Now if the question is to reuse the priority field, then we can do
> actually change the logic to accommodate priority = DAGRank(Rank) for
> nodes that are not root, still ensuring that only a node that is already
> part of a RPL DAG may be used as time source.****
>
> default 255 (that is DAGRank(INFINITE_RANK) assuming MinHopRankIncrease of
> 255)****
>
> own priority to DAGRank(Rank) that is < 255.****
>
> Children sync to whichever prio < 255 neighbor as time source, listen to
> set their own priority to zero and send DIOs. If later they select a better
> parent the priority will get lower so that’s till OK.****
>
> Would that fly?****
>
> b) about multiple DAGs, there are 2 cases:****
>
> - 2 DODAGs in a same instance. We said we want to support that, and that
> implies that the various DODAGs are closely time sync’d.****
>
> - 2 DODAGs in 2 different instances. To be discussed. We have use cases
> where that could be useful, one instance playing basic slotted aloha and
> the other doing more critical jobs. ****
>
> ** **
>
> We have not agreed on the latter but with a single radio, it seems
> problematic if the 2 instances do not share a same sense of time. We’d end
> up with slot frames that may drift from one another, sometimes overlapping…
> I suspect that we’d partition time inside a slot frame or using multiple
> slot frames, but we’d keep them in sync. Probably there is a need for a
> spanning instance (0) for (autonomic) management etc… that uses something
> very simple, always on, very much like your basic draft. If there is such a
> spanning instance, then it can be used to sync everyone, in which casethe
> Rank from the dependent instances is not used for time sync.****
>
> ****
>
> What do others think?****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* Xavier Vilajosana Guillen [mailto:[email-masked]]
> *Sent:* jeudi 22 août 2013 15:34
> *To:* Pascal Thubert (pthubert)
> *Cc:* Thomas Watteyne; [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2013 16:15:53 +0000

I do not think so, Qin;

but it is required that a node on one DODAG may jump onto the other, and to do that, it is useful to monitoring candidates from both dodags.
Note that DODAGs partition the network, and all the parents must be in one of them.

Cheers;

Pascal

From: Qin Wang [mailto:[email-masked]]
Sent: jeudi 22 août 2013 17:54
To: Pascal Thubert (pthubert)
Cc: [email-masked]; Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] time parent selection based on EB priority

Hi Pascal,

Is it assumed that 2 DODAG in a same instance must have at least one shared node?

Thanks
Qin

On Thu, Aug 22, 2013 at 11:11 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Xavi:

Pascal

From: Xavier Vilajosana Guillen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: jeudi 22 août 2013 15:34
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] time parent selection based on EB priority

Hi Pascal,

my comment inline:

Please see inline:

Qin, Xavi,

Qin

Qin

---

From: Qin Wang <[email-masked]>
Date: Fri, 23 Aug 2013 01:03:20 +0800

Pascal,

It may bring in some complexity. Think about the case. DODAG1 and DODAG2
are in a same instance, but have no shared nodes, thus may not be able sync
with each other.  A new node (node-A) comes in, wants to join into the two
DODAGs, in another word, want to jump between the two DODAGs.  I believe
node-A has to change its time source parent and re-sync when it jump from
one DODAG to another. Right?

Thank
Qin

On Fri, Aug 23, 2013 at 12:15 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  I do not think so, Qin; ****
>
> ** **
>
> but it is required that a node on one DODAG may jump onto the other, and
> to do that, it is useful to monitoring candidates from both dodags.****
>
> Note that DODAGs partition the network, and all the parents must be in one
> of them.****
>
> ** **
>
> Cheers;****
>
> ** **
>
> Pascal****
>
> ** **
>
> *Sent:* jeudi 22 août 2013 17:54
> *Cc:* [email-masked]; Thomas Watteyne; [email-masked]
>
> Is it assumed that 2 DODAG in a same instance must have at least one
> shared node?****
>
> ** **
>
> Thanks****
>
> Qin****
>
> ** **
>
> actually change the logic to accommodate priority = DAGRank(Rank) for nodes
> that are not root, still ensuring that only a node that is already part of
> a RPL DAG may be used as time source.****
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Aug 2013 19:00:09 +0000

Dear Qin:

I think the idea was to make sure that the roots are synchronized.
Certainly the DODAGs may be a bit out of sync as we progress down, but we expect that the guard time is sufficient.
The alternate would be to sync the whole network completely independent of RPL DAGs etc... eg using a GPS.
There might be use cases where that is fine, but we need to document a default behavior that does not make the assumption of a GPS or similar.

Makes sense?

Cheers,

Pascal

Sent: jeudi 22 août 2013 19:03

Pascal,

It may bring in some complexity. Think about the case. DODAG1 and DODAG2 are in a same instance, but have no shared nodes, thus may not be able sync with each other.  A new node (node-A) comes in, wants to join into the two DODAGs, in another word, want to jump between the two DODAGs.  I believe node-A has to change its time source parent and re-sync when it jump from one DODAG to another. Right?

Thank
Qin

On Fri, Aug 23, 2013 at 12:15 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
I do not think so, Qin;

Cheers;

Pascal

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: jeudi 22 août 2013 17:54
To: Pascal Thubert (pthubert)
Cc: [email-masked]<mailto:[email-masked]>; Thomas Watteyne; [email-masked]<mailto:[email-masked]>

Hi Pascal,

Thanks
Qin

Pascal

Hi Pascal,

my comment inline:

Please see inline:

Qin, Xavi,

Qin

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 22 Aug 2013 16:10:45 -0700

All,

Summarizing the different things we are talking about in this thread:
1. picking time source neighbors during the operation of the network.
Proposal is to use the (loop-free) RPL DAG. Challenged by Raghuram who
wants to have separate L2 and L3 behavior because of race conditions.
2. picking time source neighbors during join process. Proposal is to attach
to the node which indicates the lowest join priority in EB. Question is
whether join priority reflects DAGrank or not.
3. multiple DODAGs: keeping DAGroots sync'ed or participating in several
independent time bases.

My opinion is:
1. I believe keeping the same DAG structure the same between L2 and L3
makes sense. If there is no L2 connectivity, L3 cannot function since it
can not speak to and hear the neighbors, so I'm afraid I don't quite follow
the race condition issue.
2. My inclination is to have the join priority be an indication of the
DAGrank, possible by "rounding off". When joining, a new node will join L2
(i.e. synchronize) as soon as it hears EBs, then join L3 (i.e, acquire a
DAGrank) after hearing DIOs. I would have the node transmit EBs only after
that last step.
3. My opinion is that, for now, we should take the multiple root case into
account, but only if they are synchronized through some out-of-band
mechanism.

Raw opinions, up for discussion :)

Thomas

On Thu, Aug 22, 2013 at 12:00 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Dear Qin:****
>
> ** **
>
> I think the idea was to make sure that the roots are synchronized.****
>
> Certainly the DODAGs may be a bit out of sync as we progress down, but we
> expect that the guard time is sufficient.****
>
> The alternate would be to sync the whole network completely independent of
> RPL DAGs etc… eg using a GPS.****
>
> There might be use cases where that is fine, but we need to document a
> default behavior that does not make the assumption of a GPS or similar.***
> *
>
> ** **
>
> Makes sense?****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *Sent:* jeudi 22 août 2013 19:03
>
> Pascal,****
> one DODAG to another. Right?****
>
> ** **
>
> Thank****
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> *Cc:* [email-masked]; Thomas Watteyne; [email-masked]****
>
>

---

From: Kris Pister <[email-masked]>
Date: Thu, 22 Aug 2013 16:22:37 -0700

It is not unlikely that some motes in a network will have an accurate 
time source,
such as GPS.  It would be a shame to ignore the time information from a 
1-hop neighbor
with GPS just because it happened to be a child in the DODAG.

ksjp

On 8/22/2013 4:10 PM, Thomas Watteyne wrote:
> 2. picking time source neighbors during join process. Proposal is to 
> attach to the node which indicates the lowest join priority in EB. 
> Question is whether join priority reflects DAGrank or not.
> 3. multiple DODAGs: keeping DAGroots sync'ed or participating in 
> several independent time bases.
>
> My opinion is:
> makes sense. If there is no L2 connectivity, L3 cannot function since 
> it can not speak to and hear the neighbors, so I'm afraid I don't 
> quite follow the race condition issue.
> DAGrank, possible by "rounding off". When joining, a new node will 
> join L2 (i.e. synchronize) as soon as it hears EBs, then join L3 (i.e, 
> acquire a DAGrank) after hearing DIOs. I would have the node transmit 
> EBs only after that last step.
> 3. My opinion is that, for now, we should take the multiple root case 
> into account, but only if they are synchronized through some 
> out-of-band mechanism.
>
> On Thu, Aug 22, 2013 at 12:00 PM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear Qin:
>
>     Certainly the DODAGs may be a bit out of sync as we progress down,
>     but we expect that the guard time is sufficient.
>
>     The alternate would be to sync the whole network completely
>     independent of RPL DAGs etc... eg using a GPS.
>
>     There might be use cases where that is fine, but we need to
>     document a default behavior that does not make the assumption of a
>     GPS or similar.
>
>     Makes sense?
>
>     Cheers,
>
>     Pascal
>
>     *From:*Qin Wang [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>; Thomas Watteyne;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [6tsch] time parent selection based on EB priority
>
>     Pascal,
>
>     It may bring in some complexity. Think about the case. DODAG1 and
>     DODAG2 are in a same instance, but have no shared nodes, thus may
>     not be able sync with each other.  A new node (node-A) comes in,
>     wants to join into the two DODAGs, in another word, want to jump
>     between the two DODAGs.  I believe node-A has to change its time
>     source parent and re-sync when it jump from one DODAG to another.
>     Right?
>
>     Thank
>
>     Qin
>
>     On Fri, Aug 23, 2013 at 12:15 AM, Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I do not think so, Qin;
>
>     but it is required that a node on one DODAG may jump onto the
>     other, and to do that, it is useful to monitoring candidates from
>     both dodags.
>
>     *From:*Qin Wang [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>; Thomas Watteyne;
>     [email-masked] <mailto:[email-masked]>
>
>
>     *Subject:* Re: [6tsch] time parent selection based on EB priority
>
>     Hi Pascal,
>
>     On Thu, Aug 22, 2013 at 11:11 PM, Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Xavi:
>
>     The problem is that we have 2 mechanisms that establish a distance
>     to the root in order to avoid loops, RPL Rank and 4e priority.
>
>     Fact is, RPL is probably more elaborate for loop detection and
>     loop avoidance. I suspect that the priority can easily count to
>     infinity.
>
>     So I'd trust RPL Rank rather than priority, and we seem to agree
>     that we want to time sync with RPL parents.
>
>     a) My question is whether it makes sense and value to have a
>     transition between a time source based on best (hop count)
>     priority and to one based on best RPL Rank, or if we could use the
>     rank right away. Seems to me that life would be easier if we use
>     the Rank right away, though it may make the network a bit slower
>     to come up. Passing from one mode to the other will demand some
>     specifications, what if one node reboots and goes from one mode to
>     the other, etc...
>
>     actually change the logic to accommodate priority = DAGRank(Rank)
>     for nodes that are not root, still ensuring that only a node that
>     is already part of a RPL DAG may be used as time source.
>
>     Initially only the root would be priority 0. All the others would
>     be default 255 (that is DAGRank(INFINITE_RANK) assuming
>     MinHopRankIncrease of 255)
>
>     From there, all nodes that are one hop away from root with good
>     RSSI can sync with the root, and listen to DIOs, and emit their
>     own, and set their own priority to DAGRank(Rank) that is < 255.
>
>     Children sync to whichever prio < 255 neighbor as time source,
>     listen to DIOs, select a parent, migrate to that parent as time
>     source, and then can set their own priority to zero and send DIOs.
>     If later they select a better parent the priority will get lower
>     so that's till OK.
>
>     Would that fly?
>
>     - 2 DODAGs in a same instance. We said we want to support that,
>     and that implies that the various DODAGs are closely time sync'd.
>
>     - 2 DODAGs in 2 different instances. To be discussed. We have use
>     cases where that could be useful, one instance playing basic
>     slotted aloha and the other doing more critical jobs.
>
>     problematic if the 2 instances do not share a same sense of time.
>     We'd end up with slot frames that may drift from one another,
>     sometimes overlapping... I suspect that we'd partition time inside
>     a slot frame or using multiple slot frames, but we'd keep them in
>     sync. Probably there is a need for a spanning instance (0) for
>     (autonomic) management etc... that uses something very simple,
>     always on, very much like your basic draft. If there is such a
>     spanning instance, then it can be used to sync everyone, in which
>     casethe Rank from the dependent instances is not used for time sync.
>
>     What do others think?
>
>     Pascal
>
>     *From:*Xavier Vilajosana Guillen
>     [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Thomas Watteyne; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [6tsch] time parent selection based on EB priority
>
>     Hi Pascal,
>
>     my comment inline:
>
>     If no, maybe me could use the priority as a boolean to mean that
>     the node is already part of the RPL DAG and may be used as time
>     source.
>
>     From there, all nodes that are one hop away from root with good
>     RSSI can sync with the root, and listen to DIOs, and emit their
>     own, and set their own priority to zero.
>
>     Children sync to whichever prio 0 neighbor as time source, listen
>     to DIOs, select a parent, migrate to that parent as time source,
>     and then can set their own priority to zero and send DIOs.
>
>     Would that fly?
>
>     yes that would work but we are doing the same as the IEEE802-15.4e
>     Join priority field is for. The 15.4e defines this mechanism and
>     it is inherent to the networks we address so using it is
>     straightforward. Then as described by Thomas, we only need to use
>     RPL best parent as soon as we have one instead of the lowest prio
>     neighbor.
>
>     Another question with time sources is the selection of a time
>     source parent in the case that a node belongs to more than one
>     DODAG. Which parent is selected then? An more importantly, do the
>     basic draft considers having more than one DODAG?
>
>     thanks!
>     Xavi
>
>     On Thu, Aug 22, 2013 at 2:59 AM, Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Dear all:
>
>     DAGMaxRankIncrease is not configured to 0.
>
>     1) how bad is the effect of such loop? I expect that the clocks 
>     will derive rapidly, as if from the perspective of a node the
>     crystal was real, real bad.
>
>     Excellent point. I believe that this is exactly what makes this
>     6TSCH work so interesting: figuring out how consolidate the views
>     between upper and lower layers.
>
>     In my mind, the join priority as you describe looks very much like
>     a DAGrank. I believe there are, however, two potential questions
>     we should not forget:
>
>     - once the node has fully joined, somehow tie the join priority to
>     its RPL DAGrank. We might have to play with the metric to make the
>     join priority look like a hop count, but I believe it is important
>     the announced join priority changes when the mote moves up/down in
>     the topology.
>
>     - maybe consider the time source parent identified during the
>     joining as temporary until the final time source parent is
>     discovered. How the final one is discovered can through some
>     command from the ME (see Qin's attachement), or after receiving
>     many DIOs.
>
>     If no, maybe me could use the priority as a boolean to mean that
>     the node is already part of the RPL DAG and may be used as time
>     source.
>
>     From there, all nodes that are one hop away from root with good
>     RSSI can sync with the root, and listen to DIOs, and emit their
>     own, and set their own priority to zero.
>
>     Children sync to whichever prio 0 neighbor as time source, listen
>     to DIOs, select a parent, migrate to that parent as time source,
>     and then can set their own priority to zero and send DIOs.
>
>     Would that fly?
>
>     Cheers,
>
>     Pascal
>
>     On Thu, Aug 22, 2013 at 3:23 AM, Xavier Vilajosana Guillen
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>     HI Qin,
>
>     as a basic setting we want the most basic approach. I guess that
>     using (1) first priority and then RSSi will avoid having loops. As
>     you say all this approaches would work but I bet for (1) to be the
>     simplest.
>
>     cheers!
>     X
>
>     It is a good idea to use Priority in EB as a factor to choose
>     initial time parent. But, I think there are several ways to use
>     the Priority, and other metrics like RSSI. For example,
>
>     On Thu, Aug 22, 2013 at 2:49 AM, Xavier Vilajosana Guillen
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi all,
>
>         I want to propose to add in the basic TSCH draft the fact that
>         when a node joins a network, it uses the EB join priority
>         defined in the Slot and Link IE (Section 5.2.4.13 15.4e std)
>         to select its time parent. This priority is 0 for the PAN
>         coordinator of the network. A node listening several EB
>         selects as a time parent the node with lowest EB Join
>         Priority. In case of receiving multiple EBs with the same Join
>         priority then filters by other metrics e.g RSSI of the link.
>         (note that until a DIO is received nodes don not know about
>         the gradient).
>
>         A node when sends an EB uses the lowest EB Join priority it
>         has heard and adds 1 to it as its own Join priority.
>
>
>         Current draft section states that RSSI or another metric
>         should be used to select the initial time parent, this has the
>         problem that loops cannot be avoided until the first DIO is
>         received. With the proposed approach the problem is solved and
>         does not introduce anything new, just used what 15.4e provides
>         to us.
>
>         what is your opinion?
>
>         thanks!
>         Xavi
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 23 Aug 2013 09:11:02 +0000

Thomas, see my comments inline.
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, August 23, 2013 1:11 AM
To: [email-masked]
Subject: Re: [6tsch] time parent selection based on EB priority

All,

Summarizing the different things we are talking about in this thread:
1. picking time source neighbors during the operation of the network. Proposal is to use the (loop-free) RPL DAG. Challenged by Raghuram who wants to have separate L2 and L3 behavior because of race conditions.
2. picking time source neighbors during join process. Proposal is to attach to the node which indicates the lowest join priority in EB. Question is whether join priority reflects DAGrank or not.
3. multiple DODAGs: keeping DAGroots sync'ed or participating in several independent time bases.

My opinion is:

1. I believe keeping the same DAG structure the same between L2 and L3 makes sense. If there is no L2 connectivity, L3 cannot function since it can not speak to and hear the neighbors, so I'm afraid I don't quite follow the race condition issue.

2. My inclination is to have the join priority be an indication of the DAGrank, possible by "rounding off". When joining, a new node will join L2 (i.e. synchronize) as soon as it hears EBs, then join L3 (i.e, acquire a DAGrank) after hearing DIOs. I would have the node transmit EBs only after that last step.

[MR] I agree. If we want to use RPL topology information, and RPL parents as selected synch parents,  it makes sense to link the join priority with the DAGrank.

3. My opinion is that, for now, we should take the multiple root case into account, but only if they are synchronized through some out-of-band mechanism.

[MR] I am afraid that multiple DODAGs may imply more complexity, and we are looking for the basic simplest scenario. Thus, as you pointed out, if we want to consider multiple roots, we will have to assume, at least for now, that they are synchronized.

Thomas

On Thu, Aug 22, 2013 at 12:00 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Qin:

Makes sense?

Cheers,

Pascal

Pascal,

Thank
Qin

Cheers;

Pascal

Hi Pascal,

Thanks
Qin

Pascal

Hi Pascal,

my comment inline:

Please see inline:

Qin, Xavi,

Qin

Qin

---

From: Qin Wang <[email-masked]>
Date: Fri, 23 Aug 2013 21:59:33 +0800

Hi Thomas and all,

Regarding to multiple DODAG case, I believe even we assume the roots are
synchronized, it can not be guaranteed that any two nodes in different
DODAG are synchronized while the nodes are many hops from their roots.
Correct?

Can we address the issue in this way: when nodeA is jumping from DODAG1 to
DODAG2, the action of re-synchronizing to the preferred parent in DODAG2 is
triggered. Make sense?

Thanks
Qin

On Fri, Aug 23, 2013 at 5:11 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Thomas, see my comments inline.****
>
> Maria Rita****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Friday, August 23, 2013 1:11 AM
> *To:* [email-masked]
>
> All,****
> Summarizing the different things we are talking about in this thread:****
>
> wants to have separate L2 and L3 behavior because of race conditions.****
>
> attach to the node which indicates the lowest join priority in EB. Question
> is whether join priority reflects DAGrank or not.****
>
> independent time bases.****
>
> ** **
>
> My opinion is:****
>
> ** **
>
> the race condition issue.****
>
> ** **
>
> ** **
>
> that last step.****
> [MR] I agree. If we want to use RPL topology information, and RPL parents
> as selected synch parents,  it makes sense to link the join priority with
> the DAGrank.****
>
> ** **
>
> mechanism.****
> [MR] I am afraid that multiple DODAGs may imply more complexity, and we
> are looking for the basic simplest scenario. Thus, as you pointed out, if
> we want to consider multiple roots, we will have to assume, at least for
> now, that they are synchronized.****
>
> ** **
>
> Raw opinions, up for discussion :)****
>
> ** **
>
> Thomas****
>
> ** **
>
> *Sent:* jeudi 22 août 2013 19:03****
>
>

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Fri, 23 Aug 2013 14:46:56 +0000

Please see inline

From: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 22, 2013 4:10 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tsch] time parent selection based on EB priority

All,

My opinion is:
1. I believe keeping the same DAG structure the same between L2 and L3 makes sense. If there is no L2 connectivity, L3 cannot function since it can not speak to and hear the neighbors, so I'm afraid I don't quite follow the race condition issue.
 I support the idea of keeping the same DAG structure between L2 and L3.

To explain what I was referring to -
The RPL trickle timer period can very easily become a large value if the network is static. In this time if a node does switch off, it is most like that L2 will detect it first since it would have received EB from its current parent. Now if we force it that the RPL parent has to be the timing parent we cannot find a timing parent until L3 detects the topology change. If we allow L2 to initiate a join process and choose a new timing parent and inform L3 we may be violating the RPL OF. This is the situation that I was referring to. I feel that there is a fair probability of this happening. Thoughts ?

To address this we probably need to allow RPL to change the topology based on the OF, after L2 join has occurred. Then L2 can change its timing parent to be synced with DAG structure.

Thomas

I think the idea was to make sure that the roots are synchronized.
Certainly the DODAGs may be a bit out of sync as we progress down, but we expect that the guard time is sufficient.
The alternate would be to sync the whole network completely independent of RPL DAGs etc… eg using a GPS.
There might be use cases where that is fine, but we need to document a default behavior that does not make the assumption of a GPS or similar.

Makes sense?

Cheers,

Pascal

Pascal,

Thank
Qin

Cheers;

Pascal

Hi Pascal,

Thanks
Qin

The problem is that we have 2 mechanisms that establish a distance to the root in order to avoid loops, RPL Rank and 4e priority.
Fact is, RPL is probably more elaborate for loop detection and loop avoidance. I suspect that the priority can easily count to infinity.
So I’d trust RPL Rank rather than priority, and we seem to agree that we want to time sync with RPL parents.

a) My question is whether it makes sense and value to have a transition between a time source based on best (hop count) priority and to one based on best RPL Rank, or if we could use the rank right away. Seems to me that life would be easier if we use the Rank right away, though it may make the network a bit slower to come up. Passing from one mode to the other will demand some specifications, what if one node reboots and goes from one mode to the other, etc…

>From there, all nodes that are one hop away from root with good RSSI can sync with the root, and listen to DIOs, and emit their own, and set their own priority to DAGRank(Rank) that is < 255.
Children sync to whichever prio < 255 neighbor as time source, listen to DIOs, select a parent, migrate to that parent as time source, and then can set their own priority to zero and send DIOs. If later they select a better parent the priority will get lower so that’s till OK.
Would that fly?
b) about multiple DAGs, there are 2 cases:
- 2 DODAGs in a same instance. We said we want to support that, and that implies that the various DODAGs are closely time sync’d.
- 2 DODAGs in 2 different instances. To be discussed. We have use cases where that could be useful, one instance playing basic slotted aloha and the other doing more critical jobs.

We have not agreed on the latter but with a single radio, it seems problematic if the 2 instances do not share a same sense of time. We’d end up with slot frames that may drift from one another, sometimes overlapping… I suspect that we’d partition time inside a slot frame or using multiple slot frames, but we’d keep them in sync. Probably there is a need for a spanning instance (0) for (autonomic) management etc… that uses something very simple, always on, very much like your basic draft. If there is such a spanning instance, then it can be used to sync everyone, in which casethe Rank from the dependent instances is not used for time sync.
What do others think?

Pascal

Hi Pascal,

my comment inline:

Please see inline:

Qin, Xavi,

Qin

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 23 Aug 2013 07:51:59 -0700

Raghuram,
Thanks for your explanation, your point is very clear now. Let's discuss
during the call.
Thomas

On Fri, Aug 23, 2013 at 7:46 AM, Raghuram Sudhaakar (rsudhaak) <
[email-masked]> wrote:

>  Please see inline
>
>   From: Thomas Watteyne <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>
> is whether join priority reflects DAGrank or not.
> The RPL trickle timer period can very easily become a large value if the
> network is static. In this time if a node does switch off, it is most like
> that L2 will detect it first since it would have received EB from its
> current parent. Now if we force it that the RPL parent has to be the timing
> parent we cannot find a timing parent until L3 detects the topology change.
> If we allow L2 to initiate a join process and choose a new timing parent
> and inform L3 we may be violating the RPL OF. This is the situation that I
> was referring to. I feel that there is a fair probability of this
> happening. Thoughts ?
>
>  To address this we probably need to allow RPL to change the topology
> based on the OF, after L2 join has occurred. Then L2 can change its timing
> parent to be synced with DAG structure.
>
> into account, but only if they are synchronized through some out-of-band
> mechanism.
>
>
>> The alternate would be to sync the whole network completely independent
>> of RPL DAGs etc… eg using a GPS.****
>>
>> default behavior that does not make the assumption of a GPS or similar.**
>> **
>>
>> ** **
>>
>> Makes sense?****
>>
>> ** **
>>
>> Cheers,****
>>
>> ** **
>>
>> Pascal****
>>
>> ** **
>>
>> Note that DODAGs partition the network, and all the parents must be in
>> one of them.****
>>
>>  ****
>>
>> Cheers;****
>>
>>  ****
>>
>> Pascal****
>>
>>  ****
>>
>> graph?****