Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 1 Feb 2013 20:07:16 +0000

FYI

IEEE 802.1aq was published last year.  It uses IS-IS as the control plane
for bridging, instead of spanning tree.  It can run as a software upgrade,
using the same old data plane that worked with spanning tree protocols, or
along with the MAC-in-MAC (802.1ah) encapsulation if you need better
address and VLAN scaling.  It's been in multivendor interoperability demos
for quite a long time.

-- Norm

-----Original Message-----
From: Michael Richardson <[email-masked]>
Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

>3) In the ethernet world, I point to STP and its variants as layer-2
>   attempts to do routing, which failed.  Well, it does what it was
>   advertised to do (detect and disable loops), but it turns out that
>   we need much more than that.
>   People have gone to layer-3 solutions like OSPF instead, because it
>   provides diagnostics, works across vendors, and it responds much
>   faster. And we also have TRILL.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Feb 2013 19:49:39 -0500

>>>>> "Kris" == Kris Pister <[email-masked]> writes:
    Kris> like a requirement in any case.  One of the big benefits of
    Kris> tsch is the availability of a shared sense of time across the
    Kris> network.  This has important benefits to applications
    Kris> (sequence of events detection, feedback control, global
    Kris> timestamps, ...) as well as security (replay, joining,
    Kris> broadcast authentication), and others.  So for sure we need a
    Kris> mechanism where network time can be exposed to higher layers.

I agree.  
While it seems like a local implementation issue, I think that for RPL
to do something with it, the units, scales, etc. of this needs to be
standardized. 

    Kris> We also need a mechanism to expose the schedule, because for
    Kris> many applications the higher layer is going to want to do
    Kris> something in relation to radio slot activity.  For example,
    Kris> schedule a radar tank measurement at a time when there is no
    Kris> mote radio activity, or take a data sample right before a TX
    Kris> link to maximize freshness.

    Kris> How RPL or some other protocol makes use of these features is
    Kris> probably a long and polarizing discussion.  If possible I'd
    Kris> like to define the mechanism for access to the information,
    Kris> but defer the details of policy for future IDs.

Let's start by describing the information that is available, and then we
can figure out what RPL can do with it.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Robert Assimiti <[email-masked]>
Date: Wed, 6 Feb 2013 17:18:57 -0500

Thomas,

The mechanism(s) used for time synchronization is something that we might have to reconcile with RPL discovery and maintenance traffic.

Time synchronization in TSCH is based on three mechanisms:

1.      Enhanced beacons

2.      Enhanced ACKs

3.      Frame based synchronization

If a node communicates intermittently (sleepy, battery operated) it can also proactively ping its time source and receive time stamps.

In order to maximize battery life and network throughput, it is advisable that RPL ICMP discovery and maintenance traffic (governed by the trickle timer) be somehow coordinated with the transmission of time synch packets (especially with enhanced beacons).

This could be a function of the shim layer or it could be deferred to the device management entity. Any suggestions, ideas on this topic?

Thks

Robert Assimiti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, January 31, 2013 8:50 PM
To: IETF 6TSCH
Subject: Re: [6tsch] Exposing network time (etc) to higher layers.

Agreed. TSCH is built to compensate for clock drift by using all (incl. data) packets to re-synchronize, and send keep-alive packets when not enough data packets are sent to satisfy a "good enough" synchronization. You can get the motes in your network synchronized within 10's of us. In fact, the better synchronized, the less long you have to listen for a packet (since you always have to listen early in case your neighbor mote drifted), so tight synchronization is a power *benefit*, not a power cost.

As pointed out by Kris, this becomes really interesting for the application to timestamp its payload. Are you thinking of any particular use of tight synchronization by the routing layer?

On Thu, Jan 31, 2013 at 4:28 PM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Motes keep aligned with guard times smaller than 1ms, also motes share the global ASN, with that in mind, would not be difficult to expose network time. Time accuracy might then depended on the energy constraints of the networks. As more tight synchronization more packets on the air.

X.

On 31/01/13 16:23, Nick Moore wrote:
On 01/02/13 10:29, Kris Pister wrote:
So for sure we need a mechanism where network time can be exposed to higher layers.

Hey, that's a really interesting thought, especially given the drifty nature of mote clocks.

-----Nick

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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 6 Feb 2013 15:37:31 -0800

Robert,

I agree that we need to reconcile sync and routing. Since TSCH does not
define who a mote's time source neighbor should be, and since RPL doesn't
either, the 6tsch layer would I believe be the right location. I avoid the
term "shim" since it sounds as "super-thin-does-very-little".

TSCH defined the concept of time source neighbor, and RPL of routing
parent. These could be made the same, especially since TSCH allows for
motes to have multiple time source parents. Moreover, in a multi-hop
setting, we don't want to end up with synchronization loops, so a (RPL) DAG
organization looks like the right one. Finally, RPL will cause data traffic
to flow from a mote to its routing parent(s), if that routing parent is
also a TSCH time source neighbor, this means that the mote will be tightly
sync'ed "for free" when data is flowing.

Do you have any thoughts on why tying TSCH time source neighbors to RPL
routing parents would not be a good idea? Given that a TSCH topology is
relatively stable due to the channel hopping nature of communication, I
would imagine that routing churn to relatively low, and so changes in
routing/sync parents infrequent.

Just to clarify some terminology: the Enhanced Beacon (EB) you refer to, is
the one used to advertise the presence of the network, and which contain
lots of IEs describing the network (channel hopping, timeslot info,
link/slotframe info, etc) described in 5.1.2.6? I agree that this role is
similar in nature to the "periodic" DIOs being sent by RPL. Are you toying
with the idea of putting the DIO payload after the EB IEs? The standard
might be flexible enough to allow the 6tsch layer to just send that up the
stack as if they were regular data packets.

Could we do some back-of-the-envelope calculation to determine how much
this would give us? Do you have a rough list of what periodic traffic is
being sent by a full-featured RPL, and how many packets/s that represents?

Thomas

On Wed, Feb 6, 2013 at 2:18 PM, Robert Assimiti
<[email-masked]>wrote:

> Thomas,****
>
> ** **
>
> The mechanism(s) used for time synchronization is something that we might
> have to reconcile with RPL discovery and maintenance traffic. ****
>
> ** **
>
> Time synchronization in TSCH is based on three mechanisms:****
>
> **1.      **Enhanced beacons ****
>
> **2.      **Enhanced ACKs****
>
> **3.      **Frame based synchronization ****
>
> ** **
>
> If a node communicates intermittently (sleepy, battery operated) it can
> also proactively ping its time source and receive time stamps.****
>
> ** **
>
> In order to maximize battery life and network throughput, it is advisable
> that RPL ICMP discovery and maintenance traffic (governed by the trickle
> timer) be somehow coordinated with the transmission of time synch packets
> (especially with enhanced beacons). ****
>
> ** **
>
> This could be a function of the shim layer or it could be deferred to the
> device management entity. Any suggestions, ideas on this topic?****
>
> ** **
>
> Thks****
>
> ** **
>
> *Robert Assimiti*
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Thursday, January 31, 2013 8:50 PM
> *To:* IETF 6TSCH
> *Subject:* Re: [6tsch] Exposing network time (etc) to higher layers.****
>
> ** **
>
> Agreed. TSCH is built to compensate for clock drift by using all (incl.
> data) packets to re-synchronize, and send keep-alive packets when not
> enough data packets are sent to satisfy a "good enough" synchronization.
> You can get the motes in your network synchronized within 10's of us. In
> fact, the better synchronized, the less long you have to listen for a
> packet (since you always have to listen early in case your neighbor mote
> drifted), so tight synchronization is a power *benefit*, not a power cost.
> ****
>
> ** **
>
> As pointed out by Kris, this becomes really interesting for the
> application to timestamp its payload. Are you thinking of any particular
> use of tight synchronization by the routing layer?****
>
> ** **
>
> On Thu, Jan 31, 2013 at 4:28 PM, Xavier Vilajosana <
> [email-masked]> wrote:****
>
> Motes keep aligned with guard times smaller than 1ms, also motes share the
> global ASN, with that in mind, would not be difficult to expose network
> time. Time accuracy might then depended on the energy constraints of the
> networks. As more tight synchronization more packets on the air.
>
> X.****
>
>
>
>
> On 31/01/13 16:23, Nick Moore wrote:****
>
> On 01/02/13 10:29, Kris Pister wrote:****
>
> So for sure we need a mechanism where network time can be exposed to
> higher layers.****
>
>
> -----Nick****
> ** **
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> [email-masked]

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 06 Feb 2013 15:41:29 -0800

I agree on that, would be feasible to use the EB to send DIO, in fact 
seems natural to join the network and get the routing information..

On 06/02/13 15:37, Thomas Watteyne wrote:
>  Are you toying with the idea of putting the DIO payload after the EB 
> IEs? The standard might be flexible enough to allow the 6tsch layer to 
> just send that up the stack as if they were regular data packets.

---

From: [email-masked]
Date: Wed, 6 Feb 2013 16:22:43 -0800

I agree that we can send DIO with EB.

I think there are two ways to do it. One is send-on-demand, i.e. RPL
generates DIO, give it to 6TSCH, and then 6TSCH broadcasts it in EB;
Another way is always-send, i.e. every EB will include DIO. Which one more
makes sense?

Qin

---

From: Robert Assimiti <[email-masked]>
Date: Fri, 8 Feb 2013 11:50:04 -0500

Thomas,

I believe that tying the TSCH time source to the RPL is an excellent idea. This is exactly what we do in our current system and believe you me, it saved us a lot of aspirin and Tylenol (or whatever headache medicine you prefer).

Let me suggest the following flow:

1.      Device starts going through discovery and it build a table of neighbors

2.      Device chooses a MAC coordinator from the table of neighbors (criteria based on which is outside the scope of this discussion)

3.      RPL above does the same in parallel (DIOs). Once RPL chooses a parent it would ensure that the MAC layer uses the parent as the coordinator.

As for the enhanced beacons they are a MAC mechanism and in my ever to be humbled they should only ever include IEs (channel hopping, slot, link, etc) and no DIO (or RPL discovery related) since that would be a clear layer violation. But the EBs could be coordinated (within the device) with DIO (or other RPL maintenance or discovery) traffic.

Robert Assimiti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, February 06, 2013 6:38 PM
To: Robert Assimiti
Cc: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Robert,

I agree that we need to reconcile sync and routing. Since TSCH does not define who a mote's time source neighbor should be, and since RPL doesn't either, the 6tsch layer would I believe be the right location. I avoid the term "shim" since it sounds as "super-thin-does-very-little".

TSCH defined the concept of time source neighbor, and RPL of routing parent. These could be made the same, especially since TSCH allows for motes to have multiple time source parents. Moreover, in a multi-hop setting, we don't want to end up with synchronization loops, so a (RPL) DAG organization looks like the right one. Finally, RPL will cause data traffic to flow from a mote to its routing parent(s), if that routing parent is also a TSCH time source neighbor, this means that the mote will be tightly sync'ed "for free" when data is flowing.

Do you have any thoughts on why tying TSCH time source neighbors to RPL routing parents would not be a good idea? Given that a TSCH topology is relatively stable due to the channel hopping nature of communication, I would imagine that routing churn to relatively low, and so changes in routing/sync parents infrequent.

Just to clarify some terminology: the Enhanced Beacon (EB) you refer to, is the one used to advertise the presence of the network, and which contain lots of IEs describing the network (channel hopping, timeslot info, link/slotframe info, etc) described in 5.1.2.6? I agree that this role is similar in nature to the "periodic" DIOs being sent by RPL. Are you toying with the idea of putting the DIO payload after the EB IEs? The standard might be flexible enough to allow the 6tsch layer to just send that up the stack as if they were regular data packets.

Could we do some back-of-the-envelope calculation to determine how much this would give us? Do you have a rough list of what periodic traffic is being sent by a full-featured RPL, and how many packets/s that represents?

Thomas
On Wed, Feb 6, 2013 at 2:18 PM, Robert Assimiti <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

1.      Enhanced beacons

2.      Enhanced ACKs

Thks

Robert Assimiti

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: Thursday, January 31, 2013 8:50 PM
To: IETF 6TSCH
Subject: Re: [6tsch] Exposing network time (etc) to higher layers.

X.

-----Nick

---

From: Robert Assimiti <[email-masked]>
Date: Fri, 8 Feb 2013 11:57:26 -0500

Thomas,

Just to clarify what I meant was:

"I believe that tying the TSCH MAC coordinator (typically also the time source) to the RPL parent is an excellent idea.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Assimiti
Sent: Friday, February 08, 2013 11:50 AM
To: Thomas Watteyne
Cc: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Thomas,

Robert Assimiti

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, February 06, 2013 6:38 PM
To: Robert Assimiti
Cc: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Robert,

Thomas

1.      Enhanced beacons

2.      Enhanced ACKs

Thks

Robert Assimiti

X.

-----Nick

---

From: Pascal Thubert <[email-masked]>
Date: Fri, 8 Feb 2013 21:29:01 +0100

Hello Robert and Thomas,

I think that if we agree on that key design point early in the process, we ll save an awful lot of energy later...

I certainly agree with the concept pf tying the mac coordonator with RPL parent.

And thé I m wondering about the benefits / consequences of triggering DIO/ DAO just because we need to resync time in the absence of traffic. In one hand that looks like an awful layer violation. Otoh that looks like an opportunity to check routes in the absence of traffic, considering that with rpl traffic validates the routes in an other fashion.

Sendind DIOs a bit earlier or a bit more does not hurt considering that it is still quite sparse.

Question though: is there risk of synchronization of the RPL control because an external functionality -sync- would require the emission ahead of desired schedule? 

Cheers,

Pascal

Le 8 févr. 2013 à 17:57, Robert Assimiti <[email-masked]> a écrit :

> “I believe that tying the TSCH MAC coordinator (typically also the time source) to the RPL parent is an excellent idea.
>  
> On Wed, Feb 6, 2013 at 2:18 PM, Robert Assimiti <[email-masked]> wrote:
> Thomas,
>  
> On Thu, Jan 31, 2013 at 4:28 PM, Xavier Vilajosana <[email-masked]> wrote:

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 10 Feb 2013 13:15:36 -0800

Robert,
Thanks for the clarification, this makes perfect sense.
Thomas

On Fri, Feb 8, 2013 at 8:57 AM, Robert Assimiti
<[email-masked]>wrote:

> Thomas,****
>
> ** **
>
> Just to clarify what I meant was:****
>
> ** **
>
> “I believe that tying the TSCH *MAC coordinator (typically also the time
> source)* to the RPL *parent *is an excellent idea.****
>
> ** **
>
> Of *Robert Assimiti
> *Sent:* Friday, February 08, 2013 11:50 AM
> *To:* Thomas Watteyne
>
> *Cc:* IETF 6TSCH
> *Subject:* Re: [6tsch] Time synchs and RPL discovery/maintenance traffic**
> **
>
> ** **
>
> Thomas,****
>
> ** **
>
> I believe that tying the TSCH time source to the RPL is an excellent idea.
> This is exactly what we do in our current system and believe you me, it
> saved us a lot of aspirin and Tylenol (or whatever headache medicine you
> prefer).****
>
> ** **
>
> Let me suggest the following flow:****
>
> **1.      **Device starts going through discovery and it build a table of
> neighbors****
>
> **2.      **Device chooses a MAC coordinator from the table of neighbors
> (criteria based on which is outside the scope of this discussion)****
>
> **3.      **RPL above does the same in parallel (DIOs). Once RPL chooses
> a parent it would ensure that the MAC layer uses the parent as the
> coordinator.****
>
> ** **
>
> As for the enhanced beacons they are a MAC mechanism and in my ever to be
> humbled they should only ever include IEs (channel hopping, slot, link,
> etc) and no DIO (or RPL discovery related) since that would be a clear
> layer violation. But the EBs could be coordinated (within the device) with
> DIO (or other RPL maintenance or discovery) traffic.  ****
>
> ** **
>
> *Robert Assimiti*
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Thomas Watteyne
> *Sent:* Wednesday, February 06, 2013 6:38 PM
> *To:* Robert Assimiti
> *Cc:* IETF 6TSCH
> *Subject:* Re: [6tsch] Time synchs and RPL discovery/maintenance traffic**
> **
>
> ** **
>
> Robert,****
>
> ** **
>
> term "shim" since it sounds as "super-thin-does-very-little".****
>
> ** **
>
> sync'ed "for free" when data is flowing.****
>
> ** **
>
> routing/sync parents infrequent.****
>
> ** **
>
> Just to clarify some terminology: the Enhanced Beacon (EB) you refer to,
> is the one used to advertise the presence of the network, and which contain
> stack as if they were regular data packets.****
>
> ** **
>
> Thomas****
> On Wed, Feb 6, 2013 at 2:18 PM, Robert Assimiti <[email-masked]>
> wrote:****
>
> Thomas,****
>
>  ****
>
> 1.      Enhanced beacons ****
> 2.      Enhanced ACKs****
> 3.      Frame based synchronization ****
>
>  ****
>
> *Robert Assimiti*****

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 10 Feb 2013 13:29:16 -0800

Pascal, Robert,

I believe we all feel a bit uneasy at the prospect of merging MAC layer EB
with RPL DIO.

Here are some thoughts about energy gains:
- TSCH EB are used just to advertise the presence of a network, and can be
sent at an arbitrary low rate, unless (as pointed out by Robert) you rely
on them for synchronization. EBs are broadcast, and therefore would make a
good candidate for "DIO overloading".
- TSCH packets used solely to resync are sent from a mote to its time
source neighbors when it hasn't heard from it in a while (duration
determined by drift rate and guard time). Yet, these are sent unicast,
possibly in dedicated slots, so I don't believe these packets make good
candidates for DIO overloading.
- the transmission of RPL DIO packets are governed by a trickle timer, and
it's my understanding that the period between two DIOs can become large
(tens of minutes?).

Given the potential large period between DIO packets, the energy gains
could not be that significant.

Yet I believe the real advantage would be that a new mote could pick the
mote to join based also on routing information. A mote would therefore
attach to the already formed network to a mote which has a big chance of
becoming its routing parent, putting less stress on the joining process.

So, to answer Pascal's question, I believe there is no risk in terms of
synchronization, since mote can stay synchronized only by sending period
resync packet to time parents (unicast).

Thomas

On Fri, Feb 8, 2013 at 12:29 PM, Pascal Thubert <[email-masked]>wrote:

> And thé I m wondering about the benefits / consequences of triggering DIO/
> DAO just because we need to resync time in the absence of traffic. In one
> hand that looks like an awful layer violation. Otoh that looks like an
> opportunity to check routes in the absence of traffic, considering that
> with rpl traffic validates the routes in an other fashion.
>
> Question though: is there risk of synchronization of the RPL control
> because an external functionality -sync- would require the emission ahead
> of desired schedule?
>
> Cheers,
>
> Pascal
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Robert Assimiti
> 1.      Device starts going through discovery and it build a table of
> neighbors****
>
> 2.      Device chooses a MAC coordinator from the table of neighbors
> 3.      RPL above does the same in parallel (DIOs). Once RPL chooses a
> parent it would ensure that the MAC layer uses the parent as the
> coordinator.****
>
> ** **
>

---

From: [email-masked]
Date: Sun, 10 Feb 2013 15:19:43 -0800

Thomas, Pascal

When we talk about synchronization in TSCH, we refer to the two clocks at
a pair of motes, because they are talking to each other on TDMA-based MAC.

However, according to my understanding, the synchronization in RPL is
associated to some counter and globalized.

Thus, I wonder if the synchronization from RPL point of view is as same as
the synchronization in TSCH. If not, what is the relationship between
them?

Thanks
Qin

>> I think that if we agree on that key design point early in the process,
>> we
>> ll save an awful lot of energy later...
>>
>> Sendind DIOs a bit earlier or a bit more does not hurt considering that
>> it
>> is still quite sparse.
>>
>> *From:* [email-masked]
>> [mailto:[email-masked]<[email-masked]>]
>> *From:* [email-masked]
>> [mailto:[email-masked]<[email-masked]>]
>> <[email-masked]>
>> wrote:****
>>
>> Thomas,****
>>
>>  ****
>>

---

From: [email-masked]
Date: Sun, 10 Feb 2013 15:19:45 -0800

Thomas, Pascal

Thanks
Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 10 Feb 2013 15:55:16 -0800

Qin,

I'm not sure I understand what you mean by RPL synchronization. I don't
believe RPL assumes nodes are synchronized at all. RPL is a routing
protocol, and synchronization is a layer 2 concept which is pretty much
orthogonal to the routing layer. That being said, RPL does contain some
counters to ensure freshness of the routing information; maybe that's what
you mean by synchronization?

Independent from synchronization, both TSCH and RPL can periodically
broadcast information (EBs in TSCH, DIOs in RPL). I believe this thread
discusses whether it makes sense/it is allowed to combine some of that info.

Please let me know if this helps clarifying what is being discussed.
Thomas

---

From: Xavier Vilajosana <[email-masked]>
Date: Sun, 10 Feb 2013 15:58:24 -0800

Hi Qin,

from RFC6550 section 7.1 Sequence Counter Overview
details that RPL uses a counter to be able to determine the freshness of 
the information, synchronization means that nodes are updated with the 
latest DIO information and have a "recent" state of the network.

hope this helps :-)

X

On 10/02/13 15:55, Thomas Watteyne wrote:
> Qin,
>
> I'm not sure I understand what you mean by RPL synchronization. I 
> don't believe RPL assumes nodes are synchronized at all. RPL is a 
> routing protocol, and synchronization is a layer 2 concept which is 
> pretty much orthogonal to the routing layer. That being said, RPL does 
> contain some counters to ensure freshness of the routing information; 
> maybe that's what you mean by synchronization?
>
> broadcast information (EBs in TSCH, DIOs in RPL). I believe this 
> thread discusses whether it makes sense/it is allowed to combine some 
> of that info.
>
> On Sun, Feb 10, 2013 at 3:19 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Thomas, Pascal
>
>     > On Fri, Feb 8, 2013 at 12:29 PM, Pascal Thubert
>     > <[email-masked] <mailto:[email-masked]>>wrote:
>     >
>     >> Hello Robert and Thomas,
>     >>
>     >> I certainly agree with the concept pf tying the mac coordonator
>     with RPL
>     >> parent.
>     >>
>     >> And thé I m wondering about the benefits / consequences of
>     triggering
>     >> DIO/
>     >> DAO just because we need to resync time in the absence of
>     traffic. In
>     >> one
>     >> Le 8 févr. 2013 à 17:57, Robert Assimiti
>     <[email-masked] <mailto:[email-masked]>> a
>     >> écrit :
>     >>
>     >> Thomas,****
>     >>
>     >> ** **
>     >>
>     >> "I believe that tying the TSCH *MAC coordinator (typically also
>     the time
>     >> *From:* [email-masked] <mailto:[email-masked]>
>     >> [mailto:[email-masked]
>     <mailto:[email-masked]><[email-masked]
>     <mailto:[email-masked]>>]
>     >> I believe that tying the TSCH time source to the RPL is an
>     excellent
>     >> idea.
>     >> As for the enhanced beacons they are a MAC mechanism and in my
>     ever to
>     >> be
>     >> layer violation. But the EBs could be coordinated (within the
>     device)
>     >> with
>     >> *From:* [email-masked] <mailto:[email-masked]>
>     >> [mailto:[email-masked]
>     <mailto:[email-masked]><[email-masked]
>     <mailto:[email-masked]>>]
>     >> either, the 6tsch layer would I believe be the right location.
>     I avoid
>     >> the
>     >> setting, we don't want to end up with synchronization loops, so
>     a (RPL)
>     >> DAG
>     >> link/slotframe info, etc) described in 5.1.2.6? I agree that
>     this role
>     >> is
>     >> might be flexible enough to allow the 6tsch layer to just send
>     that up
>     >> the
>     >> <[email-masked] <mailto:[email-masked]>>
>     >> wrote:****
>     >>
>     >> Thomas,****
>     >>
>     >>  ****
>     >>
>     >> This could be a function of the shim layer or it could be
>     deferred to
>     >> the
>     >> *From:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     >> Behalf
>     >> Of *Thomas Watteyne
>     >> drifted), so tight synchronization is a power *benefit*, not a
>     power
>     >> cost.
>     >> ****
>     >>
>     >>  ****
>     >>
>     >> [email-masked]
>     <mailto:[email-masked]>> wrote:****
>     >>
>     >> Motes keep aligned with guard times smaller than 1ms, also
>     motes share
>     >> the
>     >> Hey, that's a really interesting thought, especially given the
>     drifty
>     >> nature of mote clocks.
>     >>
>     >> -----Nick****
>     >>
>     >>  ****
>     >>
>     >> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Sun, 10 Feb 2013 16:06:28 -0800

Thomas,

I understand what you explained as follows. Actually, my question came
from the following emails by you and Pascal.

>> > resync packet to time parents (unicast).

I'm confused by the "synchronization" in above two paragraphs. Maybe I
missed something.

Thanks
Qin

>> > I believe we all feel a bit uneasy at the prospect of merging MAC
>> layer
>> EB
>> > with RPL DIO.
>> >
>> > - TSCH EB are used just to advertise the presence of a network, and
>> can
>> be
>> > on them for synchronization. EBs are broadcast, and therefore would
>> make
>> a
>> > <[email-masked]>wrote:
>> >
>> >> Hello Robert and Thomas,
>> >>
>> >> I certainly agree with the concept pf tying the mac coordonator with
>> RPL
>> >> parent.
>> >>
>> >> Le 8 févr. 2013 à 17:57, Robert Assimiti <[email-masked]>
>> a
>> >> écrit :
>> >>
>> >> Thomas,****
>> >>
>> >> ** **
>> >>
>> >> As for the enhanced beacons they are a MAC mechanism and in my ever
>> to
>> >> be
>> >> either, the 6tsch layer would I believe be the right location. I
>> avoid
>> >> the
>> >> setting, we don't want to end up with synchronization loops, so a
>> (RPL)
>> >> DAG
>> >> link/slotframe info, etc) described in 5.1.2.6? I agree that this
>> role
>> >> is
>> >> might be flexible enough to allow the 6tsch layer to just send that
>> up
>> >> the
>> >> Motes keep aligned with guard times smaller than 1ms, also motes
>> share
>> >> the

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 10 Feb 2013 16:35:12 -0800

Qin,

Thanks for the follow-up.

I read Pascal's question as: "if we link the transmission of RPL DIO to
TSCH EBs, is there a chance that the TSCH network looses synchronization
because some RPL timing changes".

My reply is: no, since motes resync primarily by sending unicast frames to
time source neighbor, which are not related to the EBs.

Thomas

---

From: [email-masked]
Date: Sun, 10 Feb 2013 16:55:52 -0800

Thomas,

Thanks a lot.

Qin

>> >> >> because an external functionality -sync- would require the
>> emission
>> >> >> ahead
>> >> >> of desired schedule?
>>
>> And then you response:
>> >> > So, to answer Pascal's question, I believe there is no risk in
>> terms
>> of
>> don't
>> thread
>> >> When we talk about synchronization in TSCH, we refer to the two
>> clocks
>> >> at
>> >> Thus, I wonder if the synchronization from RPL point of view is as
>> same
>> >> as
>> >> > sent at an arbitrary low rate, unless (as pointed out by Robert)
>> you
>> >> rely
>> >> > - the transmission of RPL DIO packets are governed by a trickle
>> timer,
>> >> and
>> >> > Yet I believe the real advantage would be that a new mote could
>> pick
>> >> the
>> >> > attach to the already formed network to a mote which has a big
>> chance
>> >> of
>> >> > So, to answer Pascal's question, I believe there is no risk in
>> terms
>> >> of
>> >> >> DAO just because we need to resync time in the absence of traffic.
>> In
>> >> >> one
>> >> >> hand that looks like an awful layer violation. Otoh that looks
>> like
>> >> an
>> >> >> because an external functionality -sync- would require the
>> emission
>> >> >> ahead
>> >> >> of desired schedule?
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Pascal
>> >> >>
>> >> >> “I believe that tying the TSCH *MAC coordinator (typically also
>> the
>> >> time
>> >> >> This is exactly what we do in our current system and believe you
>> me,
>> >> it
>> >> >> saved us a lot of aspirin and Tylenol (or whatever headache
>> medicine
>> >> you
>> >> >> prefer).****
>> >> >>
>> >> >> ** **
>> >> >>
>> >> >> 3.      RPL above does the same in parallel (DIOs). Once RPL
>> chooses
>> >> a
>> ever
>> >> >> I agree that we need to reconcile sync and routing. Since TSCH
>> does
>> >> not
>> >> >> organization looks like the right one. Finally, RPL will cause
>> data
>> >> >> traffic
>> >> >> to flow from a mote to its routing parent(s), if that routing
>> parent
>> >> is
>> >> >> Do you have any thoughts on why tying TSCH time source neighbors
>> to
>> >> RPL
>> >> >> routing parents would not be a good idea? Given that a TSCH
>> topology
>> >> is
>> >> >> relatively stable due to the channel hopping nature of
>> communication,
>> >> I
>> >> >> Just to clarify some terminology: the Enhanced Beacon (EB) you
>> refer
>> >> to,
>> >> >> is the one used to advertise the presence of the network, and
>> which
>> >> >> contain
>> >> >> similar in nature to the "periodic" DIOs being sent by RPL. Are
>> you
>> >> >> toying
>> that
>> >> >> this would give us? Do you have a rough list of what periodic
>> traffic
>> >> is
>> >> >> The mechanism(s) used for time synchronization is something that
>> we
>> >> >> might
>> >> >> If a node communicates intermittently (sleepy, battery operated)
>> it
>> >> can
>> >> >> This could be a function of the shim layer or it could be deferred
>> to
>> >> >> the
>> >> >> You can get the motes in your network synchronized within 10's of
>> us.
>> >> In
>> >> >> packet (since you always have to listen early in case your
>> neighbor
>> >> mote
>> >> >> time. Time accuracy might then depended on the energy constraints
>> of
>> >> the

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 12 Feb 2013 13:22:13 +0000

My fault; I was writing late from a smartphone and that's damn inefficient.

My trouble is this:

We normally want to avoid mixing constraints from different layers, which would be the case if we emit a DIO just because we want to resync a clock. OTOH, there are benefits in sending more DIOs when bandwidth/energy is consumed anyway.

I was thinking that the need for a resync of clocks somewhere might be 'synchronized' with the need ro resync elsewhere. And if that cause to fire DIOs then the DIOs are synchronized. I thought that such an effect is really unwanted.

In general, routing protocols implements randoms in their timers to avoid synchronization effects.
RPL has the Trickle timer that will delay DIOs. As such, we cannot expect that the need to resync can immediately fire a DIO.
It would probably reset the trickle timer to force a DIO very soon. Will that be soon enough?

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: lundi 11 février 2013 00:55
To: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Qin,

I'm not sure I understand what you mean by RPL synchronization. I don't believe RPL assumes nodes are synchronized at all. RPL is a routing protocol, and synchronization is a layer 2 concept which is pretty much orthogonal to the routing layer. That being said, RPL does contain some counters to ensure freshness of the routing information; maybe that's what you mean by synchronization?

Independent from synchronization, both TSCH and RPL can periodically broadcast information (EBs in TSCH, DIOs in RPL). I believe this thread discusses whether it makes sense/it is allowed to combine some of that info.

Please let me know if this helps clarifying what is being discussed.
Thomas
On Sun, Feb 10, 2013 at 3:19 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Thomas, Pascal

Thanks
Qin

> <[email-masked]<mailto:[email-masked]>>wrote:
>
>> Hello Robert and Thomas,
>>
>> Le 8 févr. 2013 à 17:57, Robert Assimiti <[email-masked]<mailto:[email-masked]>> a
>> écrit :
>>
>> Thomas,****
>>
>> ** **
>>
>> "I believe that tying the TSCH *MAC coordinator (typically also the time
>> *From:* [email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>]
>> *From:* [email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]<mailto:[email-masked]><[email-masked]<mailto:[email-masked]>>]
>> <[email-masked]<mailto:[email-masked]>>
>> wrote:****
>>
>> Thomas,****
>>
>>  ****
>>
>> *From:* [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] *On
>> Behalf
>> Of *Thomas Watteyne
>> [email-masked]<mailto:[email-masked]>> wrote:****
>>

---

From: Robert Assimiti <[email-masked]>
Date: Tue, 12 Feb 2013 10:41:43 -0500

Thomas,

Merging the MAC layer EB with the RPL DIO does feel somewhat wrong.

As you pointed out, EBs are the perfect candidate for DIO overloading due to the fact that they are broadcasted. Relying on EBs for time synchs does in my opinion optimize both throughput and battery power. A MAC coordinator could (and often is) the time source for several motes. These motes can all be synched with on periodic broadcast EB transmission as opposed to individual unicasts.
As Pascal pointed out, sending DIOs earlier and more frequent could not hurt.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Sunday, February 10, 2013 4:29 PM
To: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Pascal, Robert,

I believe we all feel a bit uneasy at the prospect of merging MAC layer EB with RPL DIO.

Here are some thoughts about energy gains:
- TSCH EB are used just to advertise the presence of a network, and can be sent at an arbitrary low rate, unless (as pointed out by Robert) you rely on them for synchronization. EBs are broadcast, and therefore would make a good candidate for "DIO overloading".
- TSCH packets used solely to resync are sent from a mote to its time source neighbors when it hasn't heard from it in a while (duration determined by drift rate and guard time). Yet, these are sent unicast, possibly in dedicated slots, so I don't believe these packets make good candidates for DIO overloading.
- the transmission of RPL DIO packets are governed by a trickle timer, and it's my understanding that the period between two DIOs can become large (tens of minutes?).

Given the potential large period between DIO packets, the energy gains could not be that significant.

Yet I believe the real advantage would be that a new mote could pick the mote to join based also on routing information. A mote would therefore attach to the already formed network to a mote which has a big chance of becoming its routing parent, putting less stress on the joining process.

So, to answer Pascal's question, I believe there is no risk in terms of synchronization, since mote can stay synchronized only by sending period resync packet to time parents (unicast).

Thomas

On Fri, Feb 8, 2013 at 12:29 PM, Pascal Thubert <[email-masked]<mailto:[email-masked]>> wrote:
Hello Robert and Thomas,

Cheers,

Pascal

Le 8 févr. 2013 à 17:57, Robert Assimiti <[email-masked]<mailto:[email-masked]>> a écrit :
Thomas,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Robert Assimiti
Sent: Friday, February 08, 2013 11:50 AM
To: Thomas Watteyne
Cc: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Thomas,

Robert Assimiti

Robert,

Thomas

1.      Enhanced beacons

2.      Enhanced ACKs

Thks

Robert Assimiti

X.

-----Nick

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Tue, 12 Feb 2013 16:11:15 +0000

Hello Thomas, Robert,

I work with Pascal and have been investigating synchronization issues in RPL for a while now.

I would like to corroborate that the idea about tying the MAC coordinator to the RPL parent is the best approach and we have simulation results to indicating the same.

An important observation that I would like to bring to your notice is -

Our assumption of sparsely connected network with low data traffic to total traffic ratio is something that may quickly become obsolete for the  next generation of sensor networks as application for Smart Cities, Industrial automation, Intra-vehicular network and other use cases. In all of these scenarios, the sensor network is dense i.e there are many nodes per RPL hop with each parent having many children. In such scenarios RPL take a significant amount of time to choose the best parent and/or switches parents frequently. If we allow the RPL parent selection process to directly or indirectly control the choice of MAC coordinator it will significantly increase the L2 control traffic.
My proposal is to allow the choice of MAC coordinator to influence the choice of parent at L3. This has two advantages, 1) significant improvement in L3 network formation/convergence 2) Reduction is control traffic at L2 and L3. It also indirectly creates a more stable time sync across the entire network due to lesser number of changes in the choice of MAC coordinator.

Now, such a scheme would require L3 data to be published in the beacon which as Robert has already pointed out is a layer violation. Instead, we can propose the following -
1.       L3 protocol (since TSCH is not RPL specific) registers with a TSCH API that can control the method in which MAC coordinator is chosen and the content of EB.
2.       The definition of the method of choosing a MAC coordinator needs to be clearly described so any L3 can easily provide the necessary information (akin to a software API)
3.       L3 can also provide a simple description of the level of detail require in the EB w.r.t the MAC coordinator, time sync info etc.
4.       The L3 and L2 can dynamically change these parameters depending on type of neighbors discovered, network requirement etc. Of course, there must be a master-slave message exchange procedure to avoid deadlocks.
Generalizing the above statements, you may have already noticed, what I am getting at is a way to allow cross-layer optimization without layer violation. Emphasizing a well known fact - future sensor networks have opened up an extremely broad spectrum of requirement which no single set of protocols can satisfy. Without cross-layer optimization it is very difficult to meet these requirements. I feel that TSCH will be have a significant edge over other protocols if it can incorporate mechanism akin to software APIs to allow cross-layer optimization.

IMO, this is an important design feature that an L2 needs to provide in the use cases that I mentioned earlier and in general to be widely applicable to future sensor networks.

I would be happy to brainstorm these ideas and consider their applicability to the scope of TSCH.

-raghuram

From: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Date: Sunday, February 10, 2013 1:15 PM
To: Robert Assimiti <[email-masked]<mailto:[email-masked]>>
Cc: IETF 6TSCH <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Robert,

On Fri, Feb 8, 2013 at 8:57 AM, Robert Assimiti <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Assimiti
Sent: Friday, February 08, 2013 11:50 AM
To: Thomas Watteyne

Cc: IETF 6TSCH

Thomas,

Robert Assimiti

Robert,

Thomas

1.      Enhanced beacons

2.      Enhanced ACKs

Thks

Robert Assimiti

X.

-----Nick

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Feb 2013 15:04:12 -0500

>>>>> "rsudhaak" == rsudhaak  <Raghuram> writes:
    rsudhaak> automation, Intra-vehicular network and other use
    rsudhaak> cases. In all of these scenarios, the sensor network is
    rsudhaak> dense i.e there are many nodes per RPL hop with each
    rsudhaak> parent having many children. In such scenarios RPL take a
    rsudhaak> significant amount of time to choose the best parent
    rsudhaak> and/or switches parents frequently. If we allow the RPL

Why do you say that they take a significant amount of time to "CHOOSE"?
As for switching, that's a hysteris issue, and MRHOF is supposed to deal
with that.

Can you tell us more about this research?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Tom Phinney <[email-masked]>
Date: Tue, 12 Feb 2013 13:14:07 -0700

All,

I have a lot of experience in layering and avoiding layering
violations, going back to working with Charlie Bachman at
Honeywell on the Honeywell Distributed System Architecture, which
became the OSI Basic Reference Model (for which Charlie was
initial Rapporteur). I was involved in IEEE 802 from its earliest
working meeting in April 1980, and was one of those who made the
layering mistake that is the IEEE 802 MAC slice through the OSI
protocol stack. (Years later I figured out how the Physical and
Data-link modeling could have been done to maintain layer purity
while still accomplishing all the MAC goals, including the most
difficult to model, which was the real-time manipulation of header
bits in IEEE 802.5 token ring frames as they progressed
sequentially through token ring devices.)

The issue of layer violations arises when there is knowledge
within one layer of the internal structure and meaning of
information in another layer. There is no violation when one layer
conveys information transparently for another layer. Thus, in this
case, one could envision an L3 (Network Layer) mechanism that
creates DIOs to be conveyed to various other L3 nodes, together
with an indication that such conveyance is now desired/required
and/or that the information to be conveyed has changed from its
prior value.

One can also envision an L2 (Data-link layer) that sends EBs that
have an optional payload field for conveying higher-protocol-layer
information that L2 does not attempt to interpret.

Putting these two together, one has both L3 messages to be
conveyed and an L2 mechanism for conveying L3 messages. There is
no layer violation here. However, there is the potential for the
L3 message to not be sent, so a backup transmission mechanism,
such as a timer on the L3 DIO information that promotes it from
"available fro conveyance" to "needs to be conveyed" status. The
latter would invoke explicit L2 messaging to achieve that
conveyance, which provides the missing piece of the puzzle. The
end result is a "lazy" L3 messaging protocol that attempts to
piggyback message conveyance on otherwise-occurring L2 messaging,
but that ends up requesting explicit purpose-specific L2 messaging
when that "lazy" mechanism fails to convey the L3 information
within the required time.

-Tom Phinney

===

On 2013.02.12 09:11, Raghuram Sudhaakar (rsudhaak) wrote:

Hello Thomas, Robert,

I work with Pascal and have been
investigating synchronization issues in RPL for a while
now.

I would like to corroborate that the idea
about tying the MAC coordinator to the RPL parent is the
best approach and we have simulation results to
indicating the same.

An important observation that I would like
to bring to your notice is -

Our assumption of sparsely connected
network with low data traffic to total traffic ratio is
something that may quickly become obsolete for the  next
generation of sensor networks as application for Smart
Cities, Industrial automation, Intra-vehicular network
and other use cases. In all of these scenarios, the
sensor network is dense i.e there are many nodes per RPL
hop with each parent having many children. In such
scenarios RPL take a significant amount of time to
choose the best parent and/or switches parents
frequently. If we allow the RPL parent selection process
to directly or indirectly control the choice of MAC
coordinator it will significantly increase the L2
control traffic.

My proposal is to allow the choice of MAC
coordinator to influence the choice of parent at L3.
This has two advantages, 1) significant improvement in
L3 network formation/convergence 2) Reduction is control
traffic at L2 and L3. It also indirectly creates a more
stable time sync across the entire network due to lesser
number of changes in the choice of MAC coordinator.

Now, such a scheme would require L3 data to
be published in the beacon which as Robert has already
pointed out is a layer violation. Instead, we can
propose the following -

1.       L3 protocol (since TSCH is not RPL
specific) registers with a TSCH API that can control the
method in which MAC coordinator is chosen and the content
of EB.

2.       The definition of the method of
choosing a MAC coordinator needs to be clearly described
so any L3 can easily provide the necessary information
(akin to a software API)

3.       L3 can also provide a simple
description of the level of detail require in the EB w.r.t
the MAC coordinator, time sync info etc.

4.       The L3 and L2 can dynamically change
these parameters depending on type of neighbors
discovered, network requirement etc. Of course, there must
be a master-slave message exchange procedure to avoid
deadlocks.

Generalizing the above statements, you may
have already noticed, what I am getting at is a way to
allow cross-layer optimization without layer violation.
Emphasizing a well known fact - future sensor networks
have opened up an extremely broad spectrum of
requirement which no single set of protocols can
satisfy. Without cross-layer optimization it is very
difficult to meet these requirements. I feel that TSCH
will be have a significant edge over other protocols if
it can incorporate mechanism akin to software APIs to
allow cross-layer optimization.

IMO, this is an important design feature
that an L2 needs to provide in the use cases that I
mentioned earlier and in general to be widely applicable
to future sensor networks.

I would be happy to brainstorm these ideas
and consider their applicability to the scope of TSCH.

-raghuram

From: Thomas Watteyne
<[email-masked]>

Date: Sunday,
February 10, 2013 1:15 PM

To: Robert Assimiti

Cc: IETF 6TSCH <[email-masked]>

Subject: Re: [6tsch]
Time synchs and RPL discovery/maintenance traffic

Robert,

Thomas

On Fri, Feb 8, 2013 at 8:57 AM,
Robert Assimiti
<[email-masked]>
wrote:

Thomas,

Just to clarify what I meant
was:

“I believe that
tying the TSCH
MAC coordinator (typically also the time
source) to the RPL parent
is an excellent idea.

From:
[email-masked]
[mailto:[email-masked]]
On Behalf Of Robert Assimiti

Sent: Friday, February 08, 2013 11:50
AM

To: Thomas Watteyne

Cc: IETF 6TSCH

Subject: Re: [6tsch] Time synchs and
RPL discovery/maintenance traffic

Thomas,

I believe that tying the
TSCH time source to the RPL is an excellent
idea. This is exactly what we do in our
current system and believe you me, it saved us
a lot of aspirin and Tylenol (or whatever
headache medicine you prefer).

Let me suggest the
following flow:

1.
Device starts going
through discovery and it build a table of
neighbors

2.
Device chooses a MAC
coordinator from the table of neighbors
(criteria based on which is outside the scope
of this discussion)

3.
RPL above does the same
in parallel (DIOs). Once RPL chooses a parent
it would ensure that the MAC layer uses the
parent as the coordinator.

As for the enhanced
beacons they are a MAC mechanism and in my
ever to be humbled they should only ever
include IEs (channel hopping, slot, link, etc)
and no DIO (or RPL discovery related) since
that would be a clear layer violation. But the
EBs could be coordinated (within the device)
with DIO (or other RPL maintenance or
discovery) traffic.

Robert Assimiti

From:
[email-masked] [mailto:[email-masked]]
On Behalf Of Thomas Watteyne

Sent: Wednesday, February 06, 2013
6:38 PM

To: Robert Assimiti

Cc: IETF 6TSCH

Subject: Re: [6tsch] Time synchs and
RPL discovery/maintenance traffic

Robert,

I agree that we need to
reconcile sync and routing. Since TSCH does
not define who a mote's time source neighbor
should be, and since RPL doesn't either, the
6tsch layer would I believe be the right
location. I avoid the term "shim" since it
sounds as "super-thin-does-very-little".

TSCH defined the concept of
time source neighbor, and RPL of routing
parent. These could be made the same,
especially since TSCH allows for motes to have
multiple time source parents. Moreover, in a
multi-hop setting, we don't want to end up
with synchronization loops, so a (RPL) DAG
organization looks like the right one.
Finally, RPL will cause data traffic to flow
from a mote to its routing parent(s), if that
routing parent is also a TSCH time source
neighbor, this means that the mote will be
tightly sync'ed "for free" when data is
flowing.

Do you have any thoughts on
why tying TSCH time source neighbors to RPL
routing parents would not be a good idea?
Given that a TSCH topology is relatively
stable due to the channel hopping nature of
communication, I would imagine that routing
churn to relatively low, and so changes in
routing/sync parents infrequent.

Just to clarify some
terminology: the Enhanced Beacon (EB) you
refer to, is the one used to advertise the
presence of the network, and which contain
lots of IEs describing the network (channel
hopping, timeslot info, link/slotframe info,
etc) described in 5.1.2.6? I agree that this
role is similar in nature to the "periodic"
DIOs being sent by RPL. Are you toying with
the idea of putting the DIO payload after the
EB IEs? The standard might be flexible enough
to allow the 6tsch layer to just send that up
the stack as if they were regular data
packets.

Could we do some
back-of-the-envelope calculation to determine
how much this would give us? Do you have a
rough list of what periodic traffic is being
sent by a full-featured RPL, and how many
packets/s that represents?

Thomas

On Wed, Feb 6, 2013 at
2:18 PM, Robert Assimiti <[email-masked]>
wrote:

Thomas,

The mechanism(s)
used for time synchronization is
something that we might have to
reconcile with RPL discovery and
maintenance traffic.

Time
synchronization in TSCH is based on
three mechanisms:

1.
Enhanced beacons

2.
Enhanced ACKs

3.
Frame based
synchronization

If a node
communicates intermittently (sleepy,
battery operated) it can also
proactively ping its time source and
receive time stamps.

In order to
maximize battery life and network
throughput, it is advisable that RPL
ICMP discovery and maintenance traffic
(governed by the trickle timer) be
somehow coordinated with the
transmission of time synch packets
(especially with enhanced beacons).

This could be a
function of the shim layer or it could
be deferred to the device management
entity. Any suggestions, ideas on this
topic?

Thks

Robert Assimiti

From:
[email-masked]
[mailto:[email-masked]]
On Behalf Of Thomas Watteyne

Sent: Thursday, January 31,
2013 8:50 PM

To: IETF 6TSCH

Subject: Re: [6tsch] Exposing
network time (etc) to higher layers.

Agreed. TSCH is built
to compensate for clock drift by using
all (incl. data) packets to
re-synchronize, and send keep-alive
packets when not enough data packets are
sent to satisfy a "good enough"
synchronization. You can get the motes
in your network synchronized within 10's
of us. In fact, the better synchronized,
the less long you have to listen for a
packet (since you always have to listen
early in case your neighbor mote
drifted), so tight synchronization is a
power *benefit*, not a power cost.

As pointed out by
Kris, this becomes really interesting
for the application to timestamp its
payload. Are you thinking of any
particular use of tight
synchronization by the routing layer?

On Thu, Jan
31, 2013 at 4:28 PM, Xavier
Vilajosana <[email-masked]>
wrote:

Motes keep
aligned with guard times
smaller than 1ms, also motes
share the global ASN, with
that in mind, would not be
difficult to expose network
time. Time accuracy might then
depended on the energy
constraints of the networks.
As more tight synchronization
more packets on the air.

X.

On 31/01/13 16:23, Nick
Moore wrote:

On
01/02/13 10:29, Kris Pister
wrote:

So for
sure we need a mechanism
where network time can be
exposed to higher layers.

Hey, that's a really
interesting thought,
especially given the drifty
nature of mote clocks.

-----Nick

6tsch mailing list

[email-masked]

6tsch mailing list

[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 12 Feb 2013 12:39:10 -0800

Tom,

Thanks for the very clear definition of layer violation. I believe this now
makes perfect sense.

Thomas

On Tue, Feb 12, 2013 at 12:14 PM, Tom Phinney <[email-masked]> wrote:

> **
> All,
>
> I have a lot of experience in layering and avoiding layering violations,
> going back to working with Charlie Bachman at Honeywell on the Honeywell
> Distributed System Architecture, which became the OSI Basic Reference Model
> (for which Charlie was initial Rapporteur). I was involved in IEEE 802 from
> its earliest working meeting in April 1980, and was one of those who made
> the layering mistake that is the IEEE 802 MAC slice through the OSI
> protocol stack. (Years later I figured out how the Physical and Data-link
> modeling could have been done to maintain layer purity while still
> accomplishing all the MAC goals, including the most difficult to model,
> which was the real-time manipulation of header bits in IEEE 802.5 token
> ring frames as they progressed sequentially through token ring devices.)
>
> The issue of layer violations arises when there is knowledge within one
> layer of the internal structure and meaning of information in another
> layer. There is no violation when one layer conveys information
> transparently for another layer. Thus, in this case, one could envision an
> L3 (Network Layer) mechanism that creates DIOs to be conveyed to various
> other L3 nodes, together with an indication that such conveyance is now
> desired/required and/or that the information to be conveyed has changed
> from its prior value.
>
> One can also envision an L2 (Data-link layer) that sends EBs that have an
> optional payload field for conveying higher-protocol-layer information that
> L2 does not attempt to interpret.
>
> Putting these two together, one has both L3 messages to be conveyed and an
> L2 mechanism for conveying L3 messages. There is no layer violation here.
> However, there is the potential for the L3 message to not be sent, so a
> backup transmission mechanism, such as a timer on the L3 DIO information
> that promotes it from "available fro conveyance" to "needs to be conveyed"
> status. The latter would invoke explicit L2 messaging to achieve that
> conveyance, which provides the missing piece of the puzzle. The end result
> is a "lazy" L3 messaging protocol that attempts to piggyback message
> conveyance on otherwise-occurring L2 messaging, but that ends up requesting
> explicit purpose-specific L2 messaging when that "lazy" mechanism fails to
> convey the L3 information within the required time.
>
> -Tom Phinney
> ===
>
>
>   Hello Thomas, Robert,****
>
> ** **
>
> I work with Pascal and have been investigating synchronization issues in
> RPL for a while now. ****
>
> ** **
>
> I would like to corroborate that the idea about tying the MAC coordinator
> to the RPL parent is the best approach and we have simulation results to
> indicating the same.****
>
> ** **
>
> An important observation that I would like to bring to your notice is -***
> *
>
> ** **
>
> Our assumption of sparsely connected network with low data traffic to
> total traffic ratio is something that may quickly become obsolete for the
>  next generation of sensor networks as application for Smart Cities,
> Industrial automation, Intra-vehicular network and other use cases. In all
> of these scenarios, the sensor network is dense i.e there are many nodes
> per RPL hop with each parent having many children. In such scenarios RPL
> take a significant amount of time to choose the best parent and/or switches
> parents frequently. If we allow the RPL parent selection process to
> directly or indirectly control the choice of MAC coordinator it will
> significantly increase the L2 control traffic.****
>
> My proposal is to allow the choice of MAC coordinator to influence the
> choice of parent at L3. This has two advantages, 1) significant improvement
> in L3 network formation/convergence 2) Reduction is control traffic at L2
> and L3. It also indirectly creates a more stable time sync across the
> entire network due to lesser number of changes in the choice of MAC
> coordinator.****
>
> ** **
>
> Now, such a scheme would require L3 data to be published in the beacon
> which as Robert has already pointed out is a layer violation. Instead, we
> can propose the following -****
>
> 1.       L3 protocol (since TSCH is not RPL specific) registers with a
> TSCH API that can control the method in which MAC coordinator is chosen and
> the content of EB. ****
>
> 2.       The definition of the method of choosing a MAC coordinator needs
> to be clearly described so any L3 can easily provide the necessary
> information (akin to a software API)****
>
> 3.       L3 can also provide a simple description of the level of detail
> require in the EB w.r.t the MAC coordinator, time sync info etc.****
>
> 4.       The L3 and L2 can dynamically change these parameters depending
> on type of neighbors discovered, network requirement etc. Of course, there
> must be a master-slave message exchange procedure to avoid deadlocks.****
>
> Generalizing the above statements, you may have already noticed, what I am
> getting at is a way to allow cross-layer optimization without layer
> violation. Emphasizing a well known fact - future sensor networks have
> opened up an extremely broad spectrum of requirement which no single set of
> protocols can satisfy. Without cross-layer optimization it is very
> difficult to meet these requirements. I feel that TSCH will be have a
> significant edge over other protocols if it can incorporate mechanism akin
> to software APIs to allow cross-layer optimization.****
>
> ** **
>
> IMO, this is an important design feature that an L2 needs to provide in
> the use cases that I mentioned earlier and in general to be widely
> applicable to future sensor networks. ****
>
> ** **
>
>   From: Thomas Watteyne <[email-masked]>
> To: Robert Assimiti <[email-masked]>
> On Fri, Feb 8, 2013 at 8:57 AM, Robert Assimiti <[email-masked]
> > wrote:
>
>>  Thomas,
>>
>>
>>
>> source)* to the RPL *parent *is an excellent idea.
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Robert Assimiti
>> *Subject:* Re: [6tsch] Time synchs and RPL discovery/maintenance traffic
>>
>>
>>
>> Thomas,
>>
>>
>>
>> I believe that tying the TSCH time source to the RPL is an excellent
>> idea. This is exactly what we do in our current system and believe you me,
>> it saved us a lot of aspirin and Tylenol (or whatever headache medicine you
>> prefer).
>>
>>
>>
>> (criteria based on which is outside the scope of this discussion)
>>
>> coordinator.
>> DIO (or other RPL maintenance or discovery) traffic.
>>
>>
>>
>> *Robert Assimiti*
>>
>>
>>
>> *Subject:* Re: [6tsch] Time synchs and RPL discovery/maintenance traffic
>>
>>
>>
>> Robert,
>>
>>
>>
>> have to reconcile with RPL discovery and maintenance traffic.
>>
>>
>>
>> also proactively ping its time source and receive time stamps.
>>
>>
>>
>> device management entity. Any suggestions, ideas on this topic?
>>
>>
>>
>> Thks
>>
>>
>>
>> *Robert Assimiti*
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Thomas Watteyne
>> *Subject:* Re: [6tsch] Exposing network time (etc) to higher layers.
>>
>>
>>
>> use of tight synchronization by the routing layer?
>>
>>
>>
>> [email-masked]> wrote:
>>
>> Motes keep aligned with guard times smaller than 1ms, also motes share
>> the global ASN, with that in mind, would not be difficult to expose network
>> higher layers.
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Tue, 12 Feb 2013 20:52:00 +0000

Michael,
In dense, mobile network (e.g. Industrial automation, health care) there
are a few critical contributors to this problem -
	1) There are multiple candidate parents
	2) The DIO's of these parent are asynchronous
	3) Link Quality is calculated by simple ping-based approach over a finite
amount of time (default I think is, 5 times with 1 sec inter-arrival)

These 3 factors combined with mobility (albeit slow) cause the delays in
settling on a suitable parent.

I should also explain myself further w.r.t what I meant by choosing a
parent. To clarify - A parent is considered chosen when we are ready to
send useful application data via the parent.

In the RPL parent selection procedure, there is a wait time to receive a
second DIO to confirm parameters before starting to send traffic via the
parent. Now, during this time if we receive another DIO from another node
with different/better params w.r.t the OF, we start the parent selection
procedure all over again.

This adversely affects the goodput.

I understand that the initial design of RPL was considering static sensor
networks and the above situations/conditions do not coincide with the
assumptions. However, as you may acknowledge, these factors are becoming
very important for various use cases.

I believe that RPL itself incorporates some very useful techniques
(including trickle timers, OF etc) which are broadly applicable across
these use cases. The line of thought is to provide RPL extra information
so as to improve performance and become applicable to the use cases where
there are some deficiencies. In this way we need not modify the core RPL
protocol so as to maintain interoperability with a wider range of
networks/applications.

For example, if TSCH beacon can provide neighbor info and link quality to
RPL it will be much faster, more reliable and have less errors as compared
to the existing techniques. However, in certain use cases the existing
neighbor discovery method may be more than enough.

Hence we need an approach wherein, we can allow these dynamic requirements
based on uses cases without hardcoding the stack.

-raghuram

---

From: Kris Pister <[email-masked]>
Date: Tue, 12 Feb 2013 15:40:46 -0800

Raghuram -
    I have to nitpick a small but important point here.  Industrial 
automation may end up being an application domain where we see dense 
networks some day.  BP funded one of my students to determine if the 
plant of the future could have one million wirelessHART sensors in 10km2 
(answer: yes).
*BUT*
We are not there yet.  The problems that I've seen in the real world are 
generally related to networks being too sparse.  We *love* it when 
networks get dense.  The kind of problems that you're talking about are 
good problems to have.  The problem with the whole WSN field  is that 
too many people focused on the dream and forgot to develop things that 
actually work right now.

ksjp

---

From: Robert Assimiti <[email-masked]>
Date: Wed, 13 Feb 2013 09:10:54 -0500

Pascal,

Why not let the trickle timer do its job, and just ensure that DIOs are piggybacked on EBs.

That somewhat implies that we are making two assumptions:

1.      EBs are the primary TSCH time synchronization mechanism

2.      This assumes of course that the periodicity of time synchs in TSCH always exceeds the highest (albeit temporary due to the nature of the trickle algorithm) periodicity of DIOs. Based on my experience I would say that this assumption is always valid.

I would appreciate feedback from  the group vis-à-vis these assumptions.

Robert Assimiti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, February 12, 2013 8:22 AM
To: Thomas Watteyne; IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

My trouble is this:

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: lundi 11 février 2013 00:55
To: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Qin,

Thanks
Qin

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Wed, 13 Feb 2013 16:27:24 +0000

Kris,
Definitely we are not there yet w.r.t dense sensor networks. But as you
have rightly pointed out it is the evolutionary path.

>From the industry stand point, we see that there are a lot of customers
needing such a solution. As you may know, many key players in the sensor
hardware (importantly wireless connectivity) domain have come up with
viable and practical sensors that allow such deployments. The industry
projects that a critical mass for dense sensor deployments will be reached
in the next 5 years.

Hopefully, we can find the right balance of what will work efficiently for
today's networks while not wanting for anything when density increases
significantly. 

I do not completely agree with the point that we do not have things that
work today. We do have quite a few deployed and active sensor based
systems and protocols operating in the field today. However, they are
applicable only to a limited range of use cases - because they are
tuned/optimized for a particular set of parameters/assumptions. This seems
to be our problem today.

In the ideal world, we need the equivalent of TCP/IP.

-raghuram

---

From: Kris Pister <[email-masked]>
Date: Wed, 13 Feb 2013 13:37:17 -0800

Raghuram - I agree with you that there are viable and practical sensors, 
applications, and customers for dense networks.

I didn't say that we do not have things that work today - just that 
*most* things don't work today.  There are happy wireless HART customers 
in >100 countries on six continents.  But for every happy WSN user today 
I would say that there are at least ten who tried Zigbee or something 
similar and decided that the technology doesn't work - that's had a huge 
negative impact on the adoption rate of the whole field.  Most of the 
problems come in sparse networks.  Zigbee can be made to work in dense 
deployments with lots of powered infrastructure and some mobility (e.g. 
lighting control).
I agree with you that we need to make sure that our networks will work 
well in dense deployments with lots of powered infrastructure and some 
mobility.  But those are the *easy* problems to solve, not the hard ones.

ksjp

---

From: Kris Pister <[email-masked]>
Date: Wed, 13 Feb 2013 13:49:29 -0800

Robert -
   I can imagine low-data-rate networks where EBs are the primary time 
synch mechanism, but I don't think that this is generally the case.  In 
the majority of our networks the nodes are synchronized by the normal 
packet flow.

In a fully-formed network EBs might be sent quite infrequently.
We have customers who turn them off after the network has formed (to 
save power) and only turn them on again if a mote goes missing. Whereas 
even in a static network it's important to send DIOs due to the 
inscrutability of RF.

ksjp

On 2/13/2013 6:10 AM, Robert Assimiti wrote:
> 1.EBs are the primary TSCH time synchronization mechanism
>
> 2.This assumes of course that the periodicity of time synchs in TSCH 
> always exceeds the highest (albeit temporary due to the nature of the 
> trickle algorithm) periodicity of DIOs. Based on my experience I would 
> say that this assumption is always valid.
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Pascal Thubert (pthubert)
> *Sent:* Tuesday, February 12, 2013 8:22 AM
> *To:* Thomas Watteyne; IETF 6TSCH
> We normally want to avoid mixing constraints from different layers, 
> which would be the case if we emit a DIO just because we want to 
> resync a clock. OTOH, there are benefits in sending more DIOs when 
> bandwidth/energy is consumed anyway.
>
> I was thinking that the need for a resync of clocks somewhere might be 
> 'synchronized' with the need ro resync elsewhere. And if that cause to 
> fire DIOs then the DIOs are synchronized. I thought that such an 
> effect is really unwanted.
>
> RPL has the Trickle timer that will delay DIOs. As such, we cannot 
> expect that the need to resync can immediately fire a DIO.
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Thomas Watteyne
> *Sent:* lundi 11 février 2013 00:55
> *To:* IETF 6TSCH
> layer EB
> can be
> make a
> timer, and
> medicine you
> refer to,
> traffic is
> us. In
> of the

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 14 Feb 2013 13:05:05 -0500

Raghuram,

Glad to see that we both agree that the MAC coordinator <-> RPL parent selection should be synchronized.

I am a bit reluctant though in having the RPL parent be influenced by the MAC coordinator selection (and not vice-versa).

The reasons being that:

1.      The RPL parent selection often takes in consideration aggregate metrics received from multiple motes that are part of a particular multi-hop route. The MAC coordinator decision is somewhat short-sighted since it is taken based on an evaluation of its immediate neighbors

2.      A mote can (and often does) participate in multiple DODAGs that have different optimization goals.

I fully agree though that we need to provide a cross-layer mechanism for synchronizing the two.

One could also envision a scheme where it is up to the device to either:

1.      Choose a MAC coordinator that is influenced by the RPL parent selection

2.      Choose a RPL parent that is influenced by the MAC coordinator selection

What do you think?

Robert Assimiti

From: Raghuram Sudhaakar (rsudhaak) [mailto:[email-masked]]
Sent: Tuesday, February 12, 2013 11:11 AM
To: Thomas Watteyne; Robert Assimiti
Cc: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Hello Thomas, Robert,

-raghuram

Robert,

Cc: IETF 6TSCH

Thomas,

Robert Assimiti

Robert,

Thomas

1.      Enhanced beacons

2.      Enhanced ACKs

Thks

Robert Assimiti

X.

-----Nick

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Thu, 14 Feb 2013 18:27:16 +0000

Robert,
I agree with the concern you are raising.

It does make complete sense to allow this choice to be negotiated. We must see how to include such a mechanism between L2 and L3 to give flexibility to the devices.

One proposal would be to extend the RPL OF to take into account choice of MAC coordinator (L2 influencing L3). This will allow for enough flexibility for formation of different DAGs with different OF's.

To provide the mechanism wherein L3 influences L2 we need to make sure the RPL (L3 in general) publishes the choice of RPL parent. The method to enforce this is key, otherwise we might have a lot of inconsistencies in L2.

-raghuram

From: Robert Assimiti <[email-masked]<mailto:[email-masked]>>
Date: Thursday, February 14, 2013 10:05 AM
To: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>, Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Cc: IETF 6TSCH <[email-masked]<mailto:[email-masked]>>
Subject: RE: [6tsch] Time synchs and RPL discovery/maintenance traffic

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 14 Feb 2013 13:28:56 -0500

Rahuram,

Excellent suggestions.

Robert Assimiti

From: Raghuram Sudhaakar (rsudhaak) [mailto:[email-masked]]
Sent: Thursday, February 14, 2013 1:27 PM
To: Robert Assimiti; Thomas Watteyne
Cc: IETF 6TSCH
Subject: Re: [6tsch] Time synchs and RPL discovery/maintenance traffic

Robert,

-raghuram

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Thu, 14 Feb 2013 18:37:31 +0000

Kris,
You're right about the level of difficulty of the problem.

Just trying to think how we can design a solution that will be widely
applicable.

-raghuram

On 2/13/13 1:37 PM, "Kris Pister" <[email-masked]> wrote:

>>>>> IETF ROLL WG co-chair.
>>>>>http://datatracker.ietf.org/wg/roll/charter/
>>>>>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Feb 2013 13:50:05 -0500

>>>>> "Robert" == Robert Assimiti <[email-masked]> writes:
    Robert> One proposal would be to extend the RPL OF to take into
    Robert> account choice of MAC coordinator (L2 influencing L3). This
    Robert> will allow for enough flexibility for formation of different
    Robert> DAGs with different OF's. 

This is in my opinion the likely visible part of 6tsch: a new OF and/or
new metrics.

RPL has to make the decision(s), not have part of it made by L2 based
upon the minimal knowledge that it has.