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
[cid:image001.jpg@01CEA3F6.3D6E3C80]


From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] 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, <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>> 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.


From: 6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> [mailto:6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org>] On Behalf Of Thomas Watteyne
Sent: Tuesday, August 20, 2013 7:54 AM

To: 6TSCH
Subject: Re: [6tsch] RPL on Basic

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

On Mon, Aug 19, 2013 at 10:57 AM, <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>> 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?

Pouria

From: 6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> [mailto:6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org>] 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, <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>> 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:rsudhaak@cisco.com<mailto:rsudhaak@cisco.com>]
Sent: Wednesday, August 14, 2013 12:57 AM
To: xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>; Zand, P. (EWI)
Cc: Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>; Qin Wang

Subject: Re: [6tsch] RPL on Basic

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 <xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>>
Reply-To: <xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>>
Date: Tuesday, August 13, 2013 2:27 PM
To: Pouria Zand <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>>
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>>, "6tsch@ietf.org<mailto:6tsch@ietf.org>" <6tsch@ietf.org<mailto:6tsch@ietf.org>>, Qin Wang <qinwang@berkeley.edu<mailto:qinwang@berkeley.edu>>
Subject: Re: [6tsch] RPL on Basic

Good point :-)
agreed!
X

On Tue, Aug 13, 2013 at 2:20 PM, <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>> 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

From: Xavier Vilajosana Guillen [mailto:xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>]
Sent: Tuesday, August 13, 2013 11:13 PM

To: Zand, P. (EWI)
Cc: Qin Wang; Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>
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, <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>> 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


From: Xavier Vilajosana Guillen [mailto:xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>]
Sent: Tuesday, August 13, 2013 10:17 PM

To: Zand, P. (EWI)
Cc: Qin Wang; Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>
Subject: Re: [6tsch] RPL on Basic

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, <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>> 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


From: Xavier Vilajosana Guillen [mailto:xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>]
Sent: Tuesday, August 13, 2013 6:47 PM
To: Zand, P. (EWI)
Cc: Qin Wang; Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>

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, <P.Zand@utwente.nl<mailto:P.Zand@utwente.nl>> 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:6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> [mailto:6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org>] On Behalf Of Qin Wang
Sent: Tuesday, August 13, 2013 3:19 PM
To: Thomas Watteyne
Cc: 6tsch@ietf.org<mailto:6tsch@ietf.org>

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 <watteyne@eecs.berkeley.edu<mailto:watteyne@eecs.berkeley.edu>> 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) <pthubert@cisco.com<mailto:pthubert@cisco.com>> 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:xvilajosana@eecs.berkeley.edu<mailto:xvilajosana@eecs.berkeley.edu>]
Sent: lundi 12 août 2013 20:38
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; 6tsch@ietf.org<mailto:6tsch@ietf.org>
Subject: Re: [6tsch] RPL on Basic

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) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
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
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch


_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch


_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch