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

From: Michael Richardson <[email-masked]>
Date: Thu, 24 Jan 2013 18:31:58 -0500

In the future, please write up a description of the new list, and
send it to the relevant working groups, and let us subscribe ourselves.

The first I heard about this, was the mailman welcome message.

now: is there a description of this list which can be posted to the ROLL
     list?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 24 Jan 2013 16:15:54 -0800

Michael,

Thanks for pointing that out. We have been having e-mail and phone
discussions around 6LoWPAN/RPL over IEEE802.15.4e for a couple of weeks
with the subscribers of this mailing list. The To: field became too long,
so we decided that an IETF mailing list was the best format for going
forward. When requesting the creation of the list, I realize now that a
handful of e-mail addresses we suggested were not part of the informal
discussion list. Yours is one of them, and I apologize for the confusion.

The 6tsch list is created to "discuss link layer model for Deterministic
IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN
such as resource allocation". Its description is:

*This list is for discussions relating to the development, clarification,
and implementation of IPv6 access and meshing over deterministic
(scheduled) MAC with specific interest in IEEE 802.15.4e TSCH. Focus is on
issues related with time slots awareness at L3, time slots allocation and
distribution, and the eventual mix of centralized and distributed operation
for routing and resource allocation. The list should facilitate exchanges
between opensource implementers, share on the applicability of the
technology and address the gaps in existing IETF specs from RPL and
6LoWPAN. This list may steer work at the IETF, as well as IEC and ISA. One
of the goals for the group, should we create one, would be to put together
an IETF straw man binding existing standards (RPL, 6LoWPAN, PANA,
ForCES/OpenFlow, diffserv) over 802.15.4e.*

We will send out the announcement to ROLL shortly.

Thomas

On Thu, Jan 24, 2013 at 3:31 PM, Michael Richardson
<[email-masked]>wrote:

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

---

From: Pascal Thubert <[email-masked]>
Date: Fri, 25 Jan 2013 21:36:00 +0100

That's me actually, Michael.

I added you as a courtesy, considering that RPL is a core component of the discussion, I wanted to make sure you were informed as soon as the list would exist.

Sorry if that bothered you,

Cheers,

Pascal

Le 25 janv. 2013 à 01:15, Thomas Watteyne <[email-masked]> a écrit :

> Michael,
> 
> Thanks for pointing that out. We have been having e-mail and phone discussions around 6LoWPAN/RPL over IEEE802.15.4e for a couple of weeks with the subscribers of this mailing list. The To: field became too long, so we decided that an IETF mailing list was the best format for going forward. When requesting the creation of the list, I realize now that a handful of e-mail addresses we suggested were not part of the informal discussion list. Yours is one of them, and I apologize for the confusion.
> 
> The 6tsch list is created to "discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation". Its description is:
> 
> This list is for discussions relating to the development, clarification, and implementation of IPv6 access and meshing over deterministic (scheduled) MAC with specific interest in IEEE 802.15.4e TSCH. Focus is on issues related with time slots awareness at L3, time slots allocation and distribution, and the eventual mix of centralized and distributed operation for routing and resource allocation. The list should facilitate exchanges between opensource implementers, share on the applicability of the technology and address the gaps in existing IETF specs from RPL and 6LoWPAN. This list may steer work at the IETF, as well as IEC and ISA. One of the goals for the group, should we create one, would be to put together an IETF straw man binding existing standards (RPL, 6LoWPAN, PANA, ForCES/OpenFlow, diffserv) over 802.15.4e.
> 
> On Thu, Jan 24, 2013 at 3:31 PM, Michael Richardson <[email-masked]> wrote:
>>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Jan 2013 13:20:27 -0500

>>>>> "Thomas" == Thomas Watteyne <[email-masked]> writes:
    Thomas> Thanks for pointing that out. We have been having e-mail and
    Thomas> phone discussions around 6LoWPAN/RPL over IEEE802.15.4e for
    Thomas> a couple of weeks 
    Thomas> with the subscribers of this mailing list. The To: field
    Thomas> became too long, 
    Thomas> so we decided that an IETF mailing list was the best format
    Thomas> for going forward. When requesting the creation of the list,
    Thomas> I realize now that a handful of e-mail addresses we
    Thomas> suggested were not part of the informal 
    Thomas> discussion list. Yours is one of them, and I apologize for
    Thomas> the confusion. 

not a problem, I'm glad to be included.

    Thomas> The 6tsch list is created to "discuss link layer model for
    Thomas> Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and
    Thomas> impacts on RPL and 6LoWPAN 
    Thomas> such as resource allocation". Its description is:

okay, so this perhaps relates in part to:
      http://tools.ietf.org/agenda/85/slides/slides-85-roll-4.pdf
and   http://datatracker.ietf.org/doc/draft-wei-roll-scheduling-routing/

    Thomas> (scheduled) MAC with specific interest in IEEE 802.15.4e
    Thomas> TSCH. Focus is on 
    Thomas> issues related with time slots awareness at L3, time slots
    Thomas> allocation and 

So, if I understand the problem correctly, let me retell is in terms
I find more amusing.

So, years ago, I enjoyed _The Chicken from Minsk_, 
    http://www.amazon.com/The-Chicken-Minsk-Infuriatingly-Challenging/dp/0465071279
    http://books.google.com/books/about/The_chicken_from_Minsk.html?id=X99AAQAAIAAJ

And it told the story of Boris' trip to the University of Moscow
as a puzzle, and it went something like this: 

He apparently lives exactly 180 degress from the university. (Now, given
the Internet, I guess I can actually check this.....
http://see-you-in-moscow.com/_bl/0/47721536.gif The brown line)

The subway metros come every 30 minutes in each direction.  Boris
arrives at the station at random times, but finds that he usually goes
clockwise around the loop, rather than counter clockwise.  Why?

====

The answer is that while the two trains arrive every 30 minutes, they do
not come clockwise at :00,:30 and counterclock-wise at :15,:45 where he
gets on, but rather at :00,:30 and :02:,:32.  So, unless he arrives at
:01 or :31, the clockwise train always arrives first.

In the case of mesh networks, the point is similar, but more complex.
For Boris, once he is on the train, the travel time is the same, but 
for 15.4e, the situation might be that the the :02 train takes
significantly less time to get there, and so one should wait for the
train in the shorter direction.  Or sometimes, that wait is too long,
and one should go the long way around, rather than wait.  

We also have considerations of energy, and maybe even congestion to 
optimize for.

====
ps: according to the Chicken from Minsk, frictionless tables and
    trains were one of the successes of soviet science.

-- 
]               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: Tom Phinney <[email-masked]>
Date: Sun, 27 Jan 2013 00:40:07 -0700

"The chicken from Minsk" is an example of an
isolated local optimization that might be available in a
quasi-deterministic system, such as TSCH over IEEE
802.15.4, based on knowledge of a small subset of whatever schedule
may exist for the portion of the overall network and local RF medium
that is available for message transport between the intended
communication endpoints. Note that it is an optimization from the
vantage point of the end node that employs it, but not necessarily
an optimization of the total system resources.

The larger problem is that industrial automation and control systems
are largely deterministic, due to the dynamics of the physical
processes involved. As such they lend themselves to global
optimization technologies. Exxon (now ExxonMobil) realized that in
the 1970s when it began to employ the largest IBM mainframes
available at the time to provide multi-variable optimization for the
control loops in its refineries. (FYI, the largest single Exxon
refinery is 40 square miles (100 km^2 or 10k ha), not counting the
adjacent chemical plant. These systems are huge! They are composed
primarily of multiple dense refining equipment clusters, large
distant storage tanks, and enormous amounts of piping.)

The desired baseline communication patterns in an industrial
automation or control system are essentially static, derived from
the interconnection of physical processes (e.g., pipes, pumps,
valves, chemical reactors, fractionating towers) and the desired end
products. The primary traffic, by volume, is used for continuous
closed-loop control and process state reporting. For a given
specific process area, say 100 m on a side (i.e., 1 ha), that
baseline pattern may have a planned change only once every eighteen
months.

Very small improvements, even on the order of 0.01%, are multiplied
by the immense production volume of the major petrochemical
companies. (There's a reason -- OIL -- why ExxonMobil is again the
world's most valuable company.) Thus for such high-volume system
operators there is little reluctance to expend significant computer
resources to optimize the baseline communication patterns. That also
makes these system operators more willing to innovate in field
trials than most of their peers, because the potential payback is so
large. (And from the vendor's viewpoint, the total amount of
purchased equipment can also be very large. Hence the focus on
solving the BIG problem, rather than less profitable smaller ones.)

Of course wireless systems cannot be static; they have to adapt to
changing propagation characteristics, including fading and
interference, as well as to whatever portion of the total system
traffic varies from the baseline communication patterns.
Additionally, such systems need to be capable of bootstrapping
wireless optimization on plant unit (section) startup, and of
recovering to whatever extent is possible after an environmental
disaster such as an explosion within the plant or a tornado tearing
through the plant, or even such foreseeable circumstances as a
ship's radar intermittently disrupting wireless communication in the
portion of the plant nearest the shoreline. It is these latter
unpredictable aspects that make the addition of self-forming routing
desirable, thus leading to interest in ROLL in such plants.

To summarize, the problem is to have a wireless system go from an
ad-hoc initial startup mode to a precomputed deterministic mode with
an ad-hoc overlay and have it recover when some unplanned event
damages enough of the plant (e.g., wireless routers) that the
optimized deterministic baseline mode is no longer usable. It is
this mix of determinism and non-determinism that we are attempting
to address in a coherent, integrated manner.

-Tom Phinney

retired from Honeywell Automation Systems

former project leader (Convenor) for the 20 or so IEC wired fieldbus
standards

contributor to two industrial wireless standards: WirelessHART and
ISA100.11a

===

On 2013.01.25 11:20, Michael Richardson wrote:

====

====

---

From: Nick Moore <[email-masked]>
Date: Tue, 29 Jan 2013 13:46:54 +1100

> and one should go the long way around, rather than wait.

So, we're hoping to time our packets to use a favorable channel, but 
unlike Boris we don't have a timetable or a fixed set of tracks ...

* To what extent can we coordinate with the MAC to send our packets in a 
favorable slot?

* Can the MAC give us feedback on what slots will be favorable per next-hop?

* Should all this be happening down in the MAC layer instead?

* Or, can we extend RPL (etc) to use this information?

> trains were one of the successes of soviet science.

Assume a spherical chicken of uniform density :-).

-----Nick

-- 
Nick Moore <[email-masked]> (+61) 409 656 267

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 28 Jan 2013 19:07:37 -0800

Hi,

In my point of view MAC layer should provide information services to a 
top sublayer (maybe 2.5). these services may include link status 
information, provided QoS, channel information, etc..

with that information an above service should help to accommodate the 
schedule dynamically. This then will empower end to end QoS services at 
top layers.

Also I think that having absolute control of when to send a packet is 
not the best option, however, if the mac layer adapts dynamically 
(thanks to a service that gets information from the mac layer and acts 
accordingly) for example by  scheduling more links in case  certain 
bandwidth is not met or a channel is not working properly it will tend 
to keep the sense of robustness and QoS which is what upper layers want 
right?

regards,

Xavi

On 28/01/13 18:46, Nick Moore wrote:
> * To what extent can we coordinate with the MAC to send our packets in 
> a favorable slot?
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jan 2013 23:05:24 -0500

>>>>> "Nick" == Nick Moore <[email-masked]> writes:
    >> In the case of mesh networks, the point is similar, but more
    >> complex. For Boris, once he is on the train, the travel time is
    >> the same, but for 15.4e, the situation might be that the the :02
    >> train takes significantly less time to get there, and so one
    >> should wait for the train in the shorter direction. Or sometimes,
    >> that wait is too long, and one should go the long way around,
    >> rather than wait.

    Nick> So, we're hoping to time our packets to use a favorable
    Nick> channel, but unlike Boris we don't have a timetable or a fixed
    Nick> set of tracks ...

    Nick> * To what extent can we coordinate with the MAC to send our
    Nick> packets in a favorable slot?

    Nick> * Can the MAC give us feedback on what slots will be favorable
    Nick> per next-hop?

That is, I think the most important question.

    Nick> * Should all this be happening down in the MAC layer instead?

No.

    Nick> * Or, can we extend RPL (etc) to use this information?

I think so.
What I suspect is that we may need more than one DAG.
I'm hoping that it's only two.  In the context of Boris, he needs one
DAG for :[03]0->:[03]2, and another one for :[03]2->:[36]0.

I understand that the line might not be circular, but I think that the
time schedule is cyclic, is it not?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Jan 2013 23:09:34 -0500

>>>>> "Xavier" == Xavier Vilajosana <[email-masked]> writes:
    Xavier> In my point of view MAC layer should provide information
    Xavier> services to a top sublayer (maybe 2.5). these services may
    Xavier> include link status information, provided QoS, channel
    Xavier> information, etc..

I agree.

It's just that this is a new kind of metric: in the past we have things
like abtracted ETX, bandwidth available, power, latency, etc... none of
these things are a cyclic f(t).

This new info is.

---

From: Nick Moore <[email-masked]>
Date: Tue, 29 Jan 2013 17:43:54 +1100

> No.

OK, but why?  What makes this an L3 (/ L2.5) thing?

I'm not just asking to be contrarian, if this is to become an IETF WG 
that'd be part of the charter ...

-----Nick

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Jan 2013 09:05:24 -0500

>>>>> "Nick" == Nick Moore <[email-masked]> writes:
    Nick> * Should all this
    Nick> be happening down in the MAC layer instead?

    >> No.

    Nick> OK, but why?  What makes this an L3 (/ L2.5) thing?

    Nick> I'm not just asking to be contrarian, if this is to become an
    Nick> IETF WG that'd be part of the charter ...

A number of reasons.
1) the bufferbloat results suggests that buffering at L2 is a bad
   thing.  While very resource constrained nodes are unlikely to have much
   buffer at all, this is not true for edge/gateway nodes, and it is
   increasing untrue of various wearable and PAN-type devices such as
   smartphones which will get LLN interfaces.

   It was particularly a surprise to many layer-3 types what the 802.11
   access point people are doing at layer 2.  A lot of it invalidates
   significant architectural assumptions.  In many cases, the layer-2
   optimizations are coding to the benchmarks, rather than the real traffic.

2) layer-3 (and higher) may need to make (re-)prioritization decisions based
   upon what the transimission schedule is.
   Consider an actuator of some kind (a device that includes a fire
   supressor...) that, due to its critical nature has multiple layer-2
   connections using different technologies.  Maybe IPv6 over CAN over
   9600 baud multi-drop RS422 and 4e.  Layer-3 LLNs can easily build a
   DAG that includes both transports, realize that as slow as the 4e
   might be, it's usually still faster for non-critical traffic than the CAN.
	
   The layer-3 DAG would actually permit the the device to be addressed
   by the application using a single IPv6 address, with the network
   figuring out how to get things there.  That means less complexity and
   network knowledge required by the application.

   There may be times during the 4e cycle when the CAN is faster than
   the wireless.  There also could be congestion on the 4e which would
   cause the slot to be missed.  If the packet remained queued for the
   same layer-2, it would remain for an entire cycle.  

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: Thomas Watteyne <[email-masked]>
Date: Tue, 29 Jan 2013 12:04:21 -0800

Nick, Michael,

Very interesting discussion, indeed. I can't resist to add my 2c.

IEEE802.15.4e TSCH makes a subtle distinction between a *link *("a single
slot scheduled from mote A to mote B") and a *path *("union of all links
between A and B"). A link is attached a <neighbor, slotOffset,
channelOffset, TX|RX> tuple [1]. If multiple links are scheduled to the
same neighbor, they are typically equivalent, i.e. the MAC layer sends the
packet on whichever of these links happens to show up after the packet was
put in the MAC queue. Since the slotframe repeats over time (and the length
of the slotframe is typically constant), each *link* gives you a "quantum"
of bandwidth to a given neighbor. By modifying the number of links in a *
path*, you modify the resources allocated between two neighbors.

The TSCH standard is *extremely* flexible, and you can implement lots of
fanciness within the standard. Implementations can for example keep
per-link statistics: at any time, you can know how many packets you
sent/received, for each neighbor and for each link. Based on this
information, you can play with the queuing behavior (e.g. wait for this
link to show up because this one is behaving bad), or with the schedule
(e.g. link 14 to neighbor A is worse than all the other to this neighbor,
let's talk to mote A to replace it with another one). TSCH really only
defines how to execute the schedule, so there's lots (and lots) of room for
defining behavior.

Maybe too much room to be handled entirely by RPL. As I see it, RPL only
wants to know about some cost associated with the topology, and uses that
to compute multi-hop routes. In particular, I believe RPL is more
interested in *paths* (the "performance" of the connection between two
neighbors), rather than the individual *links *making up each path. In my
opinion (and this is, I believe, perfectly in line with *Xavi*'s comment),
we could define a *6tsch* layer which sits between TSCH and RPL. The goal
of this layer would be to (1) turn some throughput requirements into *links
*in the schedule and (2) collect information and feedback *path* statistics
to RPL.

Implementations of this layer can be all over the spectrum: it can be
controlled by an outside (central) scheduler, it can implement some
neighbor-to-neighbor communication to set up a schedule in a distributed
fashion, or anything in-between. The goal is, I believe, to avoid for RPL
to have to specify the exact slot to send on, RPL tells the *6tsch* layer
to "send this packet to neighbor A".

To come back to *Michael*'s comment, I believe that, with this setup, RPL
actually can be using traditional metrics (ETX, bandwidth, latency, etc),
the *6tsch* layer taking care of MAC specifics.

One last thing I believe is important: what TSCH *does* define is how to
frequency hop. At each occurrence of a slot in the slotframe, the frequency
to communicate on is recalculated [2], and is different from the last time.
This means that neither the *6tsch* layer nor RPL need to worry about the
actual frequency to communicate on; the schedule just looks like a grid.

I realize now this became a quite long e-mail, thanks for ready through
here!

Thoughts?

Thomas

[1] IEEE802.15.4e, Section 6.2.19.3
[2] IEEE802.15.4e, Section 5.1.1a

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 29 Jan 2013 21:14:03 +0000

Thomas,

for sure it is a long email, but full of interesting info and thoughts!

I totally agree with you about the idea of having a 6tsch layer, between TSCH and RPL. Actually, TASA (Traffic-Aware Scheduling Algorithm [1-3]) is built on such idea.

TASA is a centralized scheduling algorithm, running on a master node in a IEEE802.1.5.4e network. It allows to build TSCH schedule, based on the network topology and the traffic load. Thus, it uses the information related to the paths, coming from RPL, and those related to the traffic (i.e., average traffic load generated by each node) in order to provide time slots/channel hops patterns, able to fulfill given requirements (i.e., duty cycle, throughput, etc.) .

You can find more info and details here:

  *   [1] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; Grieco, Luigi Alfredo; Boggia, Gennaro: Traffic Aware Scheduling Algorithm for Multi-Hop IEEE 802.15.4e Networks<http://publications.uni.lu/record/9659>, Personal Indoor and Mobile Radio Communications (PIMRC), 2012 IEEE 23rd International Symposium on, 2012, pp. 327-332
  *   [2] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; Grieco, Luigi Alfredo; Boggia, Gennaro: Traffic-Aware Time-Critical Scheduling In Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT<http://publications.uni.lu/record/9689>, Proc. of IEEE Sensors 2012, 2012.
  *   [3] Accettura, Nicola; Palattella, Maria Rita; Dohler, Mischa; Grieco, Luigi Alfredo; Boggia, Gennaro: Standardized Power-Efficient & Internet-Enabled Communication Stack for Capillary M2M Networks<http://publications.uni.lu/record/8095>, Proc. of IEEE WCNC 2012, Workshop on Internet of Things Enabling Technologies, 2012, pp. 226-231, ISBN: 978-1-4673-0681-2

Of course, I will be more than happy in providing more information, and discuss more about TASA in case you may find in it a possible solution to our problem (or at least, part of the problem)!

Best Regards,
Maria Rita

________________________________
From: [email-masked] [[email-masked]] on behalf of Thomas Watteyne [[email-masked]]
Sent: Tuesday, January 29, 2013 9:04 PM
To: [email-masked]
Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

Nick, Michael,

IEEE802.15.4e TSCH makes a subtle distinction between a link ("a single slot scheduled from mote A to mote B") and a path ("union of all links between A and B"). A link is attached a <neighbor, slotOffset, channelOffset, TX|RX> tuple [1]. If multiple links are scheduled to the same neighbor, they are typically equivalent, i.e. the MAC layer sends the packet on whichever of these links happens to show up after the packet was put in the MAC queue. Since the slotframe repeats over time (and the length of the slotframe is typically constant), each link gives you a "quantum" of bandwidth to a given neighbor. By modifying the number of links in a path, you modify the resources allocated between two neighbors.

The TSCH standard is *extremely* flexible, and you can implement lots of fanciness within the standard. Implementations can for example keep per-link statistics: at any time, you can know how many packets you sent/received, for each neighbor and for each link. Based on this information, you can play with the queuing behavior (e.g. wait for this link to show up because this one is behaving bad), or with the schedule (e.g. link 14 to neighbor A is worse than all the other to this neighbor, let's talk to mote A to replace it with another one). TSCH really only defines how to execute the schedule, so there's lots (and lots) of room for defining behavior.

Maybe too much room to be handled entirely by RPL. As I see it, RPL only wants to know about some cost associated with the topology, and uses that to compute multi-hop routes. In particular, I believe RPL is more interested in paths (the "performance" of the connection between two neighbors), rather than the individual links making up each path. In my opinion (and this is, I believe, perfectly in line with Xavi's comment), we could define a 6tsch layer which sits between TSCH and RPL. The goal of this layer would be to (1) turn some throughput requirements into links in the schedule and (2) collect information and feedback path statistics to RPL.

Implementations of this layer can be all over the spectrum: it can be controlled by an outside (central) scheduler, it can implement some neighbor-to-neighbor communication to set up a schedule in a distributed fashion, or anything in-between. The goal is, I believe, to avoid for RPL to have to specify the exact slot to send on, RPL tells the 6tsch layer to "send this packet to neighbor A".

To come back to Michael's comment, I believe that, with this setup, RPL actually can be using traditional metrics (ETX, bandwidth, latency, etc), the 6tsch layer taking care of MAC specifics.

One last thing I believe is important: what TSCH does define is how to frequency hop. At each occurrence of a slot in the slotframe, the frequency to communicate on is recalculated [2], and is different from the last time. This means that neither the 6tsch layer nor RPL need to worry about the actual frequency to communicate on; the schedule just looks like a grid.

I realize now this became a quite long e-mail, thanks for ready through here!

Thoughts?

Thomas

On Tue, Jan 29, 2013 at 6:05 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

>>>>> "Nick" == Nick Moore <[email-masked]<mailto:[email-masked]>> writes:
    Nick> * Should all this

A number of reasons.

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works

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

---

From: Nick Moore <[email-masked]>
Date: Wed, 30 Jan 2013 14:29:42 +1100

On 30/01/13 07:04, Thomas Watteyne wrote:
>
> Maybe too much room to be handled entirely by RPL. As I see it, RPL 
> only wants to know about some cost associated with the topology, and 
> uses that to compute multi-hop routes. In particular, I believe RPL is 
> more interested in /paths/ (the "performance" of the connection 
> between two neighbors), rather than the individual /links /making up 
> each path. In my opinion (and this is, I believe, perfectly in line 
> with *Xavi*'s comment), we could define a /6tsch/ layer which sits 
> between TSCH and RPL. The goal of this layer would be to (1) turn some 
> throughput requirements into /links /in the schedule and (2) collect 
> information and feedback /path/ statistics to RPL.
[...]

> To come back to *Michael*'s comment, I believe that, with this setup, 
> RPL actually can be using traditional metrics (ETX, bandwidth, 
> latency, etc), the /6tsch/ layer taking care of MAC specifics.
>

Yep, that makes sense!  And as per Michael's comments, RPL can then 
handle the routing across different L2s.

On 29/01/13 15:09, Michael Richardson wrote:
> I agree. It's just that this is a new kind of metric: in the past we 
> have things like abtracted ETX, bandwidth available, power, latency, 
> etc... none of these things are a cyclic f(t). This new info is. 

Is it appropriate for the 6tsch routing metrics to change (or as you put 
it, to be a cyclic function) *within* the period of a slotframe?

For example, if node A is trying to transmit to node D and can go via 
either node B or node C, then the "best route" may toggle back and forth 
between B and C depending on which has the next available link(s), 
potentially multiple times per slotframe period.  Is this good 
behaviour?  I guess in the LoWPAN world it might be.

I think I'd better stop asking open-ended questions now and go read some 
stuff :-)

-----Nick

-- 
Nick Moore <[email-masked]> 0409 656 267

---

From: [email-masked]
Date: Wed, 30 Jan 2013 13:37:56 -0800

Hi,

As Thomas and Xavi explained, RPL is responsible for choosing a *Path*,
i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH
provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX),
which is the mapping of a *Path*, to conduct forwarding. Thus, the missing
piece is how to establish and maintain the *Links*.  My understanding is
that 6tsch will fill the gap. In addition, considering resource
constraints of devices and characteristics of IoT, 6tsch should be very
simple and flexible for wide range of application in terms of mobility,
density, latency,and so on.

In UC@Berkeley, we have designed a protocol, called uRes. The function of
uRes is to establish and maintain the *Links* with neighbors. uRes is a
distributed protocol, i.e. the computation and communication for link
reservation just happen locally. uRes is coded in Information Elements
(IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides flexibility
for further optimization and extension. uRes has been implemented in
OpenWSN (openwsn.berkeley.edu).

Regards
Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 30 Jan 2013 16:23:57 -0800

Nick,
That's quite some cross-layering! If I understand correctly, the metric
could be function of how long until the next slot, i.e. if a slot to mote B
is closer than mote C, then I will modify my routing metric to favor mote
B. This would lead to very dynamic routing metrics, indeed.
Thomas

On Tue, Jan 29, 2013 at 7:29 PM, Nick Moore <[email-masked]> wrote:

> opinion (and this is, I believe, perfectly in line with *Xavi*'s
> comment), we could define a *6tsch* layer which sits between TSCH and
> RPL. The goal of this layer would be to (1) turn some throughput
> requirements into *links *in the schedule and (2) collect information and
> feedback *path* statistics to RPL.
>
> [...]
>
>
> RPL actually can be using traditional metrics (ETX, bandwidth, latency,
> etc), the *6tsch* layer taking care of MAC specifics.
>
>
> Yep, that makes sense!  And as per Michael's comments, RPL can then handle
> the routing across different L2s.
>
>
> I agree. It's just that this is a new kind of metric: in the past we have
> things like abtracted ETX, bandwidth available, power, latency, etc... none
> of these things are a cyclic f(t). This new info is.
>
>
> potentially multiple times per slotframe period.  Is this good behaviour?
> I guess in the LoWPAN world it might be.
>
>
> Nick Moore <[email-masked]> <[email-masked]> 0409 656 267
>
>

---

From: Nick Moore <[email-masked]>
Date: Thu, 31 Jan 2013 12:44:08 +1100

On 31/01/13 11:23, Thomas Watteyne wrote:
> Nick,
> That's quite some cross-layering! If I understand correctly, the 
> metric could be function of how long until the next slot, i.e. if a 
> slot to mote B is closer than mote C, then I will modify my routing 
> metric to favor mote B. This would lead to very dynamic routing 
> metrics, indeed.

Yeah.  So in this scenario the 6TSCH sub-layer is either:

* Telling RPL "latency is 50ms.  40ms.  30ms.  20ms.  10ms.  Boris, you 
missed your train, now it is 100ms.  90ms ..."
* Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself." 
(I think this is what Michael meant by "cyclic f(t)")

My concern with the former is that it seems very chatty.  How often is 
too often?  How often is often enough?

My concern with the latter is that it seems rather a complicated thing 
to add to RPL, especially when you've got multiple hops involved in a 
route, with potentially different and varying slotframe periods.  Any 
comments from anyone with RPL (etc) implementation experience?

My concern overall is excessively dynamic routing, indeed :-)  Is it 
sufficient for 6TSCH to tell RPL an *average* latency of slotframe 
period / 2 and leave it at that?

-----Nick

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 30 Jan 2013 17:54:50 -0800

Nick,

I would argue that 6tsch should deal with MAC layer specificities and
present an aggregate view to RPL. In TSCH, we're dealing with multiple
links to the same neighbor, which might be confusing for the routing layer
to deal with. On top of that, 6tsch might want to switch links around, in
which case maybe the metric really doesn't change from a routing point of
view.

I believe that 6tsch can express both bandwidth and latency by looking at
the schedule and the per-link statistics. That is, bandwidth would be
something like the sum of links per slotframe, weighted by the ETX on each
link. This would represent "how many packet can I get to this neighbor, per
unit time", taking into account that there might be multiple links, and
lossy links.

Taking it one step further, 6tsch could be instructed to maintain 6pkt/s to
neighbor A. If on average ETX to A is 50%, 6tsch will put in 12 link/s. If
something happens and the ETX now goes to 75%, 6tsch could remove 2 links.
All of that without requiring any intervention from RPL, and without impact
of the routing.

Thomas

On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore <[email-masked]> wrote:

> My concern with the former is that it seems very chatty.  How often is too
> often?  How often is often enough?
>
> My concern with the latter is that it seems rather a complicated thing to
> add to RPL, especially when you've got multiple hops involved in a route,
> with potentially different and varying slotframe periods.  Any comments
> from anyone with RPL (etc) implementation experience?
>
> sufficient for 6TSCH to tell RPL an *average* latency of slotframe period /
> 2 and leave it at that?
>
>
> -----Nick
> --
> ______________________________**_________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/6tsch<https://www.ietf.org/mailman/listinfo/6tsch>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 30 Jan 2013 17:59:00 -0800

Hi Nick,

I see it like Thomas, for example the 6tsch sublayer tells us:

the average latency for that link is 40ms
the latest set of packets (x) have traveled in 32ms
the max latency ever is 66ms
the min latency ever is 28ms
etc...

whit that RPL can make very clever decisions on how to build a topology.

X

On 30/01/13 17:54, Thomas Watteyne wrote:
> links to the same neighbor, which might be confusing for the routing 
> layer to deal with. On top of that, 6tsch might want to switch links 
> around, in which case maybe the metric really doesn't change from a 
> routing point of view.
>
> I believe that 6tsch can express both bandwidth and latency by looking 
> at the schedule and the per-link statistics. That is, bandwidth would 
> be something like the sum of links per slotframe, weighted by the ETX 
> on each link. This would represent "how many packet can I get to this 
> neighbor, per unit time", taking into account that there might be 
> multiple links, and lossy links.
>
> Taking it one step further, 6tsch could be instructed to maintain 
> 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will put in 
> 12 link/s. If something happens and the ETX now goes to 75%, 6tsch 
> could remove 2 links. All of that without requiring any intervention 
> from RPL, and without impact of the routing.
>
> Thomas
>
> On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         That's quite some cross-layering! If I understand correctly,
>         the metric could be function of how long until the next slot,
>         i.e. if a slot to mote B is closer than mote C, then I will
>         modify my routing metric to favor mote B. This would lead to
>         very dynamic routing metrics, indeed.
>
>
>     * Telling RPL "latency is 50ms.  40ms.  30ms.  20ms.  10ms.
>      Boris, you missed your train, now it is 100ms.  90ms ..."
>     * Telling RPL "latency is (t_0 - t) mod k ms, work it out for
>     yourself." (I think this is what Michael meant by "cyclic f(t)")
>
>     My concern with the former is that it seems very chatty.  How
>     often is too often?  How often is often enough?
>
>     My concern with the latter is that it seems rather a complicated
>     thing to add to RPL, especially when you've got multiple hops
>     involved in a route, with potentially different and varying
>     slotframe periods.  Any comments from anyone with RPL (etc)
>     implementation experience?
>
>     My concern overall is excessively dynamic routing, indeed :-)  Is
>     it sufficient for 6TSCH to tell RPL an *average* latency of
>     slotframe period / 2 and leave it at that?
>
>
>     -----Nick
>     -- 
>     Nick Moore <[email-masked] <mailto:[email-masked]>> 0409 656 267
>     [email-masked] <mailto:[email-masked]>

---

From: Nick Moore <[email-masked]>
Date: Thu, 31 Jan 2013 17:26:42 +1100

Thomas Watteyne <[email-masked]> wrote:

> I would argue that 6tsch should deal with MAC layer specificities and present an aggregate view to RPL.

I think that makes sense as an initial goal at least.

If some brave soul manages to work out a more sophisticated version that allows for the cyclic nature of TSCH latency they can always call it 6TSCHbis (pronounce *that*!)

---

From: Mischa Dohler <[email-masked]>
Date: Thu, 31 Jan 2013 15:42:44 +0100

Qin,

I like this and would like to hear more about it. Do you have some 
papers/results?

You can turn the problem as you want* but if you really want a multihop 
system to scale (beyond some 500-1000 nodes), you need a distributed 
system and some machine learning** on top. This is because in static 
link topologies, the aggregate set of locally-chosen links will converge 
eventually to the optimal path; there will be no routing solution for 
ergodic (completely dynamic) link topologies beyond DTN approaches (just 
take it); and non-ergodic (but also non-static) link topologies, where 
links are occasionally in outage, can only be handled in a distributed 
fashion.

So I am all in for seeing how you could make .15.4e & RPL work closely 
together in a distributed fashion.

Thanks,
Mischa.

* The adhoc community is very good at this: they have published zillions 
of papers, proposed millions of protocols, have loads of RFCs but no 
viable product after 50 years of work - mobility/dynamics are very 
fundamental problems which you can only solve meaningfully with one-hop 
star-topology technology ... wait ... this is cellular.

** We recently standardized some machine learning approaches in a 
broadband standard; setting was different but problem the same.

__________________________________

Mischa Dohler

Director of Research, CTTC
Distinguished Lecturer, IEEE
Editor-in-Chief, ETT
BoD, Worldsensing

Mob: +34 679 094 007
Tel: +34 936 452 909
Fax: +34 936 452 901

www.cttc.es/home/mdohler
__________________________________

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Jan 2013 11:32:53 -0500

Nick> On 29/01/13 15:09, Michael Richardson wrote:
    >> I agree. It's just that this is a new kind of metric: in the past
    >> we have things like abtracted ETX, bandwidth available, power,
    >> latency, etc... none of these things are a cyclic f(t). This new
    >> info is.

    Nick> Is it appropriate for the 6tsch routing metrics to change (or
    Nick> as you put it, to be a cyclic function) *within* the period of
    Nick> a slotframe?

Yes/No.

What I think should happen is that RPL be presented with essentially two
(possibly more! TBD) links.  It will create two DODAGs, one for the top
of the cycle, and one for the bottom of the cycle.

The routing system will then essentially need two routing tables: one
for each side of the cycle.  

    Nick> For example, if node A is trying to transmit to node D and can
    Nick> go via either node B or node C, then the "best route" may
    Nick> toggle back and forth between B and C depending on which has
    Nick> the next available link(s), potentially multiple times per
    Nick> slotframe period.  Is this good behaviour?  I guess in the
    Nick> LoWPAN world it might be.

I think it would be acceptable behaviour.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Jan 2013 11:35:05 -0500

>>>>> "Thomas" == Thomas Watteyne <[email-masked]> writes:
    Thomas> Nick, That's quite some cross-layering! If I understand
    Thomas> correctly, the metric could be function of how long until
    Thomas> the next slot, i.e. if a slot to mote B is closer than mote
    Thomas> C, then I will modify my routing metric to favor mote
    Thomas> B. This would lead to very dynamic routing metrics, indeed.

These routing metrics do not change dynamically, they change cyclically.

That's important, because it means that trickle can still be used to
efficiently flood the routing metrics.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 Jan 2013 11:39:42 -0500

>>>>> "Nick" == Nick Moore <[email-masked]> writes:
    Nick> Yeah.  So in this scenario the 6TSCH sub-layer is either:

    Nick> Telling RPL "latency is (t_0 - t) mod k ms, work it out for
    Nick> yourself." (I think this is what Michael meant by "cyclic
    Nick> f(t)")

yes.

    Nick> My concern with the former is that it seems very chatty.  How
    Nick> often is too often?  How often is often enough?

    Nick> My concern with the latter is that it seems rather a
    Nick> complicated thing to add to RPL, especially when you've got
    Nick> multiple hops involved in a route, with potentially different
    Nick> and varying slotframe periods.  Any comments from anyone with
    Nick> RPL (etc) implementation experience?

(yes, I'm an implementer, but my implementation is not well tested...)

What I hope will happen is that the cyclic f(t) in the metrics will have
a horizon of some kind.  That is, some number of hops from a given node
Q, it won't matter what happens above Q for nodes below Q.
(a diagram would help here)

Otherwise, we might have a situation where the number of routes across
a network might be 2^n, with each layer contributing another DODAG to
calculate.

---

From: Don Sturek <[email-masked]>
Date: Thu, 31 Jan 2013 08:50:26 -0800

Just a suggestion from someone monitoring the reflector.....

It would be hugely useful if the topic of the all various threads did not
all read:  " re:  Welcome to the "6tsch" mailing list".   Some of the
embedded topics in these e-mails are interesting while others I might pass
on if I knew the actual contents.....

Thanks!

Don

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 31 Jan 2013 17:52:47 +0100

Could some one refer me to an initial draft submitted if available for
this group? to make group ideas and basis for discussions,

I usually prefer joining discussions that at least have an I-D on table :)

Thanking you.
AB

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 31 Jan 2013 09:24:49 -0800

Don,

Thanks for the suggestion. We got a bit carried away :)

Thomas

---

From: Kris Pister <[email-masked]>
Date: Thu, 31 Jan 2013 15:29:26 -0800

I agree that both of those mechanisms of communicating to RPL have 
issues.  However, an interface that exposes the underlying cell matrix 
(link schedule) and time base seems like a requirement in any case.  One 
of the big benefits of tsch is the availability of a shared sense of 
time across the network.  This has important benefits to applications 
(sequence of events detection, feedback control, global timestamps, ...) 
as well as security (replay, joining, broadcast authentication), and 
others.
So for sure we need a mechanism where network time can be exposed to 
higher layers.  We also need a mechanism to expose the schedule, because 
for many applications the higher layer is going to want to do something 
in relation to radio slot activity.  For example, schedule a radar tank 
measurement at a time when there is no mote radio activity, or take a 
data sample right before a TX link to maximize freshness.

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

ksjp

---

From: Kris Pister <[email-masked]>
Date: Thu, 31 Jan 2013 15:31:24 -0800

And let's not forget about power and energy.

I'm sorry Dave, but I'm afraid that I can't do that right now.

ksjp

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 31 Jan 2013 18:41:16 -0500

Qin,

Thanks for bringing up uRes. There are many out there that argue that TSCH (and any other media allocation scheme that has TDNA based DNA) is not inherently well suited for (mesh, multi-path) network that rely on distributed routing decisions. They claim that TSCH can only be efficiently utilized in highly deterministic systems in which a central computation engine (that includes a link scheduler) makes all the decisions in the network. The analogy used is one to Smart Objects being automatic pianos that play the music sheet that this computation engine puts in front of them.

In my experience, TSCH renders itself very well to a combination of both namely a central arbitration and distributed intelligence. The WLAN coordinator (which typically resides in the LBR) is responsible for  setting up a network maintenance slotframe (used for enhanced beacons, etc). The Smart Object form/maintain/select the links locally.

In terms of the interaction between TSCH and RPL there is little coordination needed, since RPL does not need to be aware of the underlying TSCH schedule. 

The coordination needed consists in (recommended, not mandatory):

1. Ensuring that the RPL DODAG parent is the current 802.15.4e coordinator  
2. Defining some sort of informative service access point that allows the MAC to feed various metrics collected to RPL

When we designed our RPL_over_TSCH Smart Object platform, we also identified a need to define additional IEs (which is fully condoned and encouraged by 4e) that would allow TSCH Smart Objects to better coordinate and accommodate the MAC agnostic RPL layer.

Robert Assimiti
Nivis
Director of Technology and Standards
Office [678]-202-6859
Mobile [404]-578-0205

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 30, 2013 4:38 PM
To: Nick Moore
Cc: [email-masked]
Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

Hi,

As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX), which is the mapping of a *Path*, to conduct forwarding. Thus, the missing piece is how to establish and maintain the *Links*.  My understanding is that 6tsch will fill the gap. In addition, considering resource constraints of devices and characteristics of IoT, 6tsch should be very simple and flexible for wide range of application in terms of mobility, density, latency,and so on.

In UC@Berkeley, we have designed a protocol, called uRes. The function of uRes is to establish and maintain the *Links* with neighbors. uRes is a distributed protocol, i.e. the computation and communication for link reservation just happen locally. uRes is coded in Information Elements
(IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides flexibility for further optimization and extension. uRes has been implemented in OpenWSN (openwsn.berkeley.edu).

Regards
Qin

>> uses that to compute multi-hop routes. In particular, I believe RPL 
>> is more interested in /paths/ (the "performance" of the connection 
>> between TSCH and RPL. The goal of this layer would be to (1) turn 
>> some throughput requirements into /links /in the schedule and (2) 
>> collect information and feedback /path/ statistics to RPL.
> [...]
>
> Is it appropriate for the 6tsch routing metrics to change (or as you 
> put it, to be a cyclic function) *within* the period of a slotframe?
>
> either node B or node C, then the "best route" may toggle back and 
> forth between B and C depending on which has the next available 
> link(s), potentially multiple times per slotframe period.  Is this 
> good behaviour?  I guess in the LoWPAN world it might be.
>
>
> I think I'd better stop asking open-ended questions now and go read 
> some stuff :-)
>
> -----Nick
>
> --

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 31 Jan 2013 18:46:45 -0500

Thomas,

I full heartedly second everything that you stated.

Robert

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, January 30, 2013 8:55 PM
To: [email-masked]
Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

Nick,

I would argue that 6tsch should deal with MAC layer specificities and present an aggregate view to RPL. In TSCH, we're dealing with multiple links to the same neighbor, which might be confusing for the routing layer to deal with. On top of that, 6tsch might want to switch links around, in which case maybe the metric really doesn't change from a routing point of view.

I believe that 6tsch can express both bandwidth and latency by looking at the schedule and the per-link statistics. That is, bandwidth would be something like the sum of links per slotframe, weighted by the ETX on each link. This would represent "how many packet can I get to this neighbor, per unit time", taking into account that there might be multiple links, and lossy links.

Taking it one step further, 6tsch could be instructed to maintain 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will put in 12 link/s. If something happens and the ETX now goes to 75%, 6tsch could remove 2 links. All of that without requiring any intervention from RPL, and without impact of the routing.

Thomas
On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore <[email-masked]<mailto:[email-masked]>> wrote:
On 31/01/13 11:23, Thomas Watteyne wrote:
Nick,
That's quite some cross-layering! If I understand correctly, the metric could be function of how long until the next slot, i.e. if a slot to mote B is closer than mote C, then I will modify my routing metric to favor mote B. This would lead to very dynamic routing metrics, indeed.

* Telling RPL "latency is 50ms.  40ms.  30ms.  20ms.  10ms.  Boris, you missed your train, now it is 100ms.  90ms ..."
* Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself." (I think this is what Michael meant by "cyclic f(t)")

My concern with the former is that it seems very chatty.  How often is too often?  How often is often enough?

My concern with the latter is that it seems rather a complicated thing to add to RPL, especially when you've got multiple hops involved in a route, with potentially different and varying slotframe periods.  Any comments from anyone with RPL (etc) implementation experience?

My concern overall is excessively dynamic routing, indeed :-)  Is it sufficient for 6TSCH to tell RPL an *average* latency of slotframe period / 2 and leave it at that?

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

---

From: Robert Assimiti <[email-masked]>
Date: Thu, 31 Jan 2013 18:59:12 -0500

This is where dedicated and shared slots come into play at the TSCH.

In TSCH, all slots and are links are created equal. One could devise a scheme where slots could be shared or dedicated. Dedicated slots could also be prioritized.

These would allow a 6TSCHbis device to be able to guarantee latencies.

Robert Assimiti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nick Moore
Sent: Thursday, January 31, 2013 1:27 AM
To: IETF 6TSCH
Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

--
Nick Moore  <[email-masked]>  (+61) 409 656 267 _______________________________________________
6tsch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Nick Moore <[email-masked]>
Date: Fri, 01 Feb 2013 11:22:25 +1100

> this group? to make group ideas and basis for discussions,

I think this is more of a virtual BOF so far, and we're still trying to 
work out the scope of the proposed WG.
Anyone here got any further documents to put on the table?

(I'm paraphrasing several very long, detailed and interesting posts 
here, probably inaccurately, so with apologies to the authors ...)

The main divide in the conversation so far seems to be whether 6TSCH is:

a) a "shim" between RPL and 4e's TSCH, requiring no mods to RPL but only 
able to express the "aggregate" behaviour of a link across the entire 
slotframe.
     or
b) an extension to RPL to make it TSCH aware, allowing for fine control 
of latencies within slotframes.

Also, a couple of people have brought up protocols building TSCH 
networks, do we think this is in scope for 6TSCH or is 6TSCH only 
concerned with passively optimizing for the networks built by these 
protocols?

-----Nick

---

From: Nick Moore <[email-masked]>
Date: Fri, 01 Feb 2013 11:23:23 +1100

On 01/02/13 10:29, Kris Pister wrote:
> higher layers.

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

-----Nick

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 31 Jan 2013 16:28:38 -0800

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.

---

From: Kris Pister <[email-masked]>
Date: Thu, 31 Jan 2013 16:30:55 -0800

Agree.  My hope is that we define a very simple shared slot system for 
network joining, and then define the mechanism for adding additional 
links, be they shared or dedicated.
Once we have that in place it will be easy for people to get networks up 
and running, and also easy to try out new ideas for optimizing performance.

The advertising information element contains a superframe length, and a 
small number (one?) of shared links.  This provides a duty-cycled 
slotted-aloha MAC, with a duty cycle controlled by the choice of 
superframe length.  For some applications this is all they need.  One 
slot every 100ms gets you a few percent duty cycle and sub-second 
multi-hop response time in low-traffic networks.  DIOs, DAOs, RAs, etc. 
all use the shared bandwidth.

With that as initial synchronization and discovery, then very fancy 
things can be built on top, either with distributed, centralized, or 
(for me ideally) hybrid approaches, with either dedicated, shared, or 
mixed links.  Such a big playground!

ksjp

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 31 Jan 2013 17:50:02 -0800

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.
>
>
>