Subject: Re: [6tsch] Dynamic Channel Allocation

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Feb 2013 12:59:41 -0500

>>>>> "Pascal" == Pascal Thubert <[email-masked]> writes:
    Pascal> The shim layer that was already discussed has a lot of value
    Pascal> to enable that virtualization and dynamic allocation. On
    Pascal> principle I'm all for it. I'm just unclear how much of it is
    Pascal> above IP (like we placed ND above IP as opposed to ARP) and
    Pascal> how mush is under IP, the the 15.4 IEs. Could there be an IP
    Pascal> abstraction that we could reuse in other similar link
    Pascal> layers?

I don't understand this shim layer.
Can it actually be observed outside of the node?

It seems to me that's it's just an API layer between a radio MAC and an
IP routing layer.

if it's observable, then it's "6lowpan-over-tsch" specification, or some
other "IPv6-over-foo" adaptation layer.

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

---

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

Hello Michael:

Over the radio, an actual negotiation will take place between RPL parent and child, or between parent and central route computer (PCE), to match the need for bandwidth in timeslot allocations. For completeness of the architecture, we want to describe that interaction, even if in the end we determine that it is best specified in the form of Information Elements below IP.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: mardi 5 février 2013 19:00
To: IETF 6TSCH
Subject: Re: [6tsch] Dynamic Channel Allocation

It seems to me that's it's just an API layer between a radio MAC and an IP routing layer.

if it's observable, then it's "6lowpan-over-tsch" specification, or some other "IPv6-over-foo" adaptation layer.

---

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

>>>>> "pthubert" == pthubert  <Pascal> writes:
    pthubert> Over the radio, an actual negotiation will take place
    pthubert> between RPL parent and child, or between parent and
    pthubert> central route computer (PCE), to match the need for

Yes, sure, I know that RPL travels over the wire.
That's wasn't the question.

How can I tell from watching the wire if there is a "tsch-shim" inplace
or not?  If I can't tell, then it's not the subject for standards work.

---

From: Kris Pister <[email-masked]>
Date: Tue, 05 Feb 2013 12:47:55 -0800

Somehow the sender and receiver need to agree on the tsch cell 
{superframe, slot, channel, options} that they will use to communicate.  
There are a lot of ways to do this:
1) implicit -  I listen for traffic, detect patterns, and figure out the 
links.  Tough, inefficient, but theoretically possible
2) L2 communicated - using the Information Elements from 4e: "add link 
{frame=1, slot=22, channel=3, unicast_RX}".  You'd see that "on the 
wire" where wire=wireless.
3) L3 communicate - options in RPL headers?  doesn't sound right to me, 
but maybe.  commands travel at layer 3, L2 gets told via management 
interface
4) MPLS, RSVP-TE, ... - again, higher layer carries commands
5) as in 3 or 4, but with the request carried by the higher layer, and 
L2 responsible for the actual negotiation
6) centralized scheduling - known not to work*
7) etc.

ksjp

* for those who don't know me or Dust: this is a joke

On 2/5/2013 11:17 AM, Michael Richardson wrote:
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Tom Phinney <[email-masked]>
Date: Tue, 05 Feb 2013 14:15:51 -0700

I disagree. If it's a means of adapting one
standard to interface to another, then whether it is a standard or
an informational document, it serves to align implementers so that
interoperability is more likely, rather than less likely.

In other words, an inadequate implementation of this interfacing
shim IS observable, but only via the occurrence of erroneous
behavior. So when there is not any implementation error, such a shim
might be unobservable. Given the complexity and subtlety of most
standards, at least around the edges, and the hubris and naïveté of
many young 'hot shot" implementers, such errors are not unlikely
when such guidance is missing.

===

On 2013.02.05 12:17, Michael Richardson wrote:

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Feb 2013 07:25:47 +0000

Hi:

And the trend we've seen so far in the list is that we'll probably end up with the need to cohabit a well-architected mix:

2) would carry the gory details that are specific to TSCH. We'll need to correlate an IP flow with the time slot and back so that an IP packet that belongs to a certain sequence of time slots stays in that sequence.

3) would carry path level metrics and reservation. The reservation corresponds to a flow and locks resources along a path that can be discovered or source routed. Forwarding is performed under the reservation constraints, as indexed by the flow. Instances may not be enough and we probably want something additional. And then we may need a new OF.

4) May be the way we actually implement per flow routing. For instance, an incoming slot can be associated to a local label, which is mapped to an outgoing label, which in turn is mapped to an outgoing time slot. This label may never reach the air, but the operation has to be described so as to make the abstraction safe to implement (as Tom indicates) and reusable across deterministic MACs.

6) may have to be more than one protocol, depending on which installed base we want to collocate with. For instance, can we 'export' the map that WiHART or ISA100 PCE (system manager) has locked, so as to either apply it ourselves to the network, or at least blacklist those allocations.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: mardi 5 février 2013 21:48
To: [email-masked]
Subject: Re: [6tsch] Dynamic Channel Allocation

Somehow the sender and receiver need to agree on the tsch cell {superframe, slot, channel, options} that they will use to communicate.  There are a lot of ways to do this:
1) implicit -  I listen for traffic, detect patterns, and figure out the links.  Tough, inefficient, but theoretically possible
2) L2 communicated - using the Information Elements from 4e: "add link {frame=1, slot=22, channel=3, unicast_RX}".  You'd see that "on the wire" where wire=wireless.
3) L3 communicate - options in RPL headers?  doesn't sound right to me, but maybe.  commands travel at layer 3, L2 gets told via management interface
4) MPLS, RSVP-TE, ... - again, higher layer carries commands
5) as in 3 or 4, but with the request carried by the higher layer, and L2 responsible for the actual negotiation
6) centralized scheduling - known not to work*
7) etc.

ksjp

6tsch mailing list

[email-masked]<mailto:[email-masked]>

---

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

Kris,

I would vote for 2 namely L2 communicated.

In a stalin-esque, fully deterministic network it would be the PCE that computes and imparts IE (communication schedule, slotfraems, links, etc) to the motes (paradigm used in ISA100.11a and WiHART).

When wanting to rely on distributed intelligence and management, it would be local 802.15.4 coordinator (not to  be confused with the PAN coordinator) that would impart  these IEs to the motes it coordinates. The coordinated motes could negotiate these management settings with the coordinator.

How would one know if the shim is there or not? That is a very good question. I suggest augmenting an existing IE or creating a new one that would let other entities know of the device's capability.

Robert Assimiti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: Tuesday, February 05, 2013 3:48 PM
To: [email-masked]
Subject: Re: [6tsch] Dynamic Channel Allocation

ksjp

6tsch mailing list

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 6 Feb 2013 14:55:49 -0800

Pascal,

These are all interesting ideas. I understand these might be just ideas,
but allow me to ask you some clarifying questions.

2) "certain sequence of time slots stays in that sequence" The TSCH
standard defines the concept of multiple slotframes in the same network,
and although it's not defined as such in the standard, you can add a
parameter to the DATA_REQUEST (i.e. the send function) indicating which
slotframe you would like a specific packet sent on. This would allow for
completely independent data flows. Does this align with what you were
thinking? This could also apply to your 3).

4) I like that a lot: label switching with labels being slot identifiers. I
know that Xavi and gang have written some papers in that direction. Maybe
Xavi would like to elaborate.

Thomas

On Tue, Feb 5, 2013 at 11:25 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hi:****
>
> ** **
>
> And the trend we’ve seen so far in the list is that we’ll probably end up
> with the need to cohabit a well-architected mix:****
>
> ** **
>
> 2) would carry the gory details that are specific to TSCH. We’ll need to
> correlate an IP flow with the time slot and back so that an IP packet that
> belongs to a certain sequence of time slots stays in that sequence.****
>
> ** **
>
> 3) would carry path level metrics and reservation. The reservation
> corresponds to a flow and locks resources along a path that can be
> discovered or source routed. Forwarding is performed under the reservation
> constraints, as indexed by the flow. Instances may not be enough and we
> probably want something additional. And then we may need a new OF. ****
>
> ** **
>
> 4) May be the way we actually implement per flow routing. For instance, an
> incoming slot can be associated to a local label, which is mapped to an
> outgoing label, which in turn is mapped to an outgoing time slot. This
> label may never reach the air, but the operation has to be described so as
> to make the abstraction safe to implement (as Tom indicates) and reusable
> across deterministic MACs. ****
>
>  ****
>
> 6) may have to be more than one protocol, depending on which installed
> base we want to collocate with. For instance, can we ‘export’ the map that
> WiHART or ISA100 PCE (system manager) has locked, so as to either apply it
> ourselves to the network, or at least blacklist those allocations.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Kris Pister
> *Sent:* mardi 5 février 2013 21:48
> *To:* [email-masked]
>
> *Subject:* Re: [6tsch] Dynamic Channel Allocation****
>
>  ** **
>
> {frame=1, slot=22, channel=3, unicast_RX}".  You'd see that "on the wire"
> where wire=wireless.
> * for those who don't know me or Dust: this is a joke****
>
>  On 2/5/2013 11:17 AM, Michael Richardson wrote:****
>
> ** **
>
> ** **
>
> ** **
>
> Yes, sure, I know that RPL travels over the wire.****
>
> That's wasn't the question.****
>
> ** **
>
> How can I tell from watching the wire if there is a "tsch-shim" inplace****
>
> or not?  If I can't tell, then it's not the subject for standards work.****
>
> ** **
>
>
>
>
> ****
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>

---

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

Robert,

Assuming a stalin-esque setting with a central PCE indicating what each
mote has to do. What transport mechanism do you envision being used to
transfer "orders" to sepcific motes. You state IE, but this is still very
MAC centric and doesn't travel multiple hops, right? What would you think
about some higher layer (e.g. CoAP) mechanism to do that?

In your second setup, do you envision a multi-tier system with local
coordinators and cluster forming around them. Pascal's view of a MPLS/RSVP
type reservation system takes that one step further in that all motes are
equal and there is, in essence, no function hierarchy in the network. What
are your thoughts on how these approaches would compare?

Thomas

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

> Kris,****
>
> ** **
>
> I would vote for 2 namely L2 communicated. ****
>
> ** **
>
> In a stalin-esque, fully deterministic network it would be the PCE that
> computes and imparts IE (communication schedule, slotfraems, links, etc) to
> the motes (paradigm used in ISA100.11a and WiHART).****
>
> ** **
>
> When wanting to rely on distributed intelligence and management, it would
> be local 802.15.4 coordinator (not to  be confused with the PAN
> coordinator) that would impart  these IEs to the motes it coordinates. The
> coordinated motes could negotiate these management settings with the
> coordinator.****
>
> ** **
>
> How would one know if the shim is there or not? That is a very good
> question. I suggest augmenting an existing IE or creating a new one that
> would let other entities know of the device’s capability.****
>
> ** **
>
> ** **
>
> ** **
>
> *Robert Assimiti*
>
> * *
>
> *Sent:* Tuesday, February 05, 2013 3:48 PM
> *To:* [email-masked]
>

 <https://www.ietf.org/mailman/listinfo/6tsch>

---

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

Hi all,

I give some update on our work on Label Switching on top of 15.4e.

some time back we were looking on how to map a MPLS/RSVP-TE architecture 
on top of 15.4e, the benefits of such architecture are that setting a 
path from one node to another (maybe the sink) is totally equivalent to 
setup a schedule in the network, i.e each node has X links to its parent 
so the path exists and meets the required bandwidth. It turned out that 
this already existed in optical networks, GMPLS extended MPLS to support 
the concept of time-slot, RSVP-TE is used then to distribute labels that 
instead of being attached at every packet are kept in the nodes in the 
form of a table where a path is described by mapping input time slots to 
output time slots. This means that a node, that receives a packet at 
time slot X from node A, and sends at time slot Y to node B is part of a 
path between A and B. With that table the MPLS architecture can be emulated.

This idea is really interesting as then, RSVP-TE on top of RPL can be 
used to distribute labels, setup paths an add integrated services into 
the network.

6TSCH is then the sublayer that provides the information to establish 
the one hop connectivity and feeds RSVP and RPL so they can change and 
accommodate to the dynamics of the network.

We have a paper under the last review round with some simulation 
results. As soon as this is published I will circulate it to the list if 
someone is interested.

regards,
Xavi

On 06/02/13 14:55, Thomas Watteyne wrote:
> Pascal,
>
> These are all interesting ideas. I understand these might be just 
> ideas, but allow me to ask you some clarifying questions.
>
> standard defines the concept of multiple slotframes in the same 
> network, and although it's not defined as such in the standard, you 
> can add a parameter to the DATA_REQUEST (i.e. the send function) 
> indicating which slotframe you would like a specific packet sent on. 
> This would allow for completely independent data flows. Does this 
> align with what you were thinking? This could also apply to your 3).
>
> 4) I like that a lot: label switching with labels being slot 
> identifiers. I know that Xavi and gang have written some papers in 
> that direction. Maybe Xavi would like to elaborate.
>
> Thomas
>
> On Tue, Feb 5, 2013 at 11:25 PM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi:
>
>     And the trend we've seen so far in the list is that we'll probably
>     end up with the need to cohabit a well-architected mix:
>
>     2) would carry the gory details that are specific to TSCH. We'll
>     need to correlate an IP flow with the time slot and back so that
>     an IP packet that belongs to a certain sequence of time slots
>     stays in that sequence.
>
>     discovered or source routed. Forwarding is performed under the
>     reservation constraints, as indexed by the flow. Instances may not
>     be enough and we probably want something additional. And then we
>     may need a new OF.
>
>     4) May be the way we actually implement per flow routing. For
>     instance, an incoming slot can be associated to a local label,
>     which is mapped to an outgoing label, which in turn is mapped to
>     an outgoing time slot. This label may never reach the air, but the
>     operation has to be described so as to make the abstraction safe
>     to implement (as Tom indicates) and reusable across deterministic
>     MACs.
>
>     6) may have to be more than one protocol, depending on which
>     installed base we want to collocate with. For instance, can we
>     'export' the map that WiHART or ISA100 PCE (system manager) has
>     locked, so as to either apply it ourselves to the network, or at
>     least blacklist those allocations.
>
>     Cheers,
>
>     Pascal
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     *On Behalf Of *Kris Pister
>     *To:* [email-masked] <mailto:[email-masked]>
>
>
>     *Subject:* Re: [6tsch] Dynamic Channel Allocation
>
>     {superframe, slot, channel, options} that they will use to
>     communicate.  There are a lot of ways to do this:
>
>
>     1) implicit -  I listen for traffic, detect patterns, and figure
>     out the links.  Tough, inefficient, but theoretically possible
>     2) L2 communicated - using the Information Elements from 4e: "add
>     link {frame=1, slot=22, channel=3, unicast_RX}".  You'd see that
>     "on the wire" where wire=wireless.
>     3) L3 communicate - options in RPL headers?  doesn't sound right
>     to me, but maybe.  commands travel at layer 3, L2 gets told via
>     management interface
>     5) as in 3 or 4, but with the request carried by the higher layer,
>     and L2 responsible for the actual negotiation
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

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

Thomas,

You are correct.
IEs can only be used to disseminate:

1.      General settings that apply to the entire WPAN/WLAN -> in this case they could be embedded in headers that travel over multiple hops

2.      Local settings: local coordinator to device being managed -> one hop

In deterministic networks one would have to rely on a management entity that manipulates a MIB. This would most definitely be an application layer construct and COAP is definitely a viable option.

In distributed or hybrid WPAN/WLANs one could use both the IE and the application layers mechanism in order to distribute settings. Local coordinators only coordinate devices that associate with it directly -> only one hop away (not a sub-tree or devices that are multiple hops away).

Thks

Robert Assimiti
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, February 06, 2013 6:04 PM
To: IETF 6TSCH
Subject: Re: [6tsch] Dynamic Channel Allocation

Robert,

Assuming a stalin-esque setting with a central PCE indicating what each mote has to do. What transport mechanism do you envision being used to transfer "orders" to sepcific motes. You state IE, but this is still very MAC centric and doesn't travel multiple hops, right? What would you think about some higher layer (e.g. CoAP) mechanism to do that?

In your second setup, do you envision a multi-tier system with local coordinators and cluster forming around them. Pascal's view of a MPLS/RSVP type reservation system takes that one step further in that all motes are equal and there is, in essence, no function hierarchy in the network. What are your thoughts on how these approaches would compare?

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

Robert Assimiti

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kris Pister
Sent: Tuesday, February 05, 2013 3:48 PM
To: [email-masked]<mailto:[email-masked]>

ksjp

6tsch mailing list