Subject: [6tsch] RPL on Basic

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 9 Aug 2013 11:32:26 -0700

Hi all,

after discussion today I would like to start working on the contents that
we want regarding RPL on Basic TSCH. Here I list some points I guess should
go there:

-RPL objective function calculation using Neighbors information described
in Basic configuration.
    -this includes how OF is calculated using numTx and numTxACK, etc..
-RPL configuration:
     - storing mode vs non-storing mode (I vote for non-storing mode for a
basic configuration)
     - DIO period. Whether we use trickle algorithm (and we define the
initial period) or we use a fix period for DIO (no trickle) for basic
configuration.
      -DAO period, idem.

I kindly ask for opinions and contribution to this items so we can start
narrowing the content.

thanks!
X

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 12 Aug 2013 09:52:10 -0700

Xavi,

I believe this is a good first list. It might be interesting to go over
RFC6552 with TSCH eyes, and see whether there is anything that would
prevent us from using that as-is. It would certainly be nice if we could.

Thomas

On Fri, Aug 9, 2013 at 11:32 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: Mon, 12 Aug 2013 10:19:17 -0700

Thanks Thomas, I will do.

cheers!
x

On Mon, Aug 12, 2013 at 9:52 AM, Thomas Watteyne <[email-masked]
> wrote:

>>      - storing mode vs non-storing mode (I vote for non-storing mode for
>> a basic configuration)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Aug 2013 18:23:31 +0000

Hello Xavi:

Please see inline

-RPL objective function calculation using Neighbors information described in Basic configuration.
    -this includes how OF is calculated using numTx and numTxACK, etc..

[]
-RPL configuration:
     - storing mode vs non-storing mode (I vote for non-storing mode for a basic configuration)

[] I would MUST the non-storing and MAY the storing mode support. It's still good t enable storing mode interop for larger devices.

     - DIO period. Whether we use trickle algorithm (and we define the initial period) or we use a fix period for DIO (no trickle) for basic configuration.
      -DAO period, idem.
[] I'd seek for a recommendation from Phil on the trickle setting.
I kindly ask for opinions and contribution to this items so we can start narrowing the content.
[] We need to discuss NUD as well. How do we know a peer is gone missing? Only reactive to traffic has issues like a child may never realize a parent is gone if there is no outwards traffic so it will fail to update DAO states. How can MAC mechanisms help?
Some of that discussion may be spread between other drafts like the architecture.

Cheers;

Pascal

thanks!
X

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

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Mon, 12 Aug 2013 11:37:46 -0700

Hi Pascal,

*[] *We need to discuss NUD as well. How do we know a peer is gone missing?
Only reactive to traffic has issues like a child may never realize a parent
is gone if there is no outwards traffic so it will fail to update DAO
states. How can MAC mechanisms help?

Keep alive packets help on that. :-)
X

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

>  Hello Xavi:****
> ** **
> ** **
> Please see inline****
> ** **
> in Basic configuration. ****
>
>     -this includes how OF is calculated using numTx and numTxACK, etc.. **
> **
>
> ** **
>
> *[] *
>
> -RPL configuration:****
>
> basic configuration)****
> ** **
> *[] *I would MUST the non-storing and MAY the storing mode support. It’s
> still good t enable storing mode interop for larger devices.****
>
> ** **
>
> configuration.****
>       -DAO period, idem.****
> *[] *I’d seek for a recommendation from Phil on the trickle setting.****
>
> narrowing the content.****
>
> *[] *We need to discuss NUD as well. How do we know a peer is gone
> missing? Only reactive to traffic has issues like a child may never realize
> a parent is gone if there is no outwards traffic so it will fail to update
> DAO states. How can MAC mechanisms help?****
>
> Some of that discussion may be spread between other drafts like the
> architecture.****
>
> ** **
>
> Cheers;****
>
> ** **
>
> Pascal****
>
> ** **
>
> thanks!
> X****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Aug 2013 18:46:51 +0000

Hello Xavi:

Sure. NUD generates a reactive keep alive. Proactive heart beat that comes at a periodic battery drain. Question is what is the optimal way with TSCH for a child to find that the parent is gone, in the absence of traffic?
Knowing that we'll have (or not) EBs, and that we will (or not) time sync from the RPL parent, there is probably something we can recommend, and limitations to the granularity that we get.

Cheers,

Pascal

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: lundi 12 août 2013 20:38
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] RPL on Basic

Hi Pascal,

On Mon, Aug 12, 2013 at 11:23 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Xavi:

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 12 Aug 2013 23:59:13 -0700

We established a while ago that we could reuse the RPL DAG structure for
timekeeping. That is, a node's routing parent coincides with its TSCH time
source neighbor. As a result, and as part of IEEE802.15.4e's normal
operation, a node keeps synchronized with its RPL parent. In the absence of
traffic, the node will periodically "keep alive" (per Xavi's e-mail) to the
parent. How often depends on a number of factors, including crystal drift
and guard time, but in a typical case, a node will realize its routing
parent is missing after 30-60s.

I believe this mechanism can serve for NUD, at least n the child->parent
case. Of course, this alone does no cover parent->child or NUD between
siblings. Any thoughts on the implications of limiting NUD to the
child->parent case?

On Mon, Aug 12, 2013 at 11:46 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Xavi:****
>
> ** **
>
> Sure. NUD generates a reactive keep alive. Proactive heart beat that comes
> at a periodic battery drain. Question is what is the optimal way with TSCH
> for a child to find that the parent is gone, in the absence of traffic?***
> *
>
> Knowing that we’ll have (or not) EBs, and that we will (or not) time sync
> from the RPL parent, there is probably something we can recommend, and
> limitations to the granularity that we get.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* Xavier Vilajosana Guillen [mailto:[email-masked]]
> *Sent:* lundi 12 août 2013 20:38
> *To:* Pascal Thubert (pthubert)
> *Cc:* Thomas Watteyne; [email-masked]
> *Subject:* Re: [6tsch] RPL on Basic****
>
> ** **
>
> Hi Pascal,
>
> Keep alive packets help on that. :-)****
>
> X****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hello Xavi:****
>
>  ****
>
>  ****
>
> Please see inline****
>
>  ****
>
>  ****
> *[] *****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****

---

From: Qin Wang <[email-masked]>
Date: Tue, 13 Aug 2013 21:18:49 +0800

Hi Thomas and Xavi,

I remember keep-alive usually use dedicated cell, instead of shared cell,
e.g. a Rx cell in child, and a Tx cell in parent. But, with EB-based
schedule establishment, a child will only have shared cell. And then,
keep-alive has to use shared cell, which may result in more collision and
then traffic.

Thought?

Qin

On Tue, Aug 13, 2013 at 2:59 PM, Thomas Watteyne <[email-masked]

>> Sure. NUD generates a reactive keep alive. Proactive heart beat that
>> comes at a periodic battery drain. Question is what is the optimal way with
>> TSCH for a child to find that the parent is gone, in the absence of traffic?
>> ****
>>
>>     -this includes how OF is calculated using numTx and numTxACK, etc.. *
>> ***
>>
>>  ****
>>
>> *[] *****
>>
>> -RPL configuration:****
>>
>> a basic configuration)****
>>
>>  ****
>>

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 14:19:21 +0000

Dear Qin, All,
I agree that Keep-alive message need to be sent in the dedicated cell to the potential neighbor/parent, whenever the sender has not received any packet from its neighbor/parent for a while. But, in this basic RPL, we might use the shared cell, as a temporary solution, to send the keep-alive to a particular neighbor. For sure, if the sender packet is not acknowledged (by the first time), the sender can't find, if the transmission is collided or if the connection to the neighbor/parent is lost. In this case I think we need to retry several times based on TSCH retransmission algorithm on those shared cells. If all the retries fails then the connection to the neighbor/parent is lost.
Since the nodes do not need to send the keep-alive message so often, therefore the traffic caused by Keep-alive is not too much.
Am I right?
BTW, do we have any common shared cell (in the whole network) to broadcast the Keep-alive message periodically to let the node to be recognized by its neighbor?

Best wishes,
Pouria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Tuesday, August 13, 2013 3:19 PM
To: Thomas Watteyne
Cc: [email-masked]
Subject: Re: [6tsch] RPL on Basic

Hi Thomas and Xavi,

I remember keep-alive usually use dedicated cell, instead of shared cell, e.g. a Rx cell in child, and a Tx cell in parent. But, with EB-based schedule establishment, a child will only have shared cell. And then, keep-alive has to use shared cell, which may result in more collision and then traffic.

Thought?

Qin

On Tue, Aug 13, 2013 at 2:59 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
We established a while ago that we could reuse the RPL DAG structure for timekeeping. That is, a node's routing parent coincides with its TSCH time source neighbor. As a result, and as part of IEEE802.15.4e's normal operation, a node keeps synchronized with its RPL parent. In the absence of traffic, the node will periodically "keep alive" (per Xavi's e-mail) to the parent. How often depends on a number of factors, including crystal drift and guard time, but in a typical case, a node will realize its routing parent is missing after 30-60s.

I believe this mechanism can serve for NUD, at least n the child->parent case. Of course, this alone does no cover parent->child or NUD between siblings. Any thoughts on the implications of limiting NUD to the child->parent case?

On Mon, Aug 12, 2013 at 11:46 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Xavi:

Cheers,

Pascal

From: Xavier Vilajosana Guillen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: lundi 12 août 2013 20:38
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] RPL on Basic

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Pascal Thubert <[email-masked]>
Date: Tue, 13 Aug 2013 18:25:05 +0200

hello Thomas

This is exactly the sort of text I'm asking for. Make a decision, show the
limits.
NUD parent to child is secondary because we can still react to traffic.
The problem with child to parent is that the child must select a new parent
and send DAOs so as to be able to get traffic back.
In the case of unidirectional traffic to the device, this would never
happen if ther is no NUD that is independent of the traffic.

This part of the discussion may be split between the basic doc and teh
architecture doc, though...

Cheers,

Pascal

2013/8/13 Thomas Watteyne <[email-masked]>

-- 
Pascal

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 13 Aug 2013 09:46:40 -0700

Hi Pouria,

I completely agree with your description. Besides, there isn't a common
shared cell to send KAs. I see the operation in the following way:
6top KA timer expires and places a KA packet into the queue (e.g this
happens every 30s). TSCH layer at the begining of a shared tx/rx slot then
reads from the queue and sends the packet. This means that the KA can be
send in any shared slot.

does it make sense?
X

On Tue, Aug 13, 2013 at 7:19 AM, <[email-masked]> wrote:

>  Dear Qin, All,****
>
> I agree that Keep-alive message need to be sent in the dedicated cell to
> the potential neighbor/parent, whenever the sender has not received any
> packet from its neighbor/parent for a while. But, in this basic RPL, we
> might use the shared cell, as a temporary solution, to send the keep-alive
> to a particular neighbor. For sure, if the sender packet is not
> acknowledged (by the first time), the sender can’t find, if the
> transmission is collided or if the connection to the neighbor/parent is
> lost. In this case I think we need to retry several times based on TSCH
> retransmission algorithm on those shared cells. If all the retries fails
> then the connection to the neighbor/parent is lost.****
>
> Since the nodes do not need to send the keep-alive message so often,
> therefore the traffic caused by Keep-alive is not too much.****
>
> Am I right? ****
>
> BTW, do we have any common shared cell (in the whole network) to broadcast
> the Keep-alive message periodically to let the node to be recognized by its
> neighbor?****
>
> ** **
>
> Best wishes,****
>
> Pouria****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Qin Wang
> *Sent:* Tuesday, August 13, 2013 3:19 PM
> *To:* Thomas Watteyne
> *Cc:* [email-masked]
>
> Hi Thomas and Xavi,****
> then traffic.****
> Thought?****
> Qin ****
> On Tue, Aug 13, 2013 at 2:59 PM, Thomas Watteyne <
> [email-masked]> wrote:****
>
> parent is missing after 30-60s.****
>
> ** **
>
> child->parent case?****

---

From: Qin Wang <[email-masked]>
Date: Wed, 14 Aug 2013 01:32:54 +0800

Hi Xavi,

I have two questions about the shared cells.

(1) Corresponding to a shared cell advertised in EB, what should the cell
type be set in the advertiser? Should be Rx?
(2) Should it be required for all of the nodes in neighborhood to be awake
in the shared cells?

Basically, my concern is that when a keep-alive is sent out, the
destination node is most likely in listening mode.

Thanks
Qin

On Wed, Aug 14, 2013 at 12:46 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

>> BTW, do we have any common shared cell (in the whole network) to
>> broadcast the Keep-alive message periodically to let the node to be
>> recognized by its neighbor?****
>>
>> ** **
>>
>> Best wishes,****
>>
>> Pouria****
>>
>> ** **
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Qin Wang

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 13 Aug 2013 10:44:38 -0700

Hi Qin, see inline

Hi Xavi,

The cell type is defined in a bitmap. The TX,RX and SHARED bits should be
set.

Well, if cells are shared (slotted aloha), nodes wake up, if they have
something to transmit they transmit, if not, they listen. If there is
nothing to be listened the slot becomes an idle listen slot, which means
that the radio is only on for the duration of the guard time.  If a packet
arrives the node gets it. (in fact all listening nodes that can hear the
packet get it but the packet is discarded by all of them except the
destination. This happens at the MAC layer as the destination address does
not match to the node's address)

Most likely is in listening mode unless has something to transmit at that
slot, then a collision will happen.
Is there something that you don't like about that approach :-) ?

X

Thanks

On Tue, Aug 13, 2013 at 10:32 AM, Qin Wang <[email-masked]> wrote:

>>> I remember keep-alive usually use dedicated cell, instead of shared
>>> cell, e.g. a Rx cell in child, and a Tx cell in parent. But, with EB-based
>>> Knowing that we’ll have (or not) EBs, and that we will (or not) time
>>> sync from the RPL parent, there is probably something we can recommend, and
>>> -RPL objective function calculation using Neighbors information
>>> described in Basic configuration. ****
>>>
>>> *[] *I would MUST the non-storing and MAY the storing mode support.
>>> It’s still good t enable storing mode interop for larger devices.****
>>>
>>>  ****
>>>

---

From: Qin Wang <[email-masked]>
Date: Wed, 14 Aug 2013 02:06:20 +0800

Xavi,

I agree to using keep-alive as one of UND methods. For this purpose, I
think we should add some configuration profile in the documents, something
like your answers to my questions.

Make sense?

Qin

On Wed, Aug 14, 2013 at 1:44 AM, Xavier Vilajosana Guillen <
[email-masked]> wrote:

>> (2) Should it be required for all of the nodes in neighborhood to be
>> awake in the shared cells?
>>
>>>> I agree that Keep-alive message need to be sent in the dedicated cell
>>>> to the potential neighbor/parent, whenever the sender has not received any
>>>> We established a while ago that we could reuse the RPL DAG structure
>>>> for timekeeping. That is, a node's routing parent coincides with its TSCH
>>>> time source neighbor. As a result, and as part of IEEE802.15.4e's normal
>>>> I believe this mechanism can serve for NUD, at least n the
>>>> child->parent case. Of course, this alone does no cover parent->child or
>>>> NUD between siblings. Any thoughts on the implications of limiting NUD to
>>>> the child->parent case?****
>>>>
>>>> ** **
>>>>
>>>>      - storing mode vs non-storing mode (I vote for non-storing mode
>>>> for a basic configuration)****
>>>>
>>>>  ****
>>>>
>>>> I kindly ask for opinions and contribution to this items so we can
>>>> start narrowing the content.****
>>>>

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 19:40:58 +0000

Xavi,

Keep Alive timer expires for "node A" after 30s if no frames have been sent (or received) to (or from) neighbor "node B". Am I right?

In 6top, (1) should not every node follow this scheme to probe its connection with all the neighbors that has already received their EB with acceptable RSSI? Or (2) the node should probe its connection with the its RPL parent and its RPL child? In the case (2), how does the 6top can inform the L3 about the new potential discovered neighbors and their connection status?

Pouria

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: Tuesday, August 13, 2013 6:47 PM
To: Zand, P. (EWI)
Cc: Qin Wang; Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] RPL on Basic

Hi Pouria,
I completely agree with your description. Besides, there isn't a common shared cell to send KAs. I see the operation in the following way:
6top KA timer expires and places a KA packet into the queue (e.g this happens every 30s). TSCH layer at the begining of a shared tx/rx slot then reads from the queue and sends the packet. This means that the KA can be send in any shared slot.
does it make sense?
X

On Tue, Aug 13, 2013 at 7:19 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Qin, All,
I agree that Keep-alive message need to be sent in the dedicated cell to the potential neighbor/parent, whenever the sender has not received any packet from its neighbor/parent for a while. But, in this basic RPL, we might use the shared cell, as a temporary solution, to send the keep-alive to a particular neighbor. For sure, if the sender packet is not acknowledged (by the first time), the sender can't find, if the transmission is collided or if the connection to the neighbor/parent is lost. In this case I think we need to retry several times based on TSCH retransmission algorithm on those shared cells. If all the retries fails then the connection to the neighbor/parent is lost.
Since the nodes do not need to send the keep-alive message so often, therefore the traffic caused by Keep-alive is not too much.
Am I right?
BTW, do we have any common shared cell (in the whole network) to broadcast the Keep-alive message periodically to let the node to be recognized by its neighbor?

Best wishes,
Pouria

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Qin Wang
Sent: Tuesday, August 13, 2013 3:19 PM
To: Thomas Watteyne
Cc: [email-masked]<mailto:[email-masked]>

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 13 Aug 2013 13:16:46 -0700

Hi Pouria,

answer inline:

Xavi,

Keep Alive timer expires for “node A” after 30s if no frames have been sent
(or received) to (or from) neighbor “node B”. Am I right?

there are many different ways to implement that, this is an option.

In 6top, (1) should not every node follow this scheme to probe its
connection with all the neighbors that has already received their EB with
acceptable RSSI?

These are the list of known neighbors with acceptable RSSI, so yes if it
wants to keep all of them.

Or (2) the node should probe its connection with the its RPL parent and its
RPL child? In the case (2), how does the 6top can inform the L3 about the
new potential discovered neighbors and their connection status?

When a node is discovered due to receiving and EB (at least in our openwsn
implementation), it is inserted at the neighbor table. At that point no
information about connectivity can be used except RSSI. As soon as a DIO is
received from that node, its information is updated (including rank). As we
don't have any information about connectivity (as RFC6552 describes) an
initial value is set (i.e rank + FOO). In openwsn a similar case to (1) is
used so eventually some stats of the link can be used to compute the ETX
and let RPL do its work.

So RPL knows about a new node because 6TOP keeps information of neighbors
an eventually this information is used by RPL to update routes. As this
node sends DIOs and receives DIOs from others the information is
permanently being updated enabling a node to be positioned in the multihop
topology.

Does it make sense?

Pouria

On Tue, Aug 13, 2013 at 12:40 PM, <[email-masked]> wrote:

>  Xavi,****
>
> ** **
>
> Keep Alive timer expires for “node A” after 30s if no frames have been
> sent (or received) to (or from) neighbor “node B”. Am I right?****
>
> ** **
>
> In 6top, (1) should not every node follow this scheme to probe its
> connection with all the neighbors that has already received their EB with
> acceptable RSSI? Or (2) the node should probe its connection with the its
> RPL parent and its RPL child? In the case (2), how does the 6top can inform
> the L3 about the new potential discovered neighbors and their connection
> status?    ****
>
> ** **
>
> Pouria****
>
> ** **
>
> ** **
>
> *Sent:* Tuesday, August 13, 2013 6:47 PM
> *To:* Zand, P. (EWI)
> *Cc:* Qin Wang; Thomas Watteyne; [email-masked]
>
> Hi Pouria,****
> shared cell to send KAs. I see the operation in the following way:****
>
> send in any shared slot. ****
>
> does it make sense?
> X****
>
> ** **
>
> On Tue, Aug 13, 2013 at 7:19 AM, <[email-masked]> wrote:****
>
> Dear Qin, All,****
>
> *Cc:* [email-masked]****

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 21:05:29 +0000

Xavi,

Many thanks for your complete explanation. It absolutely makes sense.

Just one minor question. The neighbor table will be stored in 6top. Am I right? If yes, do we need to store rank information (included in DIO) in that table? Or we just store neighbor statistic?

Pouria

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: Tuesday, August 13, 2013 10:17 PM
To: Zand, P. (EWI)
Cc: Qin Wang; Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] RPL on Basic

Hi Pouria,
answer inline:

Xavi,

In 6top, (1) should not every node follow this scheme to probe its connection with all the neighbors that has already received their EB with acceptable RSSI?

These are the list of known neighbors with acceptable RSSI, so yes if it wants to keep all of them.

Or (2) the node should probe its connection with the its RPL parent and its RPL child? In the case (2), how does the 6top can inform the L3 about the new potential discovered neighbors and their connection status?

When a node is discovered due to receiving and EB (at least in our openwsn implementation), it is inserted at the neighbor table. At that point no information about connectivity can be used except RSSI. As soon as a DIO is received from that node, its information is updated (including rank). As we don't have any information about connectivity (as RFC6552 describes) an initial value is set (i.e rank + FOO). In openwsn a similar case to (1) is used so eventually some stats of the link can be used to compute the ETX and let RPL do its work.

So RPL knows about a new node because 6TOP keeps information of neighbors an eventually this information is used by RPL to update routes. As this node sends DIOs and receives DIOs from others the information is permanently being updated enabling a node to be positioned in the multihop topology.

Does it make sense?

Pouria

On Tue, Aug 13, 2013 at 12:40 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

Pouria

From: Xavier Vilajosana Guillen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, August 13, 2013 6:47 PM
To: Zand, P. (EWI)
Cc: Qin Wang; Thomas Watteyne; [email-masked]<mailto:[email-masked]>

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 13 Aug 2013 14:13:29 -0700

Hi Pouria,

yes the neighbor table is something that 6top takes care of. The fields of
the table is something that we need to work on, stats for sure as described
by the basic configuration draft. As regards to the rank, in our
implementation, we keep it in the table, for each neighbour we keep its
rank. This information can be placed somewhere else if you want but I guess
we need it to keep some sense on what is the rank of our neighbors.

regards,
Xavi

On Tue, Aug 13, 2013 at 2:05 PM, <[email-masked]> wrote:

>  Xavi,****
>
> ** **
>
> Many thanks for your complete explanation. It absolutely makes sense.****
>
> ** **
>
> Just one minor question. The neighbor table will be stored in 6top. Am I
> right? If yes, do we need to store rank information (included in DIO) in
> that table? Or we just store neighbor statistic?****
>
> ** **
>
> Pouria ****
>
> ** **
>
> ** **
>
> *Sent:* Tuesday, August 13, 2013 10:17 PM
>
> *To:* Zand, P. (EWI)
> answer inline:****
> there are many different ways to implement that, this is an option.****
>
>  ****
>
> acceptable RSSI?****
> wants to keep all of them.****
>
> Or (2) the node should probe its connection with the its RPL parent and
> its RPL child? In the case (2), how does the 6top can inform the L3 about
> the new potential discovered neighbors and their connection status? ****
>
> and let RPL do its work. ****
>
> topology.****
> Does it make sense?****
> On Tue, Aug 13, 2013 at 12:40 PM, <[email-masked]> wrote:****
>
> Xavi,****
>
>  ****
>
> *Cc:* Qin Wang; Thomas Watteyne; [email-masked]****
>
>

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 21:20:13 +0000

Xavi,

I guess we cannot keep "node rank" in the 6top. Because a node might have different rank based on different metrics defined in L3. As a response, I don't think we can get all of those information form L3 and use them in neighbor table in 6top. Am I right?
I think, as you mentioned we need to work on them.

Pouria

From: Xavier Vilajosana Guillen [mailto:[email-masked]]
Sent: Tuesday, August 13, 2013 11:13 PM
To: Zand, P. (EWI)
Cc: Qin Wang; Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] RPL on Basic

Hi Pouria,

yes the neighbor table is something that 6top takes care of. The fields of the table is something that we need to work on, stats for sure as described by the basic configuration draft. As regards to the rank, in our implementation, we keep it in the table, for each neighbour we keep its rank. This information can be placed somewhere else if you want but I guess we need it to keep some sense on what is the rank of our neighbors.
regards,
Xavi

On Tue, Aug 13, 2013 at 2:05 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Tue, 13 Aug 2013 14:27:13 -0700

Good point :-)

agreed!
X

On Tue, Aug 13, 2013 at 2:20 PM, <[email-masked]> wrote:

>  Xavi,****
>
> ** **
>
> I guess we cannot keep “node rank” in the 6top. Because a node might have
> different rank based on different metrics defined in L3. As a response, I
> don’t think we can get all of those information form L3 and use them in
> neighbor table in 6top. Am I right? ****
>
> I think, as you mentioned we need to work on them. ****
>
> ** **
>
> Pouria  ****
>
> ** **
>
> *Sent:* Tuesday, August 13, 2013 11:13 PM
>
> *To:* Zand, P. (EWI)
> we need it to keep some sense on what is the rank of our neighbors.****
>
> regards,****
>
> Xavi****
>
> ** **
>
> ** **
>
> On Tue, Aug 13, 2013 at 2:05 PM, <[email-masked]> wrote:****
>
> Xavi,****
>
>  ****
>
> *Sent:* Tuesday, August 13, 2013 10:17 PM****
>
>
> *To:* Zand, P. (EWI)

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Tue, 13 Aug 2013 22:56:58 +0000

Xavi, Pouria,
I think we need to keep node rank at 6top (as a read only parameter obtained from L3) in order for the TSCH nodes to figure out the timing parent. In the case where RPL node may have different ranks based on different OFs we need a method to pick a timing parent.

We should propose a default OF, that is used to compute the ranks for the purpose finding the timing parent.

-raghuram

From: Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>>
Reply-To: <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 13, 2013 2:27 PM
To: Pouria Zand <[email-masked]<mailto:[email-masked]>>
Cc: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Qin Wang <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tsch] RPL on Basic

Good point :-)

agreed!
X

On Tue, Aug 13, 2013 at 2:20 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

I guess we cannot keep “node rank” in the 6top. Because a node might have different rank based on different metrics defined in L3. As a response, I don’t think we can get all of those information form L3 and use them in neighbor table in 6top. Am I right?
I think, as you mentioned we need to work on them.

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Keep Alive timer expires for “node A” after 30s if no frames have been sent (or received) to (or from) neighbor “node B”. Am I right?

Does it make sense?

Pouria

Keep Alive timer expires for “node A” after 30s if no frames have been sent (or received) to (or from) neighbor “node B”. Am I right?

Pouria

Hi Pouria,

On Tue, Aug 13, 2013 at 7:19 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Qin, All,
I agree that Keep-alive message need to be sent in the dedicated cell to the potential neighbor/parent, whenever the sender has not received any packet from its neighbor/parent for a while. But, in this basic RPL, we might use the shared cell, as a temporary solution, to send the keep-alive to a particular neighbor. For sure, if the sender packet is not acknowledged (by the first time), the sender can’t find, if the transmission is collided or if the connection to the neighbor/parent is lost. In this case I think we need to retry several times based on TSCH retransmission algorithm on those shared cells. If all the retries fails then the connection to the neighbor/parent is lost.
Since the nodes do not need to send the keep-alive message so often, therefore the traffic caused by Keep-alive is not too much.
Am I right?
BTW, do we have any common shared cell (in the whole network) to broadcast the Keep-alive message periodically to let the node to be recognized by its neighbor?

Best wishes,
Pouria

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Qin Wang
Sent: Tuesday, August 13, 2013 3:19 PM
To: Thomas Watteyne
Cc: [email-masked]<mailto:[email-masked]>

Hi Thomas and Xavi,

Thought?

Qin

Sure. NUD generates a reactive keep alive. Proactive heart beat that comes at a periodic battery drain. Question is what is the optimal way with TSCH for a child to find that the parent is gone, in the absence of traffic?
Knowing that we’ll have (or not) EBs, and that we will (or not) time sync from the RPL parent, there is probably something we can recommend, and limitations to the granularity that we get.

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

[] I would MUST the non-storing and MAY the storing mode support. It’s still good t enable storing mode interop for larger devices.

[] I’d seek for a recommendation from Phil on the trickle setting.

Cheers;

Pascal

thanks!
X

---

From: <[email-masked]>
Date: Thu, 15 Aug 2013 22:07:30 +0000

Raghuram,
I agree with you that we need a method to pick a timing parent.
We might need the L3 information on that, unless we can find a solution in 6top to use L2 information. For example about the clock accuracy capabilities of the device who has already joined the network. I am not sure if this information is available in L2 and neighbor table.
Best Wishes,
Pouria

From: Raghuram Sudhaakar (rsudhaak) [mailto:[email-masked]]
Sent: Wednesday, August 14, 2013 12:57 AM
To: [email-masked]; Zand, P. (EWI)
Cc: Thomas Watteyne; [email-masked]; Qin Wang
Subject: Re: [6tsch] RPL on Basic

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 18 Aug 2013 19:28:00 -0700

Pouria, all,

My 2c is the following. We already agreed on the fact that a mote's (RPL)
routing parent would also be its (TSCH) time source neighbor. So why not
pick the time source neighbor based on routing information?

What exactly do you mean by clock accuracy? All nodes in a TSCH network
need to be able to synchronize with one another, and I don't think we are
considering cases where that is not true.

Thomas

On Thu, Aug 15, 2013 at 3:07 PM, <[email-masked]> wrote:

>  Raghuram,****
>
> I agree with you that we need a method to pick a timing parent.****
>
> We might need the L3 information on that, unless we can find a solution in
> 6top to use L2 information. For example about the clock accuracy
> capabilities of the device who has already joined the network. I am not
> sure if this information is available in L2 and neighbor table.****
>
> Best Wishes,****
>
> Pouria****
>
> ** **
>
> *From:* Raghuram Sudhaakar (rsudhaak) [mailto:[email-masked]]
> *Sent:* Wednesday, August 14, 2013 12:57 AM
> *To:* [email-masked]; Zand, P. (EWI)
> *Cc:* Thomas Watteyne; [email-masked]; Qin Wang
>
> Xavi, Pouria,****
> I think we need to keep node rank at 6top (as a read only parameter
> obtained from L3) in order for the TSCH nodes to figure out the timing
> parent. In the case where RPL node may have different ranks based on
> different OFs we need a method to pick a timing parent.****
>
> ** **
>
> We should propose a default OF, that is used to compute the ranks for the
> purpose finding the timing parent.****
>
> ** **
>
> -raghuram****
>
> ** **
>
> *From: *Xavier Vilajosana Guillen <[email-masked]>
> *Reply-To: *<[email-masked]>
> *Date: *Tuesday, August 13, 2013 2:27 PM
> *To: *Pouria Zand <[email-masked]>
> *Cc: *Thomas Watteyne <[email-masked]>, "[email-masked]" <
> [email-masked]>, Qin Wang <[email-masked]>
> *Subject: *Re: [6tsch] RPL on Basic****
>
> ** **
>
> Good point :-)****
>
> agreed!
> X****
>
> ** **
>
> On Tue, Aug 13, 2013 at 2:20 PM, <[email-masked]> wrote:****
>
> Xavi,****
>
>  ****
>
> *Sent:* Tuesday, August 13, 2013 11:13 PM****
>
>
> *To:* Zand, P. (EWI)
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Qin Wang

---

From: <[email-masked]>
Date: Mon, 19 Aug 2013 17:57:37 +0000

Thomas,

I am not expert in synchronization, so please bear with me.

By clock accuracy information, I mean how accurate a node can maintain (e.g. ±1 ms) synchronization in the network for a period of time (e.g. 20 s) without the need for clock update. Different devices might have different clock accuracy values represent by parts per million (ppm) unit. The clock accuracy of a device might depend on the device' environment conditions (e.g. temperature or shocks) and it doesn't just depend on crystals hardware. Am I right?

In the centralized approach, the System/Network managers, use (L2) device clock accuracy information as well as (L3) nodes' topology information (similar to node's rank in RPL in 6tsch distributed approach) to select the potential clock sources in the network. Am I right?

In a distributed approach, a network device might inform their neighbors about its (L2) clock accuracy. A new device might use this information, as well as L3 parameters (e.g. sender RPL' rank), to choose its timing parent.

If in 6tsch, we are considering the case that all the nodes in the network have equal high clock accuracy, then let's consider (L3) router's rank, based on the default OF (as Raghuram suggest), as the only factor for selecting timing parent.

Pouria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Monday, August 19, 2013 4:28 AM
To: 6TSCH
Subject: Re: [6tsch] RPL on Basic

Pouria, all,

My 2c is the following. We already agreed on the fact that a mote's (RPL) routing parent would also be its (TSCH) time source neighbor. So why not pick the time source neighbor based on routing information?

What exactly do you mean by clock accuracy? All nodes in a TSCH network need to be able to synchronize with one another, and I don't think we are considering cases where that is not true.

Thomas

On Thu, Aug 15, 2013 at 3:07 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Raghuram,
I agree with you that we need a method to pick a timing parent.
We might need the L3 information on that, unless we can find a solution in 6top to use L2 information. For example about the clock accuracy capabilities of the device who has already joined the network. I am not sure if this information is available in L2 and neighbor table.
Best Wishes,
Pouria

From: Raghuram Sudhaakar (rsudhaak) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 14, 2013 12:57 AM
To: [email-masked]<mailto:[email-masked]>; Zand, P. (EWI)
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>; Qin Wang

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 19 Aug 2013 22:54:27 -0700

Pouria,
Thanks for the explanation. Allow me to answer inline.
Thomas

On Mon, Aug 19, 2013 at 10:57 AM, <[email-masked]> wrote:

>  Thomas,****
>
> ** **
>
> I am not expert in synchronization, so please bear with me.****
>
> ** **
>
> By clock accuracy information, I mean how accurate a node can maintain
> (e.g. ±1 ms) synchronization in the network for a period of time (e.g. 20
> s) without the need for clock update. Different devices might have
> different clock accuracy values represent by parts per million (ppm) unit.
> The clock accuracy of a device might depend on the device’ environment
> conditions (e.g. temperature or shocks) and it doesn’t just depend on
> crystals hardware. Am I right?
>

Agreed. I am used to the term "clock drift" for the phenomenon, but
absolutely, drift depends on manufacturing, voltage, temperature, and
probably other environmental factors. The amount of drift of your clock
source will dictate how often resynchronization needs to happen, given a
guard time (i.e. 1ms). Of course, all these parameters depend on each
other, so you can imagine buying a better clock source, or changing the
re-synchronization frequency, or changing the guard time.

****
>
> ** In the centralized approach, the System/Network managers, use (L2)
> device clock accuracy information as well as (L3) nodes’ topology
> information (similar to node’s rank in RPL in 6tsch distributed approach)
> to select the potential clock sources in the network. Am I right?
>

Hmm. I understand what you are proposing, but my first reaction is to be a
bit afraid that basing time source neighbor selection on clock drift
information might lead to lots of complexity, for not much gain (I think).
If I am drifting a lot wrt to my neighbor, could I not resolve that locally
(through all kind of techniques we can think of), rather than involving the
time source neighbor selection process in that?

>  In a distributed approach, a network device might inform their neighbors
> about its (L2) clock accuracy. A new device might use this information, as
> well as L3 parameters (e.g. sender RPL’ rank), to choose its timing parent.
>

This would certainly invert the approach. Now, we let RPL select routing
parents, and then we have TSCH just use the same. If we go the other way
around, i.e. select time source neighbors, then routes, many things will
get complicated real quick, the first of which are synchronization loops.

> ** If in 6tsch, we are considering the case that all the nodes in the
> network have equal high clock accuracy, then let’s consider (L3) router’s
> rank, based on the *default OF* (as Raghuram suggest), as the only factor
> for selecting timing parent.
>
> **
>
I would go that route, but maybe you have some counter example in mind?

> Of *Thomas Watteyne
> *Sent:* Monday, August 19, 2013 4:28 AM
> *To:* 6TSCH
>
> Pouria, all,****
> pick the time source neighbor based on routing information?****
>
> ** **
>
> considering cases where that is not true.****
>
> ** **
>
> Thomas****
>
> ** **
>
> On Thu, Aug 15, 2013 at 3:07 PM, <[email-masked]> wrote:****
>
> Raghuram,****
>
> *Cc:* Thomas Watteyne; [email-masked]; Qin Wang****
>
>

---

From: <[email-masked]>
Date: Tue, 20 Aug 2013 19:53:30 +0000

Thomas,

Many thanks for your explanation.
I couldn't find the related counter in MAC PIB of IEEE 802.15.4.

My first idea was using both (a) clock accuracy information and (b) RPL rank information for choosing the best timing parent between two routers with equal (or close) RPL rank. That would help us to avoid (1) synchronization loop problem and (2) potential drifting problem caused by choosing the parent, between two with equal ranks but not equal clock accuracy.

As you mentioned, let's not make it complicated and consider the parent rank as a factor for choosing the timing parent.

Pouria.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Tuesday, August 20, 2013 7:54 AM
To: 6TSCH
Subject: Re: [6tsch] RPL on Basic

Pouria,

On Mon, Aug 19, 2013 at 10:57 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

Agreed. I am used to the term "clock drift" for the phenomenon, but absolutely, drift depends on manufacturing, voltage, temperature, and probably other environmental factors. The amount of drift of your clock source will dictate how often resynchronization needs to happen, given a guard time (i.e. 1ms). Of course, all these parameters depend on each other, so you can imagine buying a better clock source, or changing the re-synchronization frequency, or changing the guard time.

Hmm. I understand what you are proposing, but my first reaction is to be a bit afraid that basing time source neighbor selection on clock drift information might lead to lots of complexity, for not much gain (I think). If I am drifting a lot wrt to my neighbor, could I not resolve that locally (through all kind of techniques we can think of), rather than involving the time source neighbor selection process in that?

This would certainly invert the approach. Now, we let RPL select routing parents, and then we have TSCH just use the same. If we go the other way around, i.e. select time source neighbors, then routes, many things will get complicated real quick, the first of which are synchronization loops.

Pouria

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: Monday, August 19, 2013 4:28 AM
To: 6TSCH

Pouria, all,

Thomas

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 20 Aug 2013 22:45:18 -0700

Pouria,
Glad to read we agree!
Thomas

On Tue, Aug 20, 2013 at 12:53 PM, <[email-masked]> wrote:

>  Thomas,****
>
> ** **
>
> Many thanks for your explanation.****
>
> ****
>
> I couldn’t find the related counter in MAC PIB of IEEE 802.15.4.****
>
> ** **
>
> My first idea was using both (a) clock accuracy information and (b) RPL
> rank information for choosing the best timing parent between two routers
> with equal (or close) RPL rank. That would help us to avoid (1)
> synchronization loop problem and (2) potential drifting problem caused by
> choosing the parent, between two with equal ranks but not equal clock
> accuracy.****
>
> ** **
>
> As you mentioned, let’s not make it complicated and consider the parent
> rank as a factor for choosing the timing parent.****
>
> ** **
>
> Pouria.****
>
>        ****
>
> ** **
>
> *Sent:* Tuesday, August 20, 2013 7:54 AM
>
> *To:* 6TSCH
> Pouria,****
> Thanks for the explanation. Allow me to answer inline.****
>
> Thomas****
>
> ** **
>
> On Mon, Aug 19, 2013 at 10:57 AM, <[email-masked]> wrote:****
>
> Thomas,****
>
>  ****
>
> crystals hardware. Am I right?****
>
> ** **
>
> re-synchronization frequency, or changing the guard time.****
>
> ** **
>
>   In the centralized approach, the System/Network managers, use (L2)
> to select the potential clock sources in the network. Am I right? ****
>
>  ** **
>
> time source neighbor selection process in that?****
>
>  ****
>
>   In a distributed approach, a network device might inform their
> neighbors about its (L2) clock accuracy. A new device might use this
> information, as well as L3 parameters (e.g. sender RPL’ rank), to choose
> its timing parent.****
>
>  ** **
>
> get complicated real quick, the first of which are synchronization loops.*
> ***
>
>  ****
>
>   If in 6tsch, we are considering the case that all the nodes in the
> for selecting timing parent.****
>
>  ****
>
>  I would go that route, but maybe you have some counter example in mind?**
> **
>
>  ****
>
>  Pouria****
>
>  ****
>
> *To:* 6TSCH****

---

From: <[email-masked]>
Date: Wed, 28 Aug 2013 11:55:26 +0000

Dear All,
I would like to continue our discussion for choosing the time source (either in L2 or L3) in the basic RPL.
I prepared a sample of message sequence chart to show the potential procedure for basic RPL.
I think we can refer to or modify the attached slide to discuss the details for constructing the basic RPL, as well as choosing the time source.
Best Wishes,
Pouria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, August 21, 2013 7:45 AM
To: 6TSCH
Subject: Re: [6tsch] RPL on Basic

Pouria,
Glad to read we agree!
Thomas

On Tue, Aug 20, 2013 at 12:53 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

Pouria.

To: 6TSCH

Pouria,

Pouria

Pouria, all,

Thomas

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Qin Wang <[email-masked]>
Date: Wed, 28 Aug 2013 23:31:21 +0800

Hi Pouria,

It is great to have the diagram as common base to discuss. I would like to
add "Changing time source" along with "Choosing the RPL parent", because
the time source selected at the beginning is just a temporary one, and time
source in L2 should be same as the RPL parent in L3 after RPL parent is
selected.

make sense?

Qin

On Wed, Aug 28, 2013 at 7:55 PM, <[email-masked]> wrote:

>  Dear All,****
>
> I would like to continue our discussion for choosing the time source
> (either in L2 or L3) in the basic RPL. ****
>
> I prepared a sample of message sequence chart to show the potential
> procedure for basic RPL.****
>
> I think we can refer to or modify the attached slide to discuss the
> details for constructing the basic RPL, as well as choosing the time source.
> ****
>
> Best Wishes,****
>
> Pouria  ****
>
> ****
>
> ** **
>
> ** **
>
> *Sent:* Wednesday, August 21, 2013 7:45 AM
>
> *To:* 6TSCH
> Glad to read we agree!****
>
> Thomas****
>
> ** **
>
> On Tue, Aug 20, 2013 at 12:53 PM, <[email-masked]> wrote:****
>
> Thomas,****
>
>  ****
>
> *Sent:* Tuesday, August 20, 2013 7:54 AM****
>
>
> *To:* 6TSCH

---

From: <[email-masked]>
Date: Wed, 28 Aug 2013 16:52:51 +0000

Hi Qin,
I changed the diagram based on your comment.
However, I couldn't conclude form the discussion on "time parent selection based on EB priority" thread to find out, if L3 will make the final decision about the time source or L2.
Best Wishes,
Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Wednesday, August 28, 2013 5:31 PM
To: Zand, P. (EWI)
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] RPL on Basic

Hi Pouria,

It is great to have the diagram as common base to discuss. I would like to add "Changing time source" along with "Choosing the RPL parent", because the time source selected at the beginning is just a temporary one, and time source in L2 should be same as the RPL parent in L3 after RPL parent is selected.

make sense?

Qin

On Wed, Aug 28, 2013 at 7:55 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear All,
I would like to continue our discussion for choosing the time source (either in L2 or L3) in the basic RPL.
I prepared a sample of message sequence chart to show the potential procedure for basic RPL.
I think we can refer to or modify the attached slide to discuss the details for constructing the basic RPL, as well as choosing the time source.
Best Wishes,
Pouria

To: 6TSCH

Pouria,
Glad to read we agree!
Thomas

Pouria.

To: 6TSCH

Pouria,

Pouria

Pouria, all,

Thomas

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Qin Wang <[email-masked]>
Date: Thu, 29 Aug 2013 01:20:48 +0800

Hi Pouria,

I proposed adding "Change time source" along with "Choosing the RPL parent"
because we agreed before that the RPL parent will be used as the time
source. And, this time Xavi proposed to use the node with lowest EB' join
priority as time source is just because the RPL parent hasn't been found at
the beginning.

Make sense?

Qin

On Thu, Aug 29, 2013 at 12:52 AM, <[email-masked]> wrote:

>  Hi Qin,****
>
> I changed the diagram based on your comment.****
>
> However, I couldn’t conclude form the discussion on “time parent selection
> based on EB priority” thread to find out, if L3 will make the final
> decision about the time source or L2.****
>
> Best Wishes,****
>
> Pouria****
>
> ****
>
> ** **
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* Wednesday, August 28, 2013 5:31 PM
> *To:* Zand, P. (EWI)
> selected.****
> make sense?****
> Qin****
> On Wed, Aug 28, 2013 at 7:55 PM, <[email-masked]> wrote:****
>
> Dear All,****
>
> *Sent:* Wednesday, August 21, 2013 7:45 AM****
>
>
> *To:* 6TSCH

---

From: <[email-masked]>
Date: Wed, 28 Aug 2013 18:14:21 +0000

Hi Qin,
It absolutely makes sense.
Best Wishes,
Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Wednesday, August 28, 2013 7:21 PM
To: Zand, P. (EWI)
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] RPL on Basic

Hi Pouria,

I proposed adding "Change time source" along with "Choosing the RPL parent" because we agreed before that the RPL parent will be used as the time source. And, this time Xavi proposed to use the node with lowest EB' join priority as time source is just because the RPL parent hasn't been found at the beginning.

Make sense?

Qin

On Thu, Aug 29, 2013 at 12:52 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,
I changed the diagram based on your comment.
However, I couldn't conclude form the discussion on "time parent selection based on EB priority" thread to find out, if L3 will make the final decision about the time source or L2.
Best Wishes,
Pouria

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 28, 2013 5:31 PM
To: Zand, P. (EWI)
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>

Hi Pouria,

make sense?

Qin

To: 6TSCH

Pouria,
Glad to read we agree!
Thomas

Pouria.

To: 6TSCH

Pouria,

Pouria

Pouria, all,

Thomas

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 28 Aug 2013 11:25:25 -0700

Pouria,

Wonderful diagram, great material to discuss over!

I don't quite understand the changes you made in the second revision. In my
mind, the first revision was better:
- node A initiates a network join procedure
- it receives some EBs
- after some settable time, it uses some settable algorithm to pick a time
source neighbor
- it keeps synchronized to that neighbor until told otherwise. No routing
information yet.
- either it sends in a DIS, or waits, but in any case it receives DIOs from
its neighbors
- RPL works exactly as-is, and pick routing parent(s).
- TSCH snoops on RPL's decision and changes time source neighbors
accordingly.

Does that sum it up?

Thomas

On Wed, Aug 28, 2013 at 11:14 AM, <[email-masked]> wrote:

>  Hi Qin,****
>
> It absolutely makes sense.****
>
> Best Wishes,****
>
> Pouria****
>
> ** **
>
> *Sent:* Wednesday, August 28, 2013 7:21 PM
>
> *To:* Zand, P. (EWI)
> I proposed adding "Change time source" along with "Choosing the RPL
> parent" because we agreed before that the RPL parent will be used as the
> time source. And, this time Xavi proposed to use the node with lowest EB'
> join priority as time source is just because the RPL parent hasn't been
> found at the beginning. ****
>
> ** **
>
> Make sense?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Thu, Aug 29, 2013 at 12:52 AM, <[email-masked]> wrote:****
>
> Hi Qin,****
>
> *Cc:* Thomas Watteyne; [email-masked]****
>
>

---

From: <[email-masked]>
Date: Wed, 28 Aug 2013 18:53:35 +0000

Thomas,
The changes are:

1.       Considering more time for 6top and MAC to discover more potential neighbor and update their statistic in neighbor table, before starting RPL.

2.       The RPL might consider the neighbor statistics in 6top as well as parent rank to select the parent. So, RPL will ask 6top about the local statistics in the neighbor table by calling "read statistic request".

3.        Changing the time source information in 6top and MAC, upon selecting the new parent.
I think you mean the first change. I am right?
I can remove that part.
Pouria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, August 28, 2013 8:25 PM
To: 6TSCH
Subject: Re: [6tsch] RPL on Basic

Pouria,

I don't quite understand the changes you made in the second revision. In my mind, the first revision was better:
- node A initiates a network join procedure
- it receives some EBs
- after some settable time, it uses some settable algorithm to pick a time source neighbor
- it keeps synchronized to that neighbor until told otherwise. No routing information yet.
- either it sends in a DIS, or waits, but in any case it receives DIOs from its neighbors
- RPL works exactly as-is, and pick routing parent(s).
- TSCH snoops on RPL's decision and changes time source neighbors accordingly.

Does that sum it up?

Thomas

On Wed, Aug 28, 2013 at 11:14 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,
It absolutely makes sense.
Best Wishes,
Pouria

To: Zand, P. (EWI)

Hi Pouria,

Make sense?

Qin

Hi Pouria,

make sense?

Qin

To: 6TSCH

Pouria,
Glad to read we agree!
Thomas

Pouria.

To: 6TSCH

Pouria,

Pouria

Pouria, all,

Thomas

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 29 Aug 2013 11:34:04 -0700

Pouria,

I see your points, which deal with neighbor discovery, right? IMO, there is
no problem to have both 6top and RPL add neighbors to the neighbor table.
In fact, one can consider the neighbor table to be some data source managed
jointly by L2 and L3. Some "columns" can be L2-specific (e.g. packet
counters), some L3-specific (e.g. rank).

To discover more neighbor, do you see an advantage of listening after
having synchronized, rather than listening longer at the beginning of the
join process?

Thomas

On Wed, Aug 28, 2013 at 11:53 AM, <[email-masked]> wrote:

>  Thomas,****
>
> The changes are:****
>
> **1.       **Considering more time for 6top and MAC to discover more
> potential neighbor and update their statistic in *neighbor table*, before
> starting RPL.****
>
> **2.       **The RPL might consider the neighbor statistics in 6top as
> well as parent rank to select the parent. So, RPL will ask 6top about the
> local statistics in the *neighbor table* by calling “read statistic
> request”.****
>
> **3.       ** Changing the time source information in 6top and MAC, upon
> selecting the new parent.****
>
> I think you mean the first change. I am right?****
>
> I can remove that part.****
>
> Pouria ****
>
> ** **
>
> *Sent:* Wednesday, August 28, 2013 8:25 PM
>
> *To:* 6TSCH
> Wonderful diagram, great material to discuss over!****
>
> ** **
>
> I don't quite understand the changes you made in the second revision. In
> my mind, the first revision was better:****
>
> - node A initiates a network join procedure****
>
> - it receives some EBs****
>
> source neighbor****
> information yet.****
> - either it sends in a DIS, or waits, but in any case it receives DIOs
> from its neighbors****
>
> - RPL works exactly as-is, and pick routing parent(s).****
>
> accordingly.****
> Does that sum it up?****
> On Wed, Aug 28, 2013 at 11:14 AM, <[email-masked]> wrote:****
>
> Hi Qin,****
>
> *Sent:* Wednesday, August 28, 2013 7:21 PM****
>
>
> *To:* Zand, P. (EWI)

---

From: <[email-masked]>
Date: Thu, 29 Aug 2013 19:25:34 +0000

Thomas,
Yes, I mean neighbor discovery.
"By listening longer at the beginning of the join process", Do you mean during the scanning procedure?  During scanning procedure, the node continuously keeps listening in each channel. Let's say 4 sec on each channel. My point is, how long it should keep listening (more than 4 sec?) in each channel to be sure that after scanning 16 channels (16 * 4 seconds), most of the neighbor are discovered. If we assume that the advertisement period is 2 seconds, by considering the channel hopping of the advertisers, what is the probability of discovering most of the neighbors during join process?
Am I missing anything?
Best Wishes,
Pouria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, August 29, 2013 8:34 PM
To: 6TSCH
Subject: Re: [6tsch] RPL on Basic

Pouria,

I see your points, which deal with neighbor discovery, right? IMO, there is no problem to have both 6top and RPL add neighbors to the neighbor table. In fact, one can consider the neighbor table to be some data source managed jointly by L2 and L3. Some "columns" can be L2-specific (e.g. packet counters), some L3-specific (e.g. rank).

To discover more neighbor, do you see an advantage of listening after having synchronized, rather than listening longer at the beginning of the join process?

Thomas

On Wed, Aug 28, 2013 at 11:53 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,
The changes are:

To: 6TSCH

Pouria,

Does that sum it up?

Thomas

To: Zand, P. (EWI)

Hi Pouria,

Make sense?

Qin

Hi Pouria,

make sense?

Qin

To: 6TSCH

Pouria,
Glad to read we agree!
Thomas

Pouria.

To: 6TSCH

Pouria,

Pouria

Pouria, all,

Thomas

Xavi, Pouria,

-raghuram

Good point :-)
agreed!
X

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Pouria

To: Zand, P. (EWI)

Hi Pouria,
answer inline:

Xavi,

Does it make sense?

Pouria

Pouria

Hi Pouria,

Best wishes,
Pouria

Hi Thomas and Xavi,

Thought?

Qin

Cheers,

Pascal

Hi Pascal,

Please see inline

[]
-RPL configuration:

Cheers;

Pascal

thanks!
X