Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 8 Dec 2015 14:55:54 +0000

I had a hard time mapping from the points in my review to the issues tracked in bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/

In particular, I don't see where these comments were addressed:

1. Goals and requirements are unclear

The requirements for this document are unclear to me.  Exactly what
services would a "minimal mode of operation" provide?  The Abstract and
most of the document talks about the operation of an IEEE 802.15.4 TSCH
network, yet the title of the document is "Minimal 6TiSCH Configuration".
Does a network that follows these rules provide an L2 IEEE 802.15.4
service, an IPv6 6TiSCH service, ???

Related to this question, does this document describe "a minimal set of
rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of
operation" (both text snippets from the Abstract).

2. Requirement for RPL is ill-advised

This document seems to be focused on IEEE 802.15.4 TSCH operational
parameters.  Yet, it calls for the use of RPL, which seems to me to be a
highly undesirable entangling of protocols at different layers of the
protocol stack.  IEEE 802.15.4 TSCH is expected to be used in networks
that don't use RPL.

My understanding of the document is that RPL is assumed to be in use
because it is required in a 6TiSCH network.  RPL is then used to generate
the Join Priority through the DAGRank function as specified in section
7.2.  The use of RPL implies to me the configuration and operation of a
full IPv6 stack, which hardly seems like a minimal mode of operation for
IEEE 802.15.4 TSCH.

I looked at draft-ietf-6tisch-minimal-13, and I see that there are no changes to the abstract or the introduction.  As I read that text, this document is intended to give minimal operational parameters for IEEE802.15.4 TSCH.  However, the title of the document is "Minimal 6TiSCH Configuration" and the content goes far beyond the parameters needed to run IEEE802.15.4 TSCH.  As an aside, I don't see any mention of TiSCH or 6TiSCH in the document, other than in the title.

I really need to get clarity on the purpose and scope of the document before I can continue my re-review.

- Ralph

> On Nov 30, 2015, at 7:20 AM 11/30/15, 6tisch issue tracker <[email-masked]> wrote:
> 
> #40: Ralph's INT AREA review on minimal
> 
> 
> Comment (by [email-masked]):
> 
> Xavi addressed comments one by one, tracked under bitbucket as
> https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/
> All issues are solved but the intended status that we will track with a
> separate ticket
> 
> --
> -----------------------------------+------------------------------------
> Reporter:  [email-masked]     |       Owner:  [email-masked]
>    Type:  defect                 |      Status:  new
> Priority:  major                  |   Milestone:  milestone1
> Component:  minimal                |     Version:  1.0
> Severity:  Submitted WG Document  |  Resolution:
> Keywords:                         |
> -----------------------------------+------------------------------------
> 
> Ticket URL: <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40#comment:1>
> 6tisch <https://tools.ietf.org/6tisch/>
> IPv6 over the TSCH mode of IEEE 802.15.4e
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Dec 2015 08:58:13 +0000

Hello Ralph:

> I had a hard time mapping from the points in my review to the issues 
> tracked in bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/
> 
> services would a "minimal mode of operation" provide?  The Abstract 
> and  most of the document talks about the operation of an IEEE 
> 802.15.4 TSCH  network, yet the title of the document is "Minimal 6TiSCH Configuration".
>  Related to this question, does this document describe "a minimal set 
> of  rules to operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of  operation"
> (both text snippets from the Abstract).

This issue is related with the next. I'll be proposing text at the end of this mail;

> parameters.  Yet, it calls for the use of RPL, which seems to me to be 
> a  highly undesirable entangling of protocols at different layers of the  protocol stack.
> IEEE 802.15.4 TSCH is expected to be used in networks  that don't use RPL.
> 

6TiSCH includes the mesh support by default, which is kind of natural for 802.15.4 as opposed to, say, Bluetooth.
So we care to get interoperation at that level as well and include that in the minimum support. 

6TiSCH was put together to address the NBMA nature of the multihop network as opposed to considering only one hop, like BTLE does, which would probably be have been 6lo work. 

> because it is required in a 6TiSCH network.  RPL is then used to 
> generate  the Join Priority through the DAGRank function as specified 
> in section  7.2.  The use of RPL implies to me the configuration and 
> operation of a  full IPv6 stack, which hardly seems like a minimal mode of operation for  IEEE 802.15.4 TSCH.

Looks like a definition issue, maybe we can reword the intro. An abstract "minimal mode of operation for  IEEE 802.15.4 TSCH " does not need IP at all but that's not what we are defining here. We are defining a "minimal mode of operation for IPv6 over a IEEE 802.15.4 TSCH network", in other words the minimal thing that is needed to build a 6TiSCH network, which includes the capability to support multihop operation, which includes synchronization.

6TiSCH requires RPL for data and time synchronization over multiple hops. That capability is part of our bare minimum. If someone only cares for hub and spoke, then RPL is not needed, but supporting only that model is below the bar of the 6TiSCH bare minimum. 

> I looked at draft-ietf-6tisch-minimal-13, and I see that there are no 
> changes to the abstract or the introduction.  As I read that text, 
> this document is intended to give minimal operational parameters for 
> IEEE802.15.4 TSCH.  However, the title of the document is "Minimal 
> 6TiSCH Configuration" and the content goes far beyond the parameters 
> needed to run IEEE802.15.4 TSCH.  As an aside, I don't see any mention 
> of TiSCH or 6TiSCH in the document, other than in the title.

I agree, Ralph;

Proposals:

--------------
Abstract (before)

   This document describes the minimal set of rules to operate an IEEE
   802.15.4 Timeslotted Channel Hopping (TSCH) network.  This minimal
   mode of operation can be used during network bootstrap, as a fall-
   back mode of operation when no dynamic scheduling solution is
   available or functioning, or during early interoperability testing
   and development.

----------
Abstract (after)

   This document describes the minimal set of rules to operate a 6TiSCH
   Network, which provides IPv6 connectivity over a Non-Broadcast
   Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4
   Timeslotted Channel Hopping (TSCH) links.  This minimal set only
   provides static scheduling, but it can be complemented in operating
   networks by distributed, or centrally controlled, dynamic scheduling
   extensions.

----------

------------

1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Introduction

   The nodes in a IEEE 802.15.4 TSCH network follow a communication
   schedule.  The entity (centralized or decentralized) responsible for
   building and maintaining that schedule has precise control over the
   trade-off between the network's latency, bandwidth, reliability and
   power consumption.  During early interoperability testing and
   development, however, simplicity is more important than efficiency.
   One goal of this document is to define the simplest set of rules for
   building a TSCH-compliant network, at the necessary price of lesser
   efficiency.  Yet, this minimal mode of operation MAY also be used
   during network bootstrap before any schedule is installed into the
   network so nodes can self-organize and the management and
   configuration information be distributed.  In addition, the minimal
   configuration MAY be used as a fall-back mode of operation, ensuring
   connectivity of nodes in case that dynamic scheduling mechanisms fail
   or are not available.  The IEEE 802.15.4 specification provides a
   mechanism whereby the details of slotframe length, timeslot timing,
   and channel hopping pattern are communicated when a node time
   synchronizes to the network [IEEE802154].  This document describes
   specific settings for these parameters.

------------------------------

1.  Introduction

   A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast
   Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4
   Timeslotted Channel Hopping (TSCH) links.  

   Nodes in a IEEE 802.15.4 TSCH network follow a communication
   schedule.  An entity (centralized or decentralized) responsible for
   building and maintaining that schedule has precise control over the
   trade-off between the network's latency, bandwidth, reliability and
   power consumption. The degree of optimization that is obtained
   depends on the capabilities of the controlling entity and the acceptable
   complexity for a given deployment. In a minimal configuration,
   this controlling entity is omitted, and the schedule is static.

   The IEEE 802.15.4 specification provides a mechanism whereby the
   schedule, expressed as details of slotframe length, timeslot timing,
   and channel hopping pattern, is obtained by a node at the time it joins
   the network [IEEE802154].

   This specification defines a Minimal Configuration to build a 6TiSCH
   Network, using the Routing Protocol for LLNs (RPL) and a static TSCH
   Schedule.  The 802.15.4 TSCH mode, RPL [RFC6550], and its Objective
   Function 0 (OF0) [RFC6552], are used unmodified, but parameters and
   particular operations are specified  to guarantee interoperability
   between nodes in a 6TiSCH Network.
   
   More advanced work is expected in the future to complement the
   Minimal Configuration with dynamic operations that can adapt the
   Schedule to the needs of the traffic in run time.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

------------------------------

The changes above attempt to address Ralph's comments, but also Brian's point that 2119 language should come after the introduction, and removes unnecessary text on particular usages which appeared to limit the applicability of the draft.

> before I can continue my re-review.

Yes; and ultimately the purpose is to match charter item 3:

"
3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It is expected that RPL and the Objective Function 0 (OF0) will be reused as-is.

The work will include a best practice configuration for RPL and OF0 operation over the static schedule. Based on that experience the group may produce a requirements draft for OF0 extensions, to be studied in ROLL.
"

Huge thanks for your patience and your willingness help / make sure we do the right thing.

Take care,

Pascal

> -----Original Message-----
> From: Ralph Droms (rdroms)
> Sent: mardi 8 décembre 2015 15:56
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal
> 
> 
> I had a hard time mapping from the points in my review to the issues tracked in
> bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/
> 
> The requirements for this document are unclear to me.  Exactly what services
> would a "minimal mode of operation" provide?  The Abstract and most of the
> document talks about the operation of an IEEE 802.15.4 TSCH network, yet the
> title of the document is "Minimal 6TiSCH Configuration".
> Does a network that follows these rules provide an L2 IEEE 802.15.4 service, an
> IPv6 6TiSCH service, ???
> 
> Related to this question, does this document describe "a minimal set of rules to
> operate an IEEE802.15.4 ...] TSCH network" or a "minimal mode of operation"
> (both text snippets from the Abstract).
> 
> parameters.  Yet, it calls for the use of RPL, which seems to me to be a highly
> undesirable entangling of protocols at different layers of the protocol stack.
> IEEE 802.15.4 TSCH is expected to be used in networks that don't use RPL.
> 
> My understanding of the document is that RPL is assumed to be in use because it
> is required in a 6TiSCH network.  RPL is then used to generate the Join Priority
> through the DAGRank function as specified in section 7.2.  The use of RPL implies
> to me the configuration and operation of a full IPv6 stack, which hardly seems
> like a minimal mode of operation for IEEE 802.15.4 TSCH.
> 
> I looked at draft-ietf-6tisch-minimal-13, and I see that there are no changes to
> the abstract or the introduction.  As I read that text, this document is intended
> to give minimal operational parameters for IEEE802.15.4 TSCH.  However, the
> title of the document is "Minimal 6TiSCH Configuration" and the content goes
> far beyond the parameters needed to run IEEE802.15.4 TSCH.  As an aside, I
> don't see any mention of TiSCH or 6TiSCH in the document, other than in the
> title.
> 
> > All issues are solved but the intended status that we will track with
> > a separate ticket
> >
> > --
> > -----------------------------------+----------------------------------
> > -----------------------------------+--
> > -----------------------------------+----------------------------------
> > -----------------------------------+--
> >
> > Ticket URL:
> > <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/40#comment:1>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Dec 2015 09:03:40 +0000

I received the echo of the below truncated; there may be a weird character in there; in case you got it truncated too, I'm resending a copy plain text;

Pascal

I agree, Ralph;

Proposals:

--------------
Abstract (before)

----------
Abstract (after)

----------

------------

1.  Requirements Language

2.  Introduction

1.  Introduction

   

2.  Requirements Language

"

Take care,

Pascal

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 9 Dec 2015 14:23:29 +0000

> On Dec 9, 2015, at 3:58 AM 12/9/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ralph:
> 

This is the key question I was trying to get an answer for.  I think what I read below is that the intention for this document is to define "a set of rules for simplest operation of an 6TiSCH network".

> This issue is related with the next. I'll be proposing text at the end of this mail;

OK.

> 6TiSCH was put together to address the NBMA nature of the multihop network as opposed to considering only one hop, like BTLE does, which would probably be have been 6lo work.

My key question is whether this document aimed at a description of how to use IEEE 802.15.4 TSCH or 6TiSCH.  As the goal is a description of 6TiSCH, a description of how to use RPL is, of course, appropriate.

> 6TiSCH requires RPL for data and time synchronization over multiple hops. That capability is part of our bare minimum. If someone only cares for hub and spoke, then RPL is not needed, but supportin…

I still think tying the join process to the use of RPL is a bad idea, but that's a minor design point for the WG.

>> of TiSCH or 6TiSCH in the document, other than in the title.

I apologize if I appear to be wordsmithing (or even bikeshedding).

I don't think the first sentence is right.  I think what this document describes is a simple mode of operation to provide IPv6-over-6Tisch service.  The motivation for this mode of operation is testing, initial deployment and/or "required to implement" to provide a baseline of interoperability.  I think the focus should be on the purpose of the document as a whole and the details of the scheduling mechanism can be left for the Introduction.

Good - a crisp definition of "6TiSCH" is critical.

>   Schedule to the needs of the traffic in run time.

What about all the other protocols required to run an IPv6 network?

I would assume that the reader knows about IEEE 802.15.4 TSCH, RPL, etc., and their principles of operation.  In the interest of conciseness, I recommend eliding motivations and descriptions of protocols that are available elsewhere.  If I were reading this document, I would want to know what protocols I need to implement, what is the default operation of those protocols, what operational parameters a device will receive through the network, what defaults a device should use for other operational parameters.

>   document are to be interpreted as described in RFC 2119 [RFC2119].

On reflection, I think this charter item is incomplete.  It focuses on only two aspects of how to build a simple 6TiSCH network: scheduling and routing.  A complete IPv6-over-TSCH definition needs to specify the use of 6LoWPAN, ND, address management, prefix management, etc.

Ideally, this document would be paired with a complete IPv6-over-6TSCH specification, so that this document specifies only those particular operational parameters required for the simple subset of the IPv6-over-6TSCH specification.  I understand that there is a circular dependency in that it's likely this simple 6TiSCH definition will be needed for development and testing before a complete 6TiSCH definition is published.  In that case, this document will need to be a standalone document and include descriptions of how to use all of the protocols required for 6TiSCH service.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Dec 2015 17:12:23 +0000

Hello Ralph:

> This is the key question I was trying to get an answer for.  I think what I read
> below is that the intention for this document is to define "a set of rules for
> simplest operation of an 6TiSCH network".

Yes. That is what I'm expecting as shepherd of the doc to match the charter item.

<snip>

> > 6TiSCH was put together to address the NBMA nature of the multihop network
> as opposed to considering only one hop, like BTLE does, which would probably
> be have been 6lo work.
> 
> My key question is whether this document aimed at a description of how to use
> IEEE 802.15.4 TSCH or 6TiSCH.  As the goal is a description of 6TiSCH, a
> description of how to use RPL is, of course, appropriate.

It is a 6TiSCH spec about minimal 6TiSCH Network, not a description of TSCH, which is already a completed charter item (https://tools.ietf.org/html/rfc7554).

> >
> > 6TiSCH requires RPL for data and time synchronization over multiple hops.
> That capability is part of our bare minimum. If someone only cares for hub and
> spoke, then RPL is not needed, but supporting only that model is below the bar
> of the 6TiSCH bare minimum.
> 

If it was only that, I'd agree. 

But we also need RPL to build a loop-less structure for the clock synchronization, so we do not need an additional routing method for that purpose only.
As you know, clock synchronization is key to the TSCH operation and if a node loses its sense of time, it lose connectivity and will need to rejoin.

So RPL ends up as a core mechanism in 6TiSCH and if that makes things simpler or better, then we are happy to leverage it elsewhere.

> >> needed to run IEEE802.15.4 TSCH.  As an aside, I don't see any
> >> mention of TiSCH or 6TiSCH in the document, other than in the title.
> >
> > I agree, Ralph;
> >
> > Proposals:
> >
> >
> >
> > --------------
> > Abstract (before)
> >
> I don't think the first sentence is right.  I think what this document describes is a
> simple mode of operation to provide IPv6-over-6Tisch service.  The motivation
> for this mode of operation is testing, initial deployment and/or "required to
> implement" to provide a baseline of interoperability.  I think the focus should be
> on the purpose of the document as a whole and the details of the scheduling
> mechanism can be left for the Introduction.

Hum:

"IPv6-over-6Tisch" is redundant since the 6 in 6TiSCH is already that IPv6.

Our terminology says :   6TiSCH:     IPv6 over the Timeslotted Channel Hopping (TSCH) mode of IEEE 802.15.4e.

Also we have learnt that the initial motivation and how the protocol ends up being used are totally different beast so I'd rather stick to what minimal is as opposed to what we thought we'd be using it for. It is mostly minimal because it uses a static schedule and slotted-aloha over it. It is also minimal because it is based on the IETF standards that are designed to enable IPv6 on the most constrained environments that we support (6LoWPAN, RPL, CoAP, ...).

Finally you say that the first sentence is not right but it appears that you comment on the second. Putting all the above together, and if that's really your point, then yes, I'd agree with you to remove the second sentence. What about:

"
----------
Abstract (2nd try)

This document describes a minimal mode of operation for a 6TiSCH
Network, to provide IPv6 connectivity over a Non-Broadcast
Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4
Timeslotted Channel Hopping (TSCH) links.  This minimal mode 
leverages 6LoWPAN and RPL to enable slotted-aloha operations
over a static TSCH schedule.
"

> Good - a crisp definition of "6TiSCH" is critical.

<snip>

> I would assume that the reader knows about IEEE 802.15.4 TSCH, RPL, etc., and
> their principles of operation.  In the interest of conciseness, I recommend eliding
> motivations and descriptions of protocols that are available elsewhere.  If I were
> reading this document, I would want to know what protocols I need to
> implement, what is the default operation of those protocols, what operational
> parameters a device will receive through the network, what defaults a device
> should use for other operational parameters.

Yes, we agree on the goal; " motivations and descriptions of protocols that are available elsewhere" is exactly what I've been trying to do.
But I fail to see which text in the intro still fits that description. Would you have a suggestion there? Note that we need to insist on the static schedule because that's where the minimalistic thing comes from.
Below I'm adding a paragraph to address the need to mention 6LoWPAN as mandatory parts of the minimal solution, in an attempt to cover your points above and further down this mail.

1.  Introduction

<added in v2>

   The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the
   use of both RPL and the 6LoWPAN adaptation layer framework 
   ([RFC4944], [RFC6282]) as defined over IEEE 802.14.5.
   6LoWPAN Neighbor Discovery [RFC6775] (ND)  is also required to
   exchange Compression Contexts,  form IPv6 addresses and register
   them for the purpose of Duplicate Address Detection, Address
   Resolution and Neighbor Unreachability detection over one
   TSCH link.
   
</added in v2>

   

>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH
>> network using the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It
>> is expected that RPL and the Objective Function 0 (OF0) will be reused as-is.
> 
> On reflection, I think this charter item is incomplete.  It focuses on only two
> aspects of how to build a simple 6TiSCH network: scheduling and routing.  A
> complete IPv6-over-TSCH definition needs to specify the use of 6LoWPAN, ND,
> address management, prefix management, etc.

Yes, we need to add text on reusing 6LoWPAN HC as is. Then there's the question of 6LoRH (in adoption call at 6lo); should we mention it?
The deployment and interaction with backbone router for those deployments that need it is described in the architecture.
Left to be debated is whether we point only on RFC 6775 for the other items or add draft-thubert-6lo-backbone-router (also in adoption call at 6lo) in the picture.

> Ideally, this document would be paired with a complete IPv6-over-6TSCH
> specification, so that this document specifies only those particular operational
> parameters required for the simple subset of the IPv6-over-6TSCH specification.
> I understand that there is a circular dependency in that it's likely this simple
> 6TiSCH definition will be needed for development and testing before a complete
> 6TiSCH definition is published.  In that case, this document will need to be a
> standalone document and include descriptions of how to use all of the protocols
> required for 6TiSCH service.

My thought too. The high level informational view is supposed to be the architecture, which may be ill-named since as you pointed out in your review, it goes deeper than that.
We do not want to overload the minimal draft with things that are in the architecture already. It is in line with your earlier comment on " eliding motivations and descriptions of protocols that are available elsewhere" to which I do agree.

I added a paragraph to indicate the inheritance from the architecture and the need of all the 6LoWPAN suite.

Does that work?

Pascal

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Wed, 9 Dec 2015 20:27:42 +0000

> On Dec 9, 2015, at 12:12 PM 12/9/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ralph:
> 
> 

OK.

OK.

> "IPv6-over-6Tisch" is redundant since the 6 in 6TiSCH is already that IPv6.

Yes, that was a typo...

> Also we have learnt that the initial motivation and how the protocol ends up being used are totally different beast so I'd rather stick to what minimal is as opposed to what we thought we'd be usin…

OK.  I see now that the motivations from the original Introduction were left out of the new Introduction you proposed.

> 
> Finally you say that the first sentence is not right but it appears that you comment on the second.

I think the document describes a simple mode of operation for a collection of protocols to provide 6TiSCH server.  It's probably good to describe that simple mode of operation with as few rules as possible, but the important objective, in my opinion, is simple mode of operation.

> Putting all the above together, and if that's really your point, then yes, I'd agree with you to remove the second sentence. What about:
> 
> "
> ----------
> Abstract (2nd try)
> 

I apologize again for appearing to wordsmith - but why mention only 6LoWPAN and RPL?  Why not all the relevant protocols or "This minimal mode of operation uses a collection of protocols [...]"
> But I fail to see which text in the intro still fits that description. Would you have a suggestion there? Note that we need to insist on the static schedule because that's where the minimalistic th…

Ah, I jumped ahead to talk about the document as a whole at this point.  Sorry for the confusion.

> Below I'm adding a paragraph to address the need to mention 6LoWPAN as mandatory parts of the minimal solution, in an attempt to cover your points above and further down this mail.

We're probably arguing style at this point; I would write (replacing both paragraphs):

  Nodes in a IEEE 802.15.4 TSCH network follow a communication
  schedule.  A network using the simple mode of operation uses a
  static schedule.

Perhaps, considering that a static schedule is mentioned in the next paragraph, I would simply omit the previous two paragraphs.

> Yes, we need to add text on reusing 6LoWPAN HC as is. Then there's the question of 6LoRH (in adoption call at 6lo); should we mention it?

I would consider 6LoRH to be part of 6LoWPAN header compression, so there's no need to mention it in the Introduction.

OK.

> My thought too. The high level informational view is supposed to be the architecture, which may be ill-named since as you pointed out in your review, it goes deeper than that.

I don't know whether the WG wants to produce separate architecture and 6TiSCH (IPvr-over-IEEE802.15.4TSCH) documents.  The specification I think the minimal mode document should depend on is the 6TiSCH specification.

OK.

> I added a paragraph to indicate the inheritance from the architecture and the need of all the 6LoWPAN suite.

Yes ... I think we're converging.

It would be good to hear from other WG members in this discussion.

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Dec 2015 20:54:26 +0000

Yes Ralph, 

we have converged. I like and agree with your suggestions below. 

Take care,
Pascal

> Le 9 déc. 2015 à 21:27, Ralph Droms (rdroms) <[email-masked]> a écrit :
> 
>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Thu, 10 Dec 2015 14:27:50 +0530

Hi Pascal and Ralph,

Very engrossing discussion :)

The use of RPL as a means to achieve network time synchronization is
interesting but essential too for 6TiSCH network opertation. I am sort of
wondering, if NMBA networks are common and network time synchronization 
is so
imporant, shouldn't there be native mechanisms built into IEEE 802.15.4e 
that
ensure this happens for TSCH to succeed ? I would ideally liked to have left
this job to L2 rather than pushing it to a higher layer to manage an
essentially a L2 property. Does it make sense ?

Anand

On Thursday 10 December 2015 02:24 AM, Pascal Thubert (pthubert) wrote:
> Yes Ralph, > > we have converged. I like and agree with your suggestions below. > 
 > Take care, > Pascal > >> Le 9 déc. 2015 à 21:27, Ralph Droms (rdroms) 
<[email-masked]> a écrit : >> >> >>> On Dec 9, 2015, at 12:12 PM 
12/9/15, Pascal Thubert (pthubert) <[email-masked]> wrote: >>> >>> 
Hello Ralph: >>> >>> >>>>>> Does a network that follows these rules 
provide an L2 IEEE 802.15.4 >>>>>> service, an >>>>>> IPv6 6TiSCH 
service, ??? >>>> >>>> This is the key question I was trying to get an 
answer for.  I think what I read >>>> below is that the intention for 
this document is to define "a set of rules for >>>> simplest operation 
of an 6TiSCH network". >>> >>> Yes. That is what I'm expecting as 
shepherd of the doc to match the charter item. >>> >>> >>> <snip> >>> 
 >>>>> 6TiSCH was put together to address the NBMA nature of the 
multihop network >>>> as opposed to considering only one hop, like BTLE 
does, which would probably >>>> be have been 6lo work. >>>> >>>> My key 
question is whether this document aimed at a description of how to use 
 >>>> IEEE 802.15.4 TSCH or 6TiSCH.  As the goal is a description of 
6TiSCH, a >>>> description of how to use RPL is, of course, appropriate. 
 >>> >>> It is a 6TiSCH spec about minimal 6TiSCH Network, not a 
description of TSCH, which is already a completed charter item 
(https://tools.ietf.org/html/rfc7554). >> >> OK. >> >>>>> 6TiSCH 
requires RPL for data and time synchronization over multiple hops. >>>> 
That capability is part of our bare minimum. If someone only cares for 
hub and >>>> spoke, then RPL is not needed, but supporting only that 
model is below the bar >>>> of the 6TiSCH bare minimum. >>>> >>>> I 
still think tying the join process to the use of RPL is a bad idea, but 
that's a >>>> minor design point for the WG. >>> >>> If it was only 
that, I'd agree. >>> >>> But we also need RPL to build a loop-less 
structure for the clock synchronization, so we do not need an additional 
routing method for that purpose only. >>> As you know, clock 
synchronization is key to the TSCH operation and if a node loses its 
sense of time, it lose connectivity and will need to rejoin. >>> >>> So 
RPL ends up as a core mechanism in 6TiSCH and if that makes things 
simpler or better, then we are happy to leverage it elsewhere. >> >> OK. 
 >> >>>>>> I looked at draft-ietf-6tisch-minimal-13, and I see that 
there are no >>>>>> changes to the abstract or the introduction.  As I 
read that text, >>>>>> this document is intended to give minimal 
operational parameters for >>>>>> IEEE802.15.4 TSCH.  However, the title 
of the document is "Minimal >>>>>> 6TiSCH Configuration" and the content 
goes far beyond the parameters >>>>>> needed to run IEEE802.15.4 TSCH.  
As an aside, I don't see any >>>>>> mention of TiSCH or 6TiSCH in the 
document, other than in the title. >>>>> >>>>> I agree, Ralph; >>>>> 
 >>>>> Proposals: >>>>> >>>>> >>>>> >>>>> -------------- >>>>> Abstract 
(before) >>>>> >>>>> This document describes the minimal set of rules to 
operate an IEEE >>>>> 802.15.4 Timeslotted Channel Hopping (TSCH) 
network.  This minimal >>>>> mode of operation can be used during 
network bootstrap, as a fall- >>>>> back mode of operation when no 
dynamic scheduling solution is >>>>> available or functioning, or during 
early interoperability testing >>>>> and development. >>>>> >>>>> 
---------- >>>>> Abstract (after) >>>>> >>>>> This document describes 
the minimal set of rules to operate a 6TiSCH >>>>> Network, which 
provides IPv6 connectivity over a Non-Broadcast >>>>> Multi-Access 
(NBMA) mesh that is formed of IEEE 802.15.4 >>>>> Timeslotted Channel 
Hopping (TSCH) links.  This minimal set only >>>>> provides static 
scheduling, but it can be complemented in operating >>>>> networks by 
distributed, or centrally controlled, dynamic scheduling >>>>> 
extensions. >>>>> >>>>> ---------- >>>> >>>> I apologize if I appear to 
be wordsmithing (or even bikeshedding). >>>> >>>> I don't think the 
first sentence is right.  I think what this document describes is a >>>> 
simple mode of operation to provide IPv6-over-6Tisch service.  The 
motivation >>>> for this mode of operation is testing, initial 
deployment and/or "required to >>>> implement" to provide a baseline of 
interoperability.  I think the focus should be >>>> on the purpose of 
the document as a whole and the details of the scheduling >>>> mechanism 
can be left for the Introduction. >>> >>> Hum: >>> >>> 
"IPv6-over-6Tisch" is redundant since the 6 in 6TiSCH is already that 
IPv6. >> >> Yes, that was a typo... >> >>> >>> Our terminology says :   
6TiSCH:     IPv6 over the Timeslotted Channel Hopping (TSCH) mode of 
IEEE 802.15.4e. >>> >>> Also we have learnt that the initial motivation 
and how the protocol ends up being used are totally different beast so 
I'd rather stick to what minimal is as opposed to what we thought we'd 
be using it for. It is mostly minimal because it uses a static schedule 
and slotted-aloha over it. It is also minimal because it is based on the 
IETF standards that are designed to enable IPv6 on the most constrained 
environments that we support (6LoWPAN, RPL, CoAP, ...). >> >> OK.  I see 
now that the motivations from the original Introduction were left out of 
the new Introduction you proposed. >> >>> >>> Finally you say that the 
first sentence is not right but it appears that you comment on the 
second. >> >> I think the document describes a simple mode of operation 
for a collection of protocols to provide 6TiSCH server.  It's probably 
good to describe that simple mode of operation with as few rules as 
possible, but the important objective, in my opinion, is simple mode of 
operation. >> >>> Putting all the above together, and if that's really 
your point, then yes, I'd agree with you to remove the second sentence. 
What about: >>> >>> " >>> ---------- >>> Abstract (2nd try) >>> >>> This 
document describes a minimal mode of operation for a 6TiSCH >>> Network, 
to provide IPv6 connectivity over a Non-Broadcast >>> Multi-Access 
(NBMA) mesh that is formed of IEEE 802.15.4 >>> Timeslotted Channel 
Hopping (TSCH) links.  This minimal mode >>> leverages 6LoWPAN and RPL 
to enable slotted-aloha operations >>> over a static TSCH schedule. >> 
 >> I apologize again for appearing to wordsmith - but why mention only 
6LoWPAN and RPL?  Why not all the relevant protocols or "This minimal 
mode of operation uses a collection of protocols [...]" >>> " >>> >>>> 
 >>>>> >>>>> ------------ >>>>> >>>>> >>>>> >>>>> 1.  Requirements 
Language >>>>> >>>>> The key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", >>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", 
"MAY", and "OPTIONAL" in >>>> this >>>>> document are to be interpreted 
as described in RFC 2119 [RFC2119]. >>>>> >>>>> 2.  Introduction >>>>> 
 >>>>> schedule.  The entity (centralized or decentralized) responsible 
for >>>>> building and maintaining that schedule has precise control 
over the >>>>> trade-off between the network's latency, bandwidth, 
reliability and >>>>> power consumption.  During early interoperability 
testing and >>>>> development, however, simplicity is more important 
than efficiency. >>>>> One goal of this document is to define the 
simplest set of rules for >>>>> building a TSCH-compliant network, at 
the necessary price of lesser >>>>> efficiency.  Yet, this minimal mode 
of operation MAY also be used >>>>> during network bootstrap before any 
schedule is installed into the >>>>> network so nodes can self-organize 
and the management and >>>>> configuration information be distributed.  
In addition, the minimal >>>>> configuration MAY be used as a fall-back 
mode of operation, ensuring >>>>> connectivity of nodes in case that 
dynamic scheduling mechanisms fail >>>>> or are not available.  The IEEE 
802.15.4 specification provides a >>>>> mechanism whereby the details of 
slotframe length, timeslot timing, >>>>> and channel hopping pattern are 
communicated when a node time >>>>> synchronizes to the network 
[IEEE802154].  This document describes >>>>> specific settings for these 
parameters. >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> 
1.  Introduction >>>>> >>>>> A 6TiSCH Network provides IPv6 connectivity 
over a Non-Broadcast >>>>> Multi-Access (NBMA) mesh that is formed of 
IEEE 802.15.4 >>>>> Timeslotted Channel Hopping (TSCH) links. >>>> >>>> 
Good - a crisp definition of "6TiSCH" is critical. >>> >>> <snip> >>> 
 >>>> >>>> What about all the other protocols required to run an IPv6 
network? >>>> >>>> I would assume that the reader knows about IEEE 
802.15.4 TSCH, RPL, etc., and >>>> their principles of operation.  In 
the interest of conciseness, I recommend eliding >>>> motivations and 
descriptions of protocols that are available elsewhere.  If I were >>>> 
reading this document, I would want to know what protocols I need to 
 >>>> implement, what is the default operation of those protocols, what 
operational >>>> parameters a device will receive through the network, 
what defaults a device >>>> should use for other operational parameters. 
 >>> >>> Yes, we agree on the goal; " motivations and descriptions of 
protocols that are available elsewhere" is exactly what I've been trying 
to do. >>> But I fail to see which text in the intro still fits that 
description. Would you have a suggestion there? Note that we need to 
insist on the static schedule because that's where the minimalistic 
thing comes from. >> >> Ah, I jumped ahead to talk about the document as 
a whole at this point.  Sorry for the confusion. >> >>> Below I'm adding 
a paragraph to address the need to mention 6LoWPAN as mandatory parts of 
the minimal solution, in an attempt to cover your points above and 
further down this mail. >>> >>> ------------------------------ >>> >>> 
1.  Introduction >>> >>>  A 6TiSCH Network provides IPv6 connectivity 
over a Non-Broadcast >>>  Multi-Access (NBMA) mesh that is formed of 
IEEE 802.15.4 >>>  Timeslotted Channel Hopping (TSCH) links. >>> >>> 
<added in v2> >>> >>>  The 6TiSCH [I-D.ietf-6tisch-architecture] 
architecture requires the >>>  use of both RPL and the 6LoWPAN 
adaptation layer framework >>>  ([RFC4944], [RFC6282]) as defined over 
IEEE 802.14.5. >>>  6LoWPAN Neighbor Discovery [RFC6775] (ND)  is also 
required to >>>  exchange Compression Contexts,  form IPv6 addresses and 
register >>>  them for the purpose of Duplicate Address Detection, 
Address >>>  Resolution and Neighbor Unreachability detection over one 
 >>>  TSCH link. >>> >>> </added in v2> >>> >>>  Nodes in a IEEE 
802.15.4 TSCH network follow a communication >>>  schedule.  An entity 
(centralized or decentralized) responsible for >>>  building and 
maintaining that schedule has precise control over the >>>  trade-off 
between the network's latency, bandwidth, reliability and >>>  power 
consumption. The degree of optimization that is obtained >>>  depends on 
the capabilities of the controlling entity and the acceptable >>>  
complexity for a given deployment. In a minimal configuration, >>>  this 
controlling entity is omitted, and the schedule is static. >>> >>>  The 
IEEE 802.15.4 specification provides a mechanism whereby the >>>  
schedule, expressed as details of slotframe length, timeslot timing, 
 >>>  and channel hopping pattern, is obtained by a node at the time it 
joins >>>  the network [IEEE802154]. >> >> We're probably arguing style 
at this point; I would write (replacing both paragraphs): >> >>  Nodes 
in a IEEE 802.15.4 TSCH network follow a communication >>  schedule.  A 
network using the simple mode of operation uses a >>  static schedule. 
 >> >> Perhaps, considering that a static schedule is mentioned in the 
next paragraph, I would simply omit the previous two paragraphs. >> >>>  
This specification defines a Minimal Configuration to build a 6TiSCH 
 >>>  Network, using the Routing Protocol for LLNs (RPL) and a static 
TSCH >>>  Schedule.  The 802.15.4 TSCH mode, RPL [RFC6550], and its 
Objective >>>  Function 0 (OF0) [RFC6552], are used unmodified, but 
parameters and >>>  particular operations are specified  to guarantee 
interoperability >>>  between nodes in a 6TiSCH Network. >>> >>>  More 
advanced work is expected in the future to complement the >>>  Minimal 
Configuration with dynamic operations that can adapt the >>>  Schedule 
to the needs of the traffic in run time. >>> >>>>> 3. Produce "Minimal 
6TiSCH Configuration" defining how to build a 6TiSCH >>>>> network using 
the Routing Protocol for LLNs (RPL) and a static TSCH schedule. It >>>>> 
is expected that RPL and the Objective Function 0 (OF0) will be reused 
as-is. >>>> >>>> On reflection, I think this charter item is 
incomplete.  It focuses on only two >>>> aspects of how to build a 
simple 6TiSCH network: scheduling and routing.  A >>>> complete 
IPv6-over-TSCH definition needs to specify the use of 6LoWPAN, ND, >>>> 
address management, prefix management, etc. >>> >>> Yes, we need to add 
text on reusing 6LoWPAN HC as is. Then there's the question of 6LoRH (in 
adoption call at 6lo); should we mention it? >> >> I would consider 
6LoRH to be part of 6LoWPAN header compression, so there's no need to 
mention it in the Introduction. >> >>> The deployment and interaction 
with backbone router for those deployments that need it is described in 
the architecture. >>> Left to be debated is whether we point only on RFC 
6775 for the other items or add draft-thubert-6lo-backbone-router (also 
in adoption call at 6lo) in the picture. >> >> OK. >> >>>> Ideally, this 
document would be paired with a complete IPv6-over-6TSCH >>>> 
specification, so that this document specifies only those particular 
operational >>>> parameters required for the simple subset of the 
IPv6-over-6TSCH specification. >>>> I understand that there is a 
circular dependency in that it's likely this simple >>>> 6TiSCH 
definition will be needed for development and testing before a complete 
 >>>> 6TiSCH definition is published.  In that case, this document will 
need to be a >>>> standalone document and include descriptions of how to 
use all of the protocols >>>> required for 6TiSCH service. >>> >>> My 
thought too. The high level informational view is supposed to be the 
architecture, which may be ill-named since as you pointed out in your 
review, it goes deeper than that. >> >> I don't know whether the WG 
wants to produce separate architecture and 6TiSCH 
(IPvr-over-IEEE802.15.4TSCH) documents.  The specification I think the 
minimal mode document should depend on is the 6TiSCH specification. >> 
 >>> We do not want to overload the minimal draft with things that are 
in the architecture already. It is in line with your earlier comment on 
" eliding motivations and descriptions of protocols that are available 
elsewhere" to which I do agree. >> >> OK. >> >>> I added a paragraph to 
indicate the inheritance from the architecture and the need of all the 
6LoWPAN suite. >>> >>> Does that work? >> >> Yes ... I think we're 
converging. >> >> It would be good to hear from other WG members in this 
discussion. >> >> - Ralph >> >>> >>> Pascal >>> >>> 
_______________________________________________ >>> 6tisch mailing list 
 >>> [email-masked] >>> https://www.ietf.org/mailman/listinfo/6tisch >> 
 > > _______________________________________________ > 6tisch mailing 
list > [email-masked] > https://www.ietf.org/mailman/listinfo/6tisch

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2015 09:25:12 +0000

Hello Anand:

This would mean running to protocols for building loopless structures. Considering the constraints of the devices, that's one too many.

Cheers,

Pascal

From: S.V.R.Anand [mailto:[email-masked]]
Sent: jeudi 10 décembre 2015 09:58
To: Pascal Thubert (pthubert) <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Hi Pascal and Ralph,

The use of RPL as a means to achieve network time synchronization is
interesting but essential too for 6TiSCH network opertation. I am sort of
wondering, if NMBA networks are common and network time synchronization is so
imporant, shouldn't there be native mechanisms built into IEEE 802.15.4e that
ensure this happens for TSCH to succeed ? I would ideally liked to have left
this job to L2 rather than pushing it to a higher layer to manage an
essentially a L2 property. Does it make sense ?

Anand

On Thursday 10 December 2015 02:24 AM, Pascal Thubert (pthubert) wrote:
>> Le 9 déc. 2015 à 21:27, Ralph Droms (rdroms) <[email-masked]><mailto:[email-masked]> a écrit :
>>
>>
>>> On Dec 9, 2015, at 12:12 PM 12/9/15, Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]> wrote:
>>>
>>> Hello Ralph:
>>>
>>>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

---

From: "S.V.R.Anand" <[email-masked]>
Date: Thu, 10 Dec 2015 15:05:41 +0530

Hi Pascal,

I understand your point.

Just a wishful thought prompted by the desire to keep the layers perform 
their activities.

Anand

On Thursday 10 December 2015 02:55 PM, Pascal Thubert (pthubert) wrote:
>
> Hello Anand:
>
> This would mean running to protocols for building loopless structures. 
> Considering the constraints of the devices, that’s one too many.
>
> Cheers,
>
> Pascal
>
> *From:*S.V.R.Anand [mailto:[email-masked]]
> *Sent:* jeudi 10 décembre 2015 09:58
> *To:* Pascal Thubert (pthubert) <[email-masked]>; Ralph Droms 
> (rdroms) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal
>
> Hi Pascal and Ralph,
>
> >> Le 9 déc. 2015 à 21:27, Ralph Droms (rdroms) <[email-masked]> 
> <mailto:[email-masked]>a écrit :
>
> >>
>
> >>
>
> >>> On Dec 9, 2015, at 12:12 PM 12/9/15, Pascal Thubert (pthubert) 
> <[email-masked]> <mailto:[email-masked]> wrote:
>
> >>>
>
> >>> Hello Ralph:
>
> >>>
>
> >>>
>
> >>>>>> service, an
> multihop network
> 6TiSCH, a
> (https://tools.ietf.org/html/rfc7554).
>
> >>
>
> >> OK.
>
> >>
>
> >>>> I still think tying the join process to the use of RPL is a bad 
> idea, but that's a
>
> >>>> minor design point for the WG.
>
> >>>
>
> >>> But we also need RPL to build a loop-less structure for the clock 
> synchronization, so we do not need an additional routing method for 
> that purpose only.
>
> >>> As you know, clock synchronization is key to the TSCH operation 
> and if a node loses its sense of time, it lose connectivity and will 
> need to rejoin.
>
> >>>
>
> >>> So RPL ends up as a core mechanism in 6TiSCH and if that makes 
> things simpler or better, then we are happy to leverage it elsewhere.
>
> >>
>
> >> OK.
>
> >>
>
> >>> Our terminology says : 6TiSCH:     IPv6 over the Timeslotted 
> Channel Hopping (TSCH) mode of IEEE 802.15.4e.
>
> >>>
>
> >>> Also we have learnt that the initial motivation and how the 
> protocol ends up being used are totally different beast so I'd rather 
> stick to what minimal is as opposed to what we thought we'd be using 
> it for. It is mostly minimal because it uses a static schedule and 
> slotted-aloha over it. It is also minimal because it is based on the 
> IETF standards that are designed to enable IPv6 on the most 
> constrained environments that we support (6LoWPAN, RPL, CoAP, ...).
>
> >>
>
> >> OK.  I see now that the motivations from the original Introduction 
> were left out of the new Introduction you proposed.
>
> >>
>
> >>>
>
> >> I think the document describes a simple mode of operation for a 
> collection of protocols to provide 6TiSCH server.  It's probably good 
> to describe that simple mode of operation with as few rules as 
> possible, but the important objective, in my opinion, is simple mode 
> of operation.
>
> >>
>
> >>> Putting all the above together, and if that's really your point, 
> then yes, I'd agree with you to remove the second sentence. What about:
>
> >>>
>
> >>> "
>
> >>> ----------
>
> >>> Abstract (2nd try)
>
> >>>
>
> mode of operation uses a collection of protocols [...]"
>
> >>> "
>
> >>>
>
> >>>>
>
> >>>>>
>
> >>>>> ------------
>
> >>>>>
>
> >>>>>
>
> >>>>>
>
> >>>>> 1.  Requirements Language
>
> >>>>>
>
> >>>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>
> >>>> this
>
> operational
> protocols that are available elsewhere" is exactly what I've been 
> trying to do.
>
> >>> But I fail to see which text in the intro still fits that 
> thing comes from.
> >>> Below I'm adding a paragraph to address the need to mention 
> 6LoWPAN as mandatory parts of the minimal solution, in an attempt to 
> cover your points above and further down this mail.
>
> >>>
>
> joins
> next paragraph, I would simply omit the previous two paragraphs.
>
> >>
>
> >>> Yes, we need to add text on reusing 6LoWPAN HC as is. Then there's 
> the question of 6LoRH (in adoption call at 6lo); should we mention it?
>
> >>
>
> >> I would consider 6LoRH to be part of 6LoWPAN header compression, so 
> there's no need to mention it in the Introduction.
>
> >>
>
> >>> The deployment and interaction with backbone router for those 
> deployments that need it is described in the architecture.
>
> >>> Left to be debated is whether we point only on RFC 6775 for the 
> other items or add draft-thubert-6lo-backbone-router (also in adoption 
> call at 6lo) in the picture.
>
> >>
>
> >> OK.
>
> >>
>
> need to be a
> >>> My thought too. The high level informational view is supposed to 
> be the architecture, which may be ill-named since as you pointed out 
> in your review, it goes deeper than that.
>
> >>
>
> >> I don't know whether the WG wants to produce separate architecture 
> and 6TiSCH (IPvr-over-IEEE802.15.4TSCH) documents.  The specification 
> I think the minimal mode document should depend on is the 6TiSCH 
> specification.
>
> >>
>
> in the architecture already. It is in line with your earlier comment 
> on " eliding motivations and descriptions of protocols that are 
> available elsewhere" to which I do agree.
>
> >>
>
> >> OK.
>
> >>
>
> >>> I added a paragraph to indicate the inheritance from the 
> architecture and the need of all the 6LoWPAN suite.
>
> >>>
>
> >>> Does that work?
>
> >>
>
> >>> [email-masked] <mailto:[email-masked]>
>
> > [email-masked] <mailto:[email-masked]>
>
> <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
> -- 
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2015 09:56:17 +0000

Certainly Anand;

OTOH,  time is not necessarily a L2 function. See NTPv4/TICTOC at the IETF, for instance.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of S.V.R.Anand
Sent: jeudi 10 décembre 2015 10:36
To: [email-masked]
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Hi Pascal,

I understand your point.

Just a wishful thought prompted by the desire to keep the layers perform their activities.

Anand

Cheers,

Pascal

From: S.V.R.Anand [mailto:[email-masked]]
Sent: jeudi 10 décembre 2015 09:58
To: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>; Ralph Droms (rdroms) <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Hi Pascal and Ralph,

Anand

6tisch mailing list

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Dec 2015 14:16:54 +0200

Pascal Thubert (pthubert) writes:
> > That capability is part of our bare minimum. If someone only cares
> > for hub and spoke, then RPL is not needed, but supporting only
> > that model is below the bar of the 6TiSCH bare minimum.
> > 
> > idea, but that's a minor design point for the WG.
> 

Hmm.. why do not use the 802.15.4 way of doing that? 802.15.4 already
has method of generating time synchronization hierarchy.

I.e. the 802.15.4 says that Join Metric (used to be Join Priority) is
set to be the received EB Join Metric + 1.

>From the 802.15.4e:

	The beaconing device’s join priority is the lowest join
	priority heard when it joined the network plus one.

>From the 802.15.4-2015:

	The sum of one and the value of the Join Metric field from the
	TSCH Synchronization IE, 7.4.4.2, received in the Enhanced
	Beacon frame used by the device joining the network. If the
	device is the an endpoint, the value shall be set to zero.

So in the 802.15.4 the join metric of PAN coordinator / endpoint is 0,
all nodes joining directly to it has join metric of 1, and nodes
joining to them has 2 and so on.

If the 6TiSCH is using join Metric differently then it will not be
following the 802.15.4.

> As you know, clock synchronization is key to the TSCH operation and
> if a node loses its sense of time, it lose connectivity and will
> need to rejoin.

Which is why it is already specified in the 802.15.4. See section
6.5.3 Synchronization in TSCH PAN of the 802.15.4-2015 (used to be
section 5.1.4.2a in 802.15.4e).
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2015 12:49:59 +0000

Hello Tero:

Joining a tree is easy, maintaining a loopless structure is more complex. Most of RPL complexity is actually to address the latter. We do not want to duplicate that effort at L2. With 6TiSCH, RPL's rank is fed into the Join Metric field. That's how we do it.

Cheers,

Pascal

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: jeudi 10 décembre 2015 13:17
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Ralph Droms (rdroms) <[email-masked]>; [email-masked]; draft-ietf-
> [email-masked]
> > > for hub and spoke, then RPL is not needed, but supporting only that
> > > model is below the bar of the 6TiSCH bare minimum.
> > >
> Hmm.. why do not use the 802.15.4 way of doing that? 802.15.4 already has
> method of generating time synchronization hierarchy.
> 
> I.e. the 802.15.4 says that Join Metric (used to be Join Priority) is set to be the
> received EB Join Metric + 1.
> 
> From the 802.15.4e:
> 
> So in the 802.15.4 the join metric of PAN coordinator / endpoint is 0, all nodes
> joining directly to it has join metric of 1, and nodes joining to them has 2 and so
> on.
> 
> If the 6TiSCH is using join Metric differently then it will not be following the
> 802.15.4.
> 
> > As you know, clock synchronization is key to the TSCH operation and if
> > a node loses its sense of time, it lose connectivity and will need to
> > rejoin.
> 
> 6.5.3 Synchronization in TSCH PAN of the 802.15.4-2015 (used to be section
> 5.1.4.2a in 802.15.4e).
> --
> [email-masked]

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Thu, 10 Dec 2015 13:43:27 +0000

> On Dec 10, 2015, at 7:50 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Tero:
> 

Is there an analysis published somewhere that demonstrates how time synchronization in 802.15.4-* is inadequate for 6TiSCH?

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2015 14:05:08 +0000

Hello Ralph:

The clock synchronization in 802.15.4 is adequate for 6TiSCH.

RPL provides improvements on the structure that is used to propagate that synchronization.

An improvement is related to the graph maintenance. RPL has one to start with.

Another is that the way we architected this, 6TiSCH nodes do not need to build and maintain 2 different graphs, one for data and one for clock synchronization. Maintaining both would mean doubling the state etc...

Cheers,

Pascal

> Sent: jeudi 10 décembre 2015 14:43
> Cc: Tero Kivinen <[email-masked]>; [email-masked]; draft-ietf-6tisch-
> [email-masked]
> > Joining a tree is easy, maintaining a loopless structure is more complex. Most
> of RPL complexity is actually to address the latter. We do not want to duplicate
> that effort at L2. With 6TiSCH, RPL's rank is fed into the Join Metric field. That's
> how we do it.
> 
> Is there an analysis published somewhere that demonstrates how time
> synchronization in 802.15.4-* is inadequate for 6TiSCH?
> 
> - Ralph
> >
> > Cheers,
> >
> > Pascal
> >
> >
> >> Cc: Ralph Droms (rdroms) <[email-masked]>; [email-masked];
> >> draft-ietf- [email-masked]
> >>    The beaconing device's join priority is the lowest join
> >> So in the 802.15.4 the join metric of PAN coordinator / endpoint is
> >> 0, all nodes joining directly to it has join metric of 1, and nodes

---

From: Kris Pister <[email-masked]>
Date: Fri, 11 Dec 2015 08:49:17 -0800

Ralph - to my knowledge no one has deployed the specific time-parent
selection scheme described in 802.15.4-*.  The basic scheme will likely 
work,
but the devil will be in the real-world details.

We've had about 8 years of successful deployments of industrial tsch mesh
networks using a time-parent selection scheme similar to what is proposed
in minimal.

6TiSCH present a rich design space at many levels.  The goal of minimal was
to do something simple, based as closely as possible on things that are
known to work in deployed networks.  The hope and belief is that new and
better ideas will emerge, but it is certain that many of the proposed "good
ideas" will fail.  By defining minimal we provide a reliable interoperable
platform on which papers like "Comparing time-parent selection in 15.4-*
and foo" can be written.

ksjp

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 11 Dec 2015 18:24:42 +0100

Dear all,

I wrapped up the proposed changes and integrated them to the version in
bitbucket.
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a

For simplicity, see here a summary of the changes.

Abstract:

[OLD]

[NEW]

This document describes a minimal mode of operation for a 6TiSCH
   Network, to provide IPv6 connectivity over a Non-Broadcast Multi-
   Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted
   Channel Hopping (TSCH) links.  This minimal mode leverages 6LoWPAN
   and RPL to enable slotted-aloha operations over a static TSCH
   schedule.

Introduction:

[OLD]

[NEW]

 A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast
   Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted
   Channel Hopping (TSCH) links.

   The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the
   use of both RPL and the 6LoWPAN adaptation layer framework
   ([RFC4944], [RFC6282]) as defined over IEEE 802.14.5.  6LoWPAN
   Neighbor Discovery [RFC6775] (ND) is also required to exchange
   Compression Contexts, form IPv6 addresses and register them for the
   purpose of Duplicate Address Detection, Address Resolution and
   Neighbor Unreachability detection over one TSCH link.  In order to
   reduce the header overhead of the RPL artifacts in data packets, the
   Routing header [RFC6554], the RPL Option [RFC6553] and the related IP
   in IP encapsulation MUST be encoded as prescribed in
   [I-D.ietf-6lo-routing-dispatch]

   Nodes in a IEEE 802.15.4 TSCH network follow a communication
   schedule.  A network using the simple mode of operation uses a static
   schedule.

Section 11.2

[OLD]

In addition to the Objective Function (OF), nodes in a multihop
   network using RPL MUST indicate the preferred mode of operation using
   the MOP field in DIO.  Nodes not being able to operate in the
   specified mode of operation MUST only join as leaf nodes.  RPL
   information and hop-by-hop extension headers MUST follow [RFC6553]
   and [RFC6554] specification.  In the case that the packets formed at
   the LLN need to cross through intermediate routers, these MUST follow
   the IP in IP encapsulation requirement specified by the [RFC6282] and
   [RFC2460].  RPI and RH3 extension headers and inner IP headers MUST
   be compressed according to [RFC6282].

[NEW]

In addition to the Objective Function (OF), nodes in a multihop
   network using RPL MUST indicate the preferred mode of operation using
   the MOP field in DIO.  Nodes not being able to operate in the
   specified mode of operation MUST only join as leaf nodes.  RPL
   information and hop-by-hop extension headers MUST follow [RFC6553]
   and [RFC6554] specification.  In the case that the packets formed at
   the LLN need to cross through intermediate routers, these MUST follow
   the IP in IP encapsulation requirement specified by the [RFC6282] and
   [RFC2460].  RPI and RH3 extension headers and inner IP headers MUST
   be compressed according to [RFC6282] and
[I-D.ietf-6lo-routing-dispatch].

have a nice weekend,
Xavi

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 11 Dec 2015 13:29:27 -0600

Xavi;

As I understand slotted-aloha, TSCH is really Time Division Multiple Access (TDMA), not slotted-aloha.  Slotted-aloha access to the medium is used in the 802.15.4 CSMA algorithms for some modes but not TSCH.

Pat

On 11, Dec2015, at 11:24, Xavier Vilajosana <[email-masked]> wrote:

Dear all,

I wrapped up the proposed changes and integrated them to the version in bitbucket.
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a>

Abstract:

[OLD]

[NEW]

Introduction:   

[OLD]

[NEW]

Section 11.2

[OLD]

[NEW]

   be compressed according to [RFC6282] and [I-D.ietf-6lo-routing-dispatch].  

have a nice weekend,
Xavi

2015-12-11 17:49 GMT+01:00 Kris Pister <[email-masked] <mailto:[email-masked]>>:
Ralph - to my knowledge no one has deployed the specific time-parent
selection scheme described in 802.15.4-*.  The basic scheme will likely work,
but the devil will be in the real-world details.

ksjp

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 11 Dec 2015 22:06:21 +0000 (UTC)

Hi Pat,
According to my understanding, in the TSCH mode of 802.15.4, if the attribute of a slot is Shared, slotted- aloha access should be allowed in the slot. Right?
ThanksQin 

    On Friday, December 11, 2015 2:29 PM, "[email-masked]" <[email-masked]> wrote:

 Xavi;
As I understand slotted-aloha, TSCH is really Time Division Multiple Access (TDMA), not slotted-aloha.  Slotted-aloha access to the medium is used in the 802.15.4 CSMA algorithms for some modes but not TSCH.
Pat
On 11, Dec2015, at 11:24, Xavier Vilajosana <[email-masked]> wrote:
Dear all,
I wrapped up the proposed changes and integrated them to the version in bitbucket.https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a
For simplicity, see here a summary of the changes.

Abstract:
[OLD]
 This document describes the minimal set of rules to operate an IEEE   802.15.4 Timeslotted Channel Hopping (TSCH) network.  This minimal   mode of operation can be used during network bootstrap, as a fall-   back mode of operation when no dynamic scheduling solution is   available or functioning, or during early interoperability testing   and development.
[NEW]
This document describes a minimal mode of operation for a 6TiSCH   Network, to provide IPv6 connectivity over a Non-Broadcast Multi-   Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted   Channel Hopping (TSCH) links.  This minimal mode leverages 6LoWPAN   and RPL to enable slotted-aloha operations over a static TSCH   schedule.      Introduction:   
[OLD]
The nodes in a IEEE 802.15.4 TSCH network follow a communication   schedule.  The entity (centralized or decentralized) responsible for   building and maintaining that schedule has precise control over the   trade-off between the network's latency, bandwidth, reliability and   power consumption.  During early interoperability testing and   development, however, simplicity is more important than efficiency.   One goal of this document is to define the simplest set of rules for   building a TSCH-compliant network, at the necessary price of lesser   efficiency.  Yet, this minimal mode of operation MAY also be used   during network bootstrap before any schedule is installed into the   network so nodes can self-organize and the management and   configuration information be distributed.  In addition, the minimal   configuration MAY be used as a fall-back mode of operation, ensuring   connectivity of nodes in case that dynamic scheduling mechanisms fail   or are not available.  The IEEE 802.15.4 specification provides a   mechanism whereby the details of slotframe length, timeslot timing,   and channel hopping pattern are communicated when a node time   synchronizes to the network [IEEE802154].  This document describes   specific settings for these parameters.
[NEW]
 A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast   Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted   Channel Hopping (TSCH) links.
   The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the   use of both RPL and the 6LoWPAN adaptation layer framework   ([RFC4944], [RFC6282]) as defined over IEEE 802.14.5.  6LoWPAN   Neighbor Discovery [RFC6775] (ND) is also required to exchange   Compression Contexts, form IPv6 addresses and register them for the   purpose of Duplicate Address Detection, Address Resolution and   Neighbor Unreachability detection over one TSCH link.  In order to   reduce the header overhead of the RPL artifacts in data packets, the   Routing header [RFC6554], the RPL Option [RFC6553] and the related IP   in IP encapsulation MUST be encoded as prescribed in   [I-D.ietf-6lo-routing-dispatch]
   Nodes in a IEEE 802.15.4 TSCH network follow a communication   schedule.  A network using the simple mode of operation uses a static   schedule.
   This specification defines a Minimal Configuration to build a 6TiSCH   Network, using the Routing Protocol for LLNs (RPL) and a static TSCH   Schedule.  The 802.15.4 TSCH mode, RPL [RFC6550], and its Objective   Function 0 (OF0) [RFC6552], are used unmodified, but parameters and   particular operations are specified to guarantee interoperability   between nodes in a 6TiSCH Network.
   More advanced work is expected in the future to complement the   Minimal Configuration with dynamic operations that can adapt the   Schedule to the needs of the traffic in run time.  
Section 11.2
[OLD]
In addition to the Objective Function (OF), nodes in a multihop   network using RPL MUST indicate the preferred mode of operation using   the MOP field in DIO.  Nodes not being able to operate in the   specified mode of operation MUST only join as leaf nodes.  RPL   information and hop-by-hop extension headers MUST follow [RFC6553]   and [RFC6554] specification.  In the case that the packets formed at   the LLN need to cross through intermediate routers, these MUST follow   the IP in IP encapsulation requirement specified by the [RFC6282] and   [RFC2460].  RPI and RH3 extension headers and inner IP headers MUST   be compressed according to [RFC6282].
[NEW]
In addition to the Objective Function (OF), nodes in a multihop   network using RPL MUST indicate the preferred mode of operation using   the MOP field in DIO.  Nodes not being able to operate in the   specified mode of operation MUST only join as leaf nodes.  RPL   information and hop-by-hop extension headers MUST follow [RFC6553]   and [RFC6554] specification.  In the case that the packets formed at   the LLN need to cross through intermediate routers, these MUST follow   the IP in IP encapsulation requirement specified by the [RFC6282] and   [RFC2460].  RPI and RH3 extension headers and inner IP headers MUST   be compressed according to [RFC6282] and [I-D.ietf-6lo-routing-dispatch].  

have a nice weekend,Xavi

ksjp

---

From: Pat Kinney <[email-masked]>
Date: Sat, 12 Dec 2015 07:57:00 -0500

Hi  Qin;
A shared slot is open for all devices.  To transmit on this timeslot a device shall sense the medium for activity, if active it shall wait for the next available time slot.   Hence a shared slot is a contention access period for CSMA-CA.  This isn't slotted aloha, since it senses the medium first.
Pat

Patrick Kinney
Kinney Consulting
+1.847.960.3715
[email-masked]

> On Dec 11, 2015, at 5:06 PM, Qin Wang <[email-masked]> wrote:
> 
> Hi Pat,
> 
> Thanks
> Qin

---

From: Jonathan Simon <[email-masked]>
Date: Sat, 12 Dec 2015 14:29:26 -0800

Pat - unless something was changed in 802.15.4-2015, that was not how the
original TSCH shared slots worked.  Devices don't do carrier sense, since
transmissions are synchronized and talk at the same time (within sync
tolerances) - they do however back off using a similar backoff mechanism,
but counted in shared slots as opposed to time, to avoid persistent
collision.    I think that's what "slotted Aloha" is supposed to mean here
- a slotted shared medium without carrier sense.

Jonathan

On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney <
[email-masked]> wrote:

> Hi  Qin;
> A shared slot is open for all devices.  To transmit on this timeslot a
> device shall sense the medium for activity, if active it shall wait for the
> next available time slot.   Hence a shared slot is a contention access
> period for CSMA-CA.  This isn't slotted aloha, since it senses the medium
> first.
> Pat
>
> Patrick Kinney
> Kinney Consulting
> +1.847.960.3715
> According to my understanding, in the TSCH mode of 802.15.4, if the
> attribute of a slot is Shared, slotted- aloha access should be allowed in
> the slot. Right?
>
> Thanks
> Qin
>
>
>
> On Friday, December 11, 2015 2:29 PM, "[email-masked]"
> <[email-masked]> wrote:
>
>
> Xavi;
>
> As I understand slotted-aloha, TSCH is really Time Division Multiple
> Access (TDMA), not slotted-aloha.  Slotted-aloha access to the medium is
> used in the 802.15.4 CSMA algorithms for some modes but not TSCH.
>
> Pat
>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 14 Dec 2015 12:41:23 +0000

Can we get some text quoted from the appropriate IEEE spec(s) to support the positions in this discussion?

- Ralph

> On Dec 12, 2015, at 5:29 PM 12/12/15, Jonathan Simon <[email-masked]> wrote:
> 
> Pat - unless something was changed in 802.15.4-2015, that was not how the original TSCH shared slots worked.  Devices don't do carrier sense, since transmissions are synchronized and talk at the same time (within sync tolerances) - they do however back off using a similar backoff mechanism, but counted in shared slots as opposed to time, to avoid persistent collision.    I think that's what "slotted Aloha" is supposed to mean here - a slotted shared medium without carrier sense.
> 
> Jonathan
> 
> On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney <[email-masked]> wrote:
> Hi  Qin;

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 14 Dec 2015 18:18:17 -0600

I made an error in my earlier email, although shared slots do not require carrier sense, it is really recommended.  In most 15.4 modes (but not TSCH) when a device wishes to use a shared medium, the devices use CSMA to avoid collisions. Also, devices compliant to ETSI 300-328 must use carrier sense for LBT (802.15.4’s CSMA is cited in that regulation)

Pat
 
On 12, Dec2015, at 16:29, Jonathan Simon <[email-masked]> wrote:

Jonathan

On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney <[email-masked] <mailto:[email-masked]>> wrote:
Hi  Qin;
A shared slot is open for all devices.  To transmit on this timeslot a device shall sense the medium for activity, if active it shall wait for the next available time slot.   Hence a shared slot is a contention access period for CSMA-CA.  This isn't slotted aloha, since it senses the medium first.
Pat

Patrick Kinney
Kinney Consulting
+1.847.960.3715 <tel:%2B1.847.960.3715>
[email-masked] <mailto:[email-masked]>

On Dec 11, 2015, at 5:06 PM, Qin Wang <[email-masked] <mailto:[email-masked]>> wrote:

> On Friday, December 11, 2015 2:29 PM, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Xavi;
> 
> On 11, Dec2015, at 11:24, Xavier Vilajosana <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Dear all,
>

---

From: Jonathan Simon <[email-masked]>
Date: Mon, 14 Dec 2015 16:28:27 -0800

Pat - Carrier sense (via CCA) is an option in TSCH, so it can be used where
appropriate (e.g. for coexistence), but isn't required in general as part
of the media access scheme, again because it may not be useable in a
tightly synchronized network.

Jonathan

On Mon, Dec 14, 2015 at 4:18 PM, [email-masked] <
[email-masked]> wrote:

> I made an error in my earlier email, although shared slots do not require
> carrier sense, it is really recommended.  In most 15.4 modes (but not TSCH)
> when a device wishes to use a shared medium, the devices use CSMA to avoid
> collisions. Also, devices compliant to ETSI 300-328 must use carrier sense
> for LBT (802.15.4’s CSMA is cited in that regulation)
>
> Pat
>

-- 
Jonathan Simon
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

******************LINEAR TECHNOLOGY CORPORATION
CONFIDENTIAL******************

This e-mail transmission, and any documents, files or previous e-mail
messages attached to it may contain confidential information that is
legally privileged. If you are not the intended recipient, or person
responsible for delivering it to the intended recipient, you are hereby
notified that any disclosure, copying, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY
PROHIBITED. If you have received this transmission in error, please
immediately notify me by reply email or by telephone at 510-400-2936 and
delete the original transmission and its attachments without reading or
saving in any manner. Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 14:25:40 +0000

We need to reach consensus on this;

With minimal, we are using a time slotted medium with shared access. And we want to do cca to avoid collisions, don’t we? If that’s so, then even if the MAC has that optional, minimal needs it.
Should we call this TDMA? For some people (including Wikipedia and yours truly), TDMA is about exclusive access to time slots. Which will be the case of the slots that are assigned by the 6P protocol between parent and child, but is not the case of the minimal draft.  I agree that because we do cca, we are not aloha stricto sensu either.

What we are doing extends slotted-aloha to make it “polite”. In a way that makes minimal compliant with ETSI, since politeness is what the regulation is all about.

Will we agree if we replace “slotted-aloha” by “polite slotted-aloha” or “a polite form of slotted-aloha”?

Cheers,

Pascal

From: Jonathan Simon [mailto:[email-masked]]
Sent: mardi 15 décembre 2015 01:28
To: [email-masked]
Cc: Qin Wang <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; Xavier Vilajosana <[email-masked]>; Tero Kivinen <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Kris Pister <[email-masked]>; [email-masked]; 6tisch <[email-masked]>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Pat - Carrier sense (via CCA) is an option in TSCH, so it can be used where appropriate (e.g. for coexistence), but isn't required in general as part of the media access scheme, again because it may not be useable in a tightly synchronized network.

Jonathan

On Mon, Dec 14, 2015 at 4:18 PM, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>> wrote:
I made an error in my earlier email, although shared slots do not require carrier sense, it is really recommended.  In most 15.4 modes (but not TSCH) when a device wishes to use a shared medium, the devices use CSMA to avoid collisions. Also, devices compliant to ETSI 300-328 must use carrier sense for LBT (802.15.4’s CSMA is cited in that regulation)

Pat

On 12, Dec2015, at 16:29, Jonathan Simon <[email-masked]<mailto:[email-masked]>> wrote:

Jonathan

On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney <[email-masked]<mailto:[email-masked]>> wrote:
Hi  Qin;
A shared slot is open for all devices.  To transmit on this timeslot a device shall sense the medium for activity, if active it shall wait for the next available time slot.   Hence a shared slot is a contention access period for CSMA-CA.  This isn't slotted aloha, since it senses the medium first.
Pat

Patrick Kinney
Kinney Consulting
+1.847.960.3715<tel:%2B1.847.960.3715>
[email-masked]<mailto:[email-masked]>

On Dec 11, 2015, at 5:06 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pat,

Thanks
Qin

On Friday, December 11, 2015 2:29 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Xavi;

Pat

On 11, Dec2015, at 11:24, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Abstract:

[OLD]

[NEW]

Introduction:

[OLD]

[NEW]

Section 11.2

[OLD]

[NEW]

have a nice weekend,
Xavi

2015-12-11 17:49 GMT+01:00 Kris Pister <[email-masked]<mailto:[email-masked]>>:
Ralph - to my knowledge no one has deployed the specific time-parent
selection scheme described in 802.15.4-*.  The basic scheme will likely work,
but the devil will be in the real-world details.

ksjp

--
Jonathan Simon
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
[email-masked]<mailto:[email-masked]>

******************LINEAR TECHNOLOGY CORPORATION CONFIDENTIAL******************

This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply email or by telephone at 510-400-2936 and delete the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Dec 2015 08:40:55 -0600

We could change the sentence to : This minimal mode leverages 6LoWPAN and RPL to enable communication links over a static TSCH schedule via shared time-slots.

Pat

On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) <[email-masked]> wrote:

 

Cheers,
 
Pascal
 
From: Jonathan Simon [mailto:[email-masked] <mailto:[email-masked]>] 
Sent: mardi 15 décembre 2015 01:28
To: [email-masked] <mailto:[email-masked]>
Cc: Qin Wang <[email-masked] <mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>; Xavier Vilajosana <[email-masked] <mailto:[email-masked]>>; Tero Kivinen <[email-masked] <mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked] <mailto:[email-masked]>>; Kris Pister <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; 6tisch <[email-masked] <mailto:[email-masked]>>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Jonathan
 
On Mon, Dec 14, 2015 at 4:18 PM, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> wrote:
I made an error in my earlier email, although shared slots do not require carrier sense, it is really recommended.  In most 15.4 modes (but not TSCH) when a device wishes to use a shared medium, the devices use CSMA to avoid collisions. Also, devices compliant to ETSI 300-328 must use carrier sense for LBT (802.15.4’s CSMA is cited in that regulation)
 
Pat
 
On 12, Dec2015, at 16:29, Jonathan Simon <[email-masked] <mailto:[email-masked]>> wrote:

Jonathan

Patrick Kinney
Kinney Consulting

Hi Pat,

Thanks
Qin

Xavi;

Pat

Dear all,

Abstract:
 
[OLD]

[NEW]

Introduction:   
 
[OLD]

[NEW]

 

Section 11.2
 
[OLD]

[NEW]

have a nice weekend,
Xavi

ksjp

 

 

-- 
Jonathan Simon
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
[email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 14:57:18 +0000

Hello Pat:

> Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Time slotted Channel Hopping (TSCH) links.

> This minimal mode uses a collection of protocols including the 6LoWPAN

> framework and RPL to enable shared access operations over a static

> TSCH schedule.

Note that Ralph had an issue with the beginning of the sentence which now mentions a “collection of protocols”.

Otherwise, the last call text seems to be very similar to your proposal. Would you suggest to change the above abstract or is it OK as is?

Pascal

From: [email-masked] [mailto:[email-masked]]
Sent: vendredi 18 décembre 2015 15:41
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Simon Jonathan <[email-masked]>; Qin Wang <[email-masked]>; Xavier Vilajosana <[email-masked]>; Tero Kivinen <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Kris Pister <[email-masked]>; [email-masked]; 6tisch <[email-masked]>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Pat

On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Pascal

From: Jonathan Simon [mailto:[email-masked]]
Sent: mardi 15 décembre 2015 01:28
To: [email-masked]<mailto:[email-masked]>
Cc: Qin Wang <[email-masked]<mailto:[email-masked]>>; Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Xavier Vilajosana <[email-masked]<mailto:[email-masked]>>; Tero Kivinen <[email-masked]<mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked]<mailto:[email-masked]>>; Kris Pister <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 6tisch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Jonathan

Pat

Jonathan

Patrick Kinney
Kinney Consulting

Thanks
Qin

Xavi;

Pat

Dear all,

Abstract:

[OLD]

[NEW]

Introduction:

[OLD]

[NEW]

Section 11.2

[OLD]

[NEW]

have a nice weekend,
Xavi

ksjp

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 18 Dec 2015 14:59:16 +0000

I posted a similar suggestion on 2015-12-14: https://mailarchive.ietf.org/arch/search/?email_list=6tisch

> > This minimal mode uses a collection of protocols including the 6LoWPAN suite
> > and RPL to enable slotted-aloha operations over a static TSCH schedule.
> 
> I suggest finessing the "slotted-aloha" vs "CSMA" argument by s/slotted-aloha/shared timeslot/ or s/slotted-aloha//
> 
> Better yet, "slotted-aloha" or "CSMA" is too much detail for the Abstract.  How about something like "enable interoperation over IEEE 802.15.4 TSCH with minimal network configuration and infrastructure", which is what this document is really about?

I will reiterate my broader point - there is a serious risk of getting the text in this document out of sync with the published IEEE 802.15.4 specs.  You can minimized that risk by making maximum use of pointers to the IEEE specs and minimize the text in this document that restates the IEEE (and IETF and other) specs.

- Ralph

> On Dec 18, 2015, at 9:40 AM 12/18/15, [email-masked] wrote:
> 
> On Mon, Dec 14, 2015 at 4:18 PM, [email-masked] <[email-masked]> wrote:

---

From: "Salazar, Ruben" <[email-masked]>
Date: Fri, 18 Dec 2015 15:13:28 +0000

I tend to agree that we should either be high level in the description of the document, like suggested by Ralph, or if we want to go into the detail then we must use the naming adopted already in the cited-standards, like TSCH with cca.
TSCH with cca is more than "polite" slotted-aloha: it has a significant impact on the overall network throughput, it has much higher throughput than slotted aloha: it would be misleading to use term "slotted aloha" just because it is more familiar. By now, with all the work been done in 6TiSCH, I believe that most of the participants are already familiar with TSCH.
Regards

____________________________________________________________________________________________________________
Ruben Salazar, PhD   |   Landis+Gyr  |   Global Head of Research and Technology
Office:  +1 678 258 3165  |  Email: [email-masked]   |   Address: 30000 Mill Creek Av., Alpharetta, GA 30022, USA

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Ralph Droms (rdroms)
Sent: Friday, December 18, 2015 9:59 AM
To: [email-masked]
Cc: Pascal Thubert (pthubert) <[email-masked]>; Xavier Vilajosana <[email-masked]>; Kris Pister <[email-masked]>; Tero Kivinen <[email-masked]>; 6tisch <[email-masked]>; Simon Jonathan <[email-masked]>; [email-masked]
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

> > This minimal mode uses a collection of protocols including the
> > 6LoWPAN suite and RPL to enable slotted-aloha operations over a static TSCH schedule.
>
> I suggest finessing the "slotted-aloha" vs "CSMA" argument by
> s/slotted-aloha/shared timeslot/ or s/slotted-aloha//
>

- Ralph

> Cc: Qin Wang <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>; Xavier Vilajosana
> <[email-masked]>; Tero Kivinen <[email-masked]>; Ralph
> Droms (rdroms) <[email-masked]>; Kris Pister <[email-masked]>;
> [email-masked]; 6tisch <[email-masked]>
> I made an error in my earlier email, although shared slots do not
> require carrier sense, it is really recommended.  In most 15.4 modes
> (but not TSCH) when a device wishes to use a shared medium, the
> devices use CSMA to avoid collisions. Also, devices compliant to ETSI
> 300-328 must use carrier sense for LBT (802.15.4’s CSMA is cited in
> that regulation)
>
> Pat
>
> selection scheme described in 802.15.4-*.  The basic scheme will
> likely work, but the devil will be in the real-world details.
>
> We've had about 8 years of successful deployments of industrial tsch
> mesh networks using a time-parent selection scheme similar to what is
> proposed in minimal.
>
> 6TiSCH present a rich design space at many levels.  The goal of
> minimal was to do something simple, based as closely as possible on
> things that are known to work in deployed networks.  The hope and
> belief is that new and better ideas will emerge, but it is certain
> that many of the proposed "good ideas" will fail.  By defining minimal
> we provide a reliable interoperable platform on which papers like
> "Comparing time-parent selection in 15.4-* and foo" can be written.
>
> ksjp
>

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 15:47:27 +0000

Hello Ruben:

Looks good. Is the text in the consensus call OK with you then?

Pascal

> From: Salazar, Ruben [mailto:[email-masked]]
> Sent: vendredi 18 décembre 2015 16:13
> To: Ralph Droms (rdroms) <[email-masked]>;
> Cc: Pascal Thubert (pthubert) <[email-masked]>; Xavier Vilajosana
> <[email-masked]>; Kris Pister <[email-masked]>; Tero Kivinen
> <[email-masked]>; 6tisch <[email-masked]>; Simon Jonathan
> <[email-masked]>; [email-masked]
> Subject: RE: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal
> 
> I tend to agree that we should either be high level in the description of the
> document, like suggested by Ralph, or if we want to go into the detail then we
> must use the naming adopted already in the cited-standards, like TSCH with cca.
> TSCH with cca is more than "polite" slotted-aloha: it has a significant impact on
> the overall network throughput, it has much higher throughput than slotted
> aloha: it would be misleading to use term "slotted aloha" just because it is more
> familiar. By now, with all the work been done in 6TiSCH, I believe that most of
> the participants are already familiar with TSCH.
> Regards
> 
> _________________________________________________________________
> ___________________________________________
> Office:  +1 678 258 3165  |  Email: [email-masked]   |   Address:
> 30000 Mill Creek Av., Alpharetta, GA 30022, USA
> 
> Cc: Pascal Thubert (pthubert) <[email-masked]>; Xavier Vilajosana
> <[email-masked]>; Kris Pister <[email-masked]>; Tero Kivinen
> <[email-masked]>; 6tisch <[email-masked]>; Simon Jonathan
> <[email-masked]>; [email-masked]
> I posted a similar suggestion on 2015-12-14:
> https://mailarchive.ietf.org/arch/search/?email_list=6tisch
> 
> > Better yet, "slotted-aloha" or "CSMA" is too much detail for the Abstract.  How
> about something like "enable interoperation over IEEE 802.15.4 TSCH with
> minimal network configuration and infrastructure", which is what this document
> is really about?
> 
> I will reiterate my broader point - there is a serious risk of getting the text in this
> document out of sync with the published IEEE 802.15.4 specs.  You can
> minimized that risk by making maximum use of pointers to the IEEE specs and
> minimize the text in this document that restates the IEEE (and IETF and other)
> specs.
> 
> - Ralph
> 
> 
> > We could change the sentence to : This minimal mode leverages 6LoWPAN
> and RPL to enable communication links over a static TSCH schedule via shared
> time-slots.
> >
> > Pat
> >
> >
> > With minimal, we are using a time slotted medium with shared access. And we
> want to do cca to avoid collisions, don’t we? If that’s so, then even if the MAC
> has that optional, minimal needs it.
> > Should we call this TDMA? For some people (including Wikipedia and yours
> truly), TDMA is about exclusive access to time slots. Which will be the case of
> the slots that are assigned by the 6P protocol between parent and child, but is
> not the case of the minimal draft.  I agree that because we do cca, we are not
> aloha stricto sensu either.
> >
> > What we are doing extends slotted-aloha to make it “polite”. In a way that
> makes minimal compliant with ETSI, since politeness is what the regulation is all
> about.
> >
> appropriate (e.g. for coexistence), but isn't required in general as part of the
> media access scheme, again because it may not be useable in a tightly
> synchronized network.
> >
> > Jonathan
> >
> > On Mon, Dec 14, 2015 at 4:18 PM, [email-masked]
> tolerances) - they do however back off using a similar backoff mechanism, but
> counted in shared slots as opposed to time, to avoid persistent collision.    I think
> that's what "slotted Aloha" is supposed to mean here - a slotted shared medium
> without carrier sense.
> >
> > Jonathan
> >
> > On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney
> > A shared slot is open for all devices.  To transmit on this timeslot a device shall
> sense the medium for activity, if active it shall wait for the next available time
> slot.   Hence a shared slot is a contention access period for CSMA-CA.  This isn't
> slotted aloha, since it senses the medium first.
> > Pat
> >
> > Patrick Kinney
> > Kinney Consulting
> > +1.847.960.3715
> > According to my understanding, in the TSCH mode of 802.15.4, if the attribute
> of a slot is Shared, slotted- aloha access should be allowed in the slot. Right?
> >
> > Thanks
> > Qin
> >
> >
> >
> > As I understand slotted-aloha, TSCH is really Time Division Multiple Access
> (TDMA), not slotted-aloha.  Slotted-aloha access to the medium is used in the
> 802.15.4 CSMA algorithms for some modes but not TSCH.
> >
> > Pat
> >
> messages attached to it may contain confidential information that is legally
> privileged. If you are not the intended recipient, or person responsible for
> delivering it to the intended recipient, you are hereby notified that any
> disclosure, copying, distribution or use of any of the information contained in or
> attached to this transmission is STRICTLY PROHIBITED. If you have received this
> transmission in error, please immediately notify me by reply email or by
> telephone at 510-400-2936 and delete the original transmission and its
> attachments without reading or saving in any manner. Thank you.
> >
> >
> This e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized representative
> of an intended recipient, you are prohibited from using, copying or distributing
> the information in this e-mail or its attachments. If you have received this e-mail
> in error, please notify the sender immediately by return e-mail and delete all
> copies of this message and any attachments. Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 15:52:29 +0000

Your recommendation makes full sense Ralph; the point here is that what we are doing with minimal is one of the many ways we can use TSCH, shared slot vs. not, CCA vs. not. We want to express that.
The text in the consensus call echoes your suggestion below, and I'm trying to get consensus around it.

Pascal

> Sent: vendredi 18 décembre 2015 15:59
> Cc: Pascal Thubert (pthubert) <[email-masked]>; Tero Kivinen
> <[email-masked]>; Kris Pister <[email-masked]>; Xavier Vilajosana
> <[email-masked]>; 6tisch <[email-masked]>; Simon Jonathan

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 18 Dec 2015 15:56:15 +0000

I'll respond on the thread for the consensus call.

- Ralph

> On Dec 18, 2015, at 10:52 AM 12/18/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
>

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Dec 2015 10:00:57 -0600

You’re correct, they are very similar so no need to change.

Pat

On 18, Dec2015, at 8:57, Pascal Thubert (pthubert) <[email-masked]> wrote:

Hello Pat:

 
 
Pascal
 
From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] 
Sent: vendredi 18 décembre 2015 15:41
To: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
Cc: Simon Jonathan <[email-masked] <mailto:[email-masked]>>; Qin Wang <[email-masked] <mailto:[email-masked]>>; Xavier Vilajosana <[email-masked] <mailto:[email-masked]>>; Tero Kivinen <[email-masked] <mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked] <mailto:[email-masked]>>; Kris Pister <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; 6tisch <[email-masked] <mailto:[email-masked]>>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Pat

On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:

 

Cheers,
 
Pascal

 
Jonathan

Pat

 
Jonathan

Patrick Kinney
Kinney Consulting

Hi Pat,

Thanks
Qin

Xavi;

Pat

Dear all,

Abstract:
 
[OLD]

[NEW]

Introduction:   
 
[OLD]

[NEW]

 

Section 11.2
 
[OLD]

[NEW]

have a nice weekend,
Xavi

ksjp

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 18 Dec 2015 17:47:01 +0100

As Jonathan said in a previous thread. CCA is optional and does not bring a
big advantage as nodes are synchronized and communication occurs at the
same time and hence CCA does not bring a lot. Maybe to get some benefit in
duty cycle regulation due to LBT and maybe to avoid some external
interference. But at the end the behaviour in shared slots is slotted aloha
if this CCA option is not used.

regards,
Xavi

2015-12-18 17:00 GMT+01:00 [email-masked] <
[email-masked]>:

> Otherwise, the last call text seems to be very similar to your proposal.
> Would you suggest to change the above abstract or is it OK as is?
>
> Pascal
>
> *From:* [email-masked] [
> mailto:[email-masked]
> <[email-masked]>]
> *Sent:* vendredi 18 décembre 2015 15:41
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Simon Jonathan <[email-masked]>; Qin Wang <[email-masked]>;
> Xavier Vilajosana <[email-masked]>; Tero Kivinen <
> [email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Kris Pister <
> [email-masked]>; [email-masked]; 6tisch <
> [email-masked]>
> We could change the sentence to : This minimal mode leverages 6LoWPAN and
> RPL to enable communication links over a static TSCH schedule via shared
> time-slots.
>
> Pat
>
>
> With minimal, we are using a time slotted medium with shared access. And
> we want to do cca to avoid collisions, don’t we? If that’s so, then even if
> the MAC has that optional, minimal needs it.
> truly), TDMA is about exclusive access to time slots. Which will be the
> case of the slots that are assigned by the 6P protocol between parent and
> child, but is not the case of the minimal draft.  I agree that because we
> do cca, we are not aloha stricto sensu either.
>
> makes minimal compliant with ETSI, since politeness is what the regulation
> is all about.
>
> *From:* Jonathan Simon [mailto:[email-masked] <[email-masked]>]
> *Sent:* mardi 15 décembre 2015 01:28
> *To:* [email-masked]
> *Cc:* Qin Wang <[email-masked]>; Pascal Thubert (pthubert) <
> [email-masked]>; Xavier Vilajosana <[email-masked]>;
> Tero Kivinen <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>;
> Kris Pister <[email-masked]>; [email-masked];
> 6tisch <[email-masked]>
> Pat - Carrier sense (via CCA) is an option in TSCH, so it can be used
> where appropriate (e.g. for coexistence), but isn't required in general as
> part of the media access scheme, again because it may not be useable in a

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 16:55:28 +0000

Hello Xavi:
Point is, we are doing statistical multiplexing in the minimal time slots. If a node starts talking, the others should yield.
The draft says that CCA is optional; this is not a very strong language. Shouldn’t we encourage it a bit more loudly?

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: vendredi 18 décembre 2015 17:47
To: [email-masked]
Cc: Pascal Thubert (pthubert) <[email-masked]>; Tero Kivinen <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Kris Pister <[email-masked]>; 6tisch <[email-masked]>; Simon Jonathan <[email-masked]>; [email-masked]
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

As Jonathan said in a previous thread. CCA is optional and does not bring a big advantage as nodes are synchronized and communication occurs at the same time and hence CCA does not bring a lot. Maybe to get some benefit in duty cycle regulation due to LBT and maybe to avoid some external interference. But at the end the behaviour in shared slots is slotted aloha if this CCA option is not used.

regards,
Xavi

2015-12-18 17:00 GMT+01:00 [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>:
You’re correct, they are very similar so no need to change.

Pat

On 18, Dec2015, at 8:57, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Pat:

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: vendredi 18 décembre 2015 15:41
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: Simon Jonathan <[email-masked]<mailto:[email-masked]>>; Qin Wang <[email-masked]<mailto:[email-masked]>>; Xavier Vilajosana <[email-masked]<mailto:[email-masked]>>; Tero Kivinen <[email-masked]<mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked]<mailto:[email-masked]>>; Kris Pister <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; 6tisch <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Pat

Cheers,

Pascal

Jonathan

Pat

Jonathan

Patrick Kinney
Kinney Consulting

Thanks
Qin

Xavi;

Pat

Dear all,

Abstract:

[OLD]

[NEW]

Introduction:

[OLD]

[NEW]

Section 11.2

[OLD]

[NEW]

have a nice weekend,
Xavi

ksjp

--
Jonathan Simon
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936<tel:%28510%29%20400-2936>
(510) 489-3799<tel:%28510%29%20489-3799> FAX
[email-masked]<mailto:[email-masked]>

******************LINEAR TECHNOLOGY CORPORATION CONFIDENTIAL******************
This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply email or by telephone at 510-400-2936<tel:510-400-2936> and delete the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Dec 2015 11:12:43 -0600

Xavi;

I agree that CCA does not buy anything when a time-slot is assigned, but it does make a significant difference for shared slots, especially when traffic for them is high.  When a device backs off due to CCA detection, that device does not expend the energy of transmitting its packet and then listening for the ACK.  It also prevents that same device from colliding with another transmission saving energy for the devices in that exchange. 

Finally, hopefully we’ve gone beyond the slotted aloha discussion.

Pat
 
On 18, Dec2015, at 10:47, Xavier Vilajosana <[email-masked]> wrote:

regards,
Xavi

2015-12-18 17:00 GMT+01:00 [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>:
You’re correct, they are very similar so no need to change.

Pat

On 18, Dec2015, at 8:57, Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>> wrote:

Hello Pat:

 
 
Pascal

 
Pat

 

 
Cheers,
 
Pascal

 
Jonathan

Pat

 
Jonathan

Patrick Kinney
Kinney Consulting

Hi Pat,

Thanks
Qin

Xavi;

Pat

Dear all,

Abstract:
 
[OLD]

[NEW]

Introduction:   
 
[OLD]

[NEW]

 

Section 11.2
 
[OLD]

[NEW]

have a nice weekend,
Xavi

ksjp

 

 

-- 
Jonathan Simon
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936 <tel:%28510%29%20400-2936>
(510) 489-3799 <tel:%28510%29%20489-3799> FAX
[email-masked] <mailto:[email-masked]>
 
******************LINEAR TECHNOLOGY CORPORATION CONFIDENTIAL******************
This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply email or by telephone at 510-400-2936 <tel:510-400-2936> and delete the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 18 Dec 2015 12:19:11 -0500

> On Dec 18, 2015, at 11:55 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Xavi:

What do the IEEE 802.15.4 specs require for the use of slots marked as shared?

> 2015-12-18 17:00 GMT+01:00 [email-masked] <[email-masked]>:

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Dec 2015 11:43:11 -0600

According to 802.15.4, shared time slots may use CCA but are not required to use CCA.

Pat

On 18, Dec2015, at 11:19, Ralph Droms <[email-masked]> wrote:

>  
> Cheers,
>  
> Pascal
>  
> From: [email-masked] <mailto:[email-masked]> [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Xavier Vilajosana
> Cc: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>; Tero Kivinen <[email-masked] <mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked] <mailto:[email-masked]>>; Kris Pister <[email-masked] <mailto:[email-masked]>>; 6tisch <[email-masked] <mailto:[email-masked]>>; Simon Jonathan <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2015 17:55:52 +0000

And what would be your recommendation for 6TiSCH, Pat?

Pascal

Le 18 déc. 2015 à 18:43, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> a écrit :

Pat

On 18, Dec2015, at 11:19, Ralph Droms <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 18, 2015, at 11:55 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Xavi:

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: vendredi 18 décembre 2015 17:47
To: [email-masked]<mailto:[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Tero Kivinen <[email-masked]<mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked]<mailto:[email-masked]>>; Kris Pister <[email-masked]<mailto:[email-masked]>>; 6tisch <[email-masked]<mailto:[email-masked]>>; Simon Jonathan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

regards,
Xavi

Pat

Hello Pat:

Pascal

Pat

Cheers,

Pascal

Jonathan

Pat

Jonathan

Patrick Kinney
Kinney Consulting

Thanks
Qin

Xavi;

Pat

Dear all,

Abstract:

[OLD]

[NEW]

Introduction:

[OLD]

[NEW]

Section 11.2

[OLD]

[NEW]

have a nice weekend,
Xavi

ksjp

---

From: Kris Pister <[email-masked]>
Date: Fri, 18 Dec 2015 10:35:58 -0800

Pascal -
CCA can be a useful feature in a TSCH network.  It is certainly useful 
if the EU standards
prevent you from selling your devices without it.  It doesn't provide 
much benefit for
the purpose that you describe below however.

Most motes in a TSCH network will the synchronized to a small fraction 
of the guard
time (+/- 1 ms default for minimal).  That's just simple statistics - if 
six sigma of the
synchronization error distribution is approach the guard time, then 
you're already
in deep trouble with motes falling out of the network.

Published academic networks routinely run with a few tens of 
microseconds of
synchronization error.  Commercial networks can be below one microsecond 
RMS.
In general, synchronization improves with increasing network traffic, as 
the motes
get updates more frequently.

Compare these numbers to the RX-to-TX turnaround time specified in the 
15.4 standard,
which is 192 microseconds.  If I'm supposed to start transmitting at 
time T0, I need
to *end* my CCA RX of the channel something like 192 microseconds before 
T0.  But
everyone who might collide with my transmission is also planning to 
transmit at
time TO.  As described above, they will probably succeed with an error 
of a few
microseconds, to possibly tens of microseconds.  Result: I won't hear them.

192 microseconds is the upper bound given in the standard, and most 
radios are
faster.  But even so CCA is just not going to help you very often. It 
may be useful
to detect WiFi or other interferers, but it won't detect other motes in 
your
network contending for the same slot.

ksjp

On 12/18/2015 8:55 AM, Pascal Thubert (pthubert) wrote:
>
> Hello Xavi:
>
> Point is, we are doing statistical multiplexing in the minimal time 
> slots. If a node starts talking, the others should yield.
>
> The draft says that CCA is optional; this is not a very strong 
> language. Shouldn’t we encourage it a bit more loudly?
>
> Cheers,
>
> Pascal
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Xavier Vilajosana
> *Sent:* vendredi 18 décembre 2015 17:47
> *Cc:* Pascal Thubert (pthubert) <[email-masked]>; Tero Kivinen 
> <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Kris Pister 
> <[email-masked]>; 6tisch <[email-masked]>; Simon Jonathan 
> As Jonathan said in a previous thread. CCA is optional and does not 
> bring a big advantage as nodes are synchronized and communication 
> occurs at the same time and hence CCA does not bring a lot. Maybe to 
> get some benefit in duty cycle regulation due to LBT and maybe to 
> avoid some external interference. But at the end the behaviour in 
> shared slots is slotted aloha if this CCA option is not used.
>
> regards,
>
> Xavi
>
> 2015-12-18 17:00 GMT+01:00 [email-masked] 
> <mailto:[email-masked]> 
> <[email-masked] 
> <mailto:[email-masked]>>:
>
>     On 18, Dec2015, at 8:57, Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Pat:
>
>     6LoWPAN
>     Note that Ralph had an issue with the beginning of the sentence
>     which now mentions a “collection of protocols”.
>
>     Otherwise, the last call text seems to be very similar to your
>     proposal. Would you suggest to change the above abstract or is it
>     OK as is?
>
>     Pascal
>
>     *From:[email-masked]
>     <mailto:[email-masked]> [mailto:[email-masked]]
>
>     *To:* Pascal Thubert (pthubert) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Simon Jonathan <[email-masked]
>     <mailto:[email-masked]>>; Qin Wang <[email-masked]
>     <mailto:[email-masked]>>; Xavier Vilajosana
>     <[email-masked]
>     <mailto:[email-masked]>>; Tero Kivinen
>     <[email-masked] <mailto:[email-masked]>>; Ralph Droms (rdroms)
>     <[email-masked] <mailto:[email-masked]>>; Kris Pister
>     <[email-masked] <mailto:[email-masked]>>;
>     [email-masked]
>     <mailto:[email-masked]>; 6tisch
>     <[email-masked] <mailto:[email-masked]>>
>     We could change the sentence to : This minimal mode leverages
>     6LoWPAN and RPL to enable communication links over a static
>     TSCH schedule via shared time-slots.
>
>     Pat
>
>     On 18, Dec2015, at 8:25, Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     With minimal, we are using a time slotted medium with shared
>     access. And we want to do cca to avoid collisions, don’t we? If
>     that’s so, then even if the MAC has that optional, minimal needs it.
>
>     Should we call this TDMA? For some people (including Wikipedia and
>     yours truly), TDMA is about exclusive access to time slots. Which
>     will be the case of the slots that are assigned by the 6P protocol
>     between parent and child, but is not the case of the minimal
>     draft.  I agree that because we do cca, we are not aloha stricto
>     sensu either.
>
>     What we are doing extends slotted-aloha to make it “polite”. In a
>     way that makes minimal compliant with ETSI, since politeness is
>     what the regulation is all about.
>
>     Will we agree if we replace “slotted-aloha” by “polite
>     slotted-aloha” or “a polite form of slotted-aloha”?
>
>     Cheers,
>
>     Pascal
>
>     *From:* Jonathan Simon [mailto:[email-masked]]
>     <mailto:[email-masked]>
>     *Cc:* Qin Wang <[email-masked]
>     <mailto:[email-masked]>>; Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>>; Xavier
>     Vilajosana <[email-masked]
>     <mailto:[email-masked]>>; Tero Kivinen
>     <[email-masked] <mailto:[email-masked]>>; Ralph Droms (rdroms)
>     <[email-masked] <mailto:[email-masked]>>; Kris Pister
>     <[email-masked] <mailto:[email-masked]>>;
>     [email-masked]
>     <mailto:[email-masked]>; 6tisch
>     <[email-masked] <mailto:[email-masked]>>
>     Pat - Carrier sense (via CCA) is an option in TSCH, so it can be
>     used where appropriate (e.g. for coexistence), but isn't required
>     in general as part of the media access scheme, again because it
>     may not be useable in a tightly synchronized network.
>
>     Jonathan
>
>     <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         I made an error in my earlier email, although shared slots do
>         not require carrier sense, it is really recommended.  In most
>         15.4 modes (but not TSCH) when a device wishes to use a shared
>         medium, the devices use CSMA to avoid collisions. Also,
>         devices compliant to ETSI 300-328 must use carrier sense for
>         LBT (802.15.4’s CSMA is cited in that regulation)
>
>         Pat
>
>         Pat - unless something was changed in 802.15.4-2015, that was
>         not how the original TSCH shared slots worked. Devices don't
>         do carrier sense, since transmissions are synchronized and
>         talk at the same time (within sync tolerances) - they do
>         however back off using a similar backoff mechanism, but
>         counted in shared slots as opposed to time, to avoid
>         persistent collision.  I think that's what "slotted Aloha" is
>         supposed to mean here - a slotted shared medium without
>         carrier sense.
>
>         Jonathan
>
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi  Qin;
>
>             A shared slot is open for all devices.  To transmit on
>             this timeslot a device shall sense the medium for
>             activity, if active it shall wait for the next available
>             time slot.   Hence a shared slot is a contention access
>             period for CSMA-CA. This isn't slotted aloha, since it
>             senses the medium first.
>
>             Pat
>
>
>             Patrick Kinney
>
>             Kinney Consulting
>
>             <mailto:[email-masked]>
>
>
>             On Dec 11, 2015, at 5:06 PM, Qin Wang
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 Hi Pat,
>
>                 According to my understanding, in the TSCH mode of
>                 802.15.4, if the attribute of a slot is Shared,
>                 slotted- aloha access should be allowed in the slot.
>                 Right?
>
>                 Thanks
>
>                 Qin
>
>                 On Friday, December 11, 2015 2:29 PM,
>                 "[email-masked]
>                 <mailto:[email-masked]>"
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                 Xavi;
>
>                 As I understand slotted-aloha, TSCH is really Time
>                 Division Multiple Access (TDMA), not slotted-aloha.
>                 Slotted-aloha access to the medium is used in the
>                 On 11, Dec2015, at 11:24, Xavier Vilajosana
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                 Dear all,
>
>                  6LoWPAN
>                 2015-12-11 17:49 GMT+01:00 Kris Pister
>                 <[email-masked] <mailto:[email-masked]>>:
>
>                         Is there an analysis published somewhere that
>                         demonstrates how time synchronization in
>                         802.15.4-* is inadequate for 6TiSCH?
>
>     This e-mail transmission, and any documents, files or previous
>     e-mail messages attached to it may contain confidential
>     information that is legally privileged. If you are not the
>     intended recipient, or person responsible for delivering it to the
>     intended recipient, you are hereby notified that any disclosure,
>     copying, distribution or use of any of the information contained
>     in or attached to this transmission is STRICTLY PROHIBITED. If you
>     have received this transmission in error, please immediately
>     notify me by reply email or by telephone at 510-400-2936
>     <tel:510-400-2936> and delete the original transmission and
>     its attachments without reading or saving in any manner. Thank you.
>

---

From: Kris Pister <[email-masked]>
Date: Fri, 18 Dec 2015 10:53:00 -0800

I have no attachment to having "slotted-aloha" appear in the text. I 
agree that
we should use naming consistent with the 15.4 document.

The behavior of the traffic will in fact be identical to a slotted-aloha 
MAC,
whatever we choose to call it.

ksjp

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 18 Dec 2015 13:38:41 -0600

Kris;

It seems that your point is essentially that if the minimal network is the only network within transmission range, then CCA is not necessary.  However, since this is an ISM band, ignoring other devices such as 802.11, 802.15.4 CSMA, or even other minimal networks, will cause many devices to retransmit due to the collisions, which would further congest the band.  

Moreover, you are correct that a device wishing to transmit would start its CCA at T=1800 microseconds with CCA being 128 microseconds and Rx to Tx being 192 microseconds, so a device would only detect another device if that device started transmitting 320 microseconds “early” within the the allowed margin of 1100 microseconds.  I believe that the synchronization errors for those devices minimally active will be much greater than more active devices.

Finally, I believe that a device should use CCA as is required in IEC 62591(WHART) and IEC 62734 (ISA100.11a).

Pat

On 18, Dec2015, at 12:35, Kris Pister <[email-masked]> wrote:

Pascal - 
CCA can be a useful feature in a TSCH network.  It is certainly useful if the EU standards
prevent you from selling your devices without it.  It doesn't provide much benefit for
the purpose that you describe below however.

Most motes in a TSCH network will the synchronized to a small fraction of the guard
time (+/- 1 ms default for minimal).  That's just simple statistics - if six sigma of the
synchronization error distribution is approach the guard time, then you're already
in deep trouble with motes falling out of the network.

Published academic networks routinely run with a few tens of microseconds of 
synchronization error.  Commercial networks can be below one microsecond RMS.
In general, synchronization improves with increasing network traffic, as the motes
get updates more frequently.

Compare these numbers to the RX-to-TX turnaround time specified in the 15.4 standard,
which is 192 microseconds.  If I'm supposed to start transmitting at time T0, I need
to *end* my CCA RX of the channel something like 192 microseconds before T0.  But
everyone who might collide with my transmission is also planning to transmit at
time TO.  As described above, they will probably succeed with an error of a few 
microseconds, to possibly tens of microseconds.  Result: I won't hear them.

192 microseconds is the upper bound given in the standard, and most radios are
faster.  But even so CCA is just not going to help you very often.  It may be useful 
to detect WiFi or other interferers, but it won't detect other motes in your 
network contending for the same slot.

ksjp

On 12/18/2015 8:55 AM, Pascal Thubert (pthubert) wrote:
> Cc: Pascal Thubert (pthubert) <[email-masked]> <mailto:[email-masked]>; Tero Kivinen <[email-masked]> <mailto:[email-masked]>; Ralph Droms (rdroms) <[email-masked]> <mailto:[email-masked]>; Kris Pister <[email-masked]> <mailto:[email-masked]>; 6tisch <[email-masked]> <mailto:[email-masked]>; Simon Jonathan <[email-masked]> <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> 2015-12-18 17:00 GMT+01:00  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>:
> On 18, Dec2015, at 8:57, Pascal Thubert (pthubert) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hello Pat:
>  
> From:  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> [ <mailto:[email-masked]>mailto:[email-masked] <mailto:[email-masked]>] 
> To: Pascal Thubert (pthubert) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>
> Cc: Simon Jonathan < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Qin Wang < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Xavier Vilajosana < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Tero Kivinen < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Ralph Droms (rdroms) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Kris Pister < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>;  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>; 6tisch < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>
> On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Jonathan Simon [ <mailto:[email-masked]>mailto:[email-masked] <mailto:[email-masked]>] 
> To:  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
> Cc: Qin Wang < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Pascal Thubert (pthubert) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Xavier Vilajosana < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Tero Kivinen < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Ralph Droms (rdroms) < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>; Kris Pister < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>;  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>; 6tisch < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>
> On Mon, Dec 14, 2015 at 4:18 PM,  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]> < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
> On 12, Dec2015, at 16:29, Jonathan Simon < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>  
> On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
> Hi  Qin;
>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
> 
> On Dec 11, 2015, at 5:06 PM, Qin Wang < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Pat,
>  
> On Friday, December 11, 2015 2:29 PM, " <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>" < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> Xavi;
>  
> On 11, Dec2015, at 11:24, Xavier Vilajosana < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>  
> Dear all,
>  
>  <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a>https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a>
>  
> 2015-12-11 17:49 GMT+01:00 Kris Pister < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>>:
>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>  <https://www.ietf.org/mailman/listinfo/6tisch>https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>  
>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>  <https://www.ietf.org/mailman/listinfo/6tisch>https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>  
>  
>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>  <https://www.ietf.org/mailman/listinfo/6tisch>https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
>  
> 
>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>  <https://www.ietf.org/mailman/listinfo/6tisch>https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>  <https://www.ietf.org/mailman/listinfo/6tisch>https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>
> 
> 
>  
>  
> 
> 
>  
> -- 
> Jonathan Simon
>  <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>
>

---

From: Jonathan Simon <[email-masked]>
Date: Fri, 18 Dec 2015 11:49:20 -0800

Pat -

WirelessHART requires that CCA be supported, not enabled. In practice it
isn't used unless required by local regulation.  FYI 62591 v1.0 copies an
error in the WirelessHART spec that mandates carrier sense for CCA.  The
latest WirelessHART spec (and the upcoming 62591 v2.0) corrects this to
allow all CCA modes and defaults to energy detect.

Jonathan

On Fri, Dec 18, 2015 at 11:38 AM, [email-masked] <
[email-masked]> wrote:

> Kris;
>
> It seems that your point is essentially that if the minimal network is the
> only network within transmission range, then CCA is not necessary.
> However, since this is an ISM band, ignoring other devices such as 802.11,
> 802.15.4 CSMA, or even other minimal networks, will cause many devices to
> retransmit due to the collisions, which would further congest the band.
>
> Moreover, you are correct that a device wishing to transmit would start
> its CCA at T=1800 microseconds with CCA being 128 microseconds and Rx to Tx
> being 192 microseconds, so a device would only detect another device if
> that device started transmitting 320 microseconds “early” within the the
> allowed margin of 1100 microseconds.  I believe that the synchronization
> errors for those devices minimally active will be much greater than more
> active devices.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 19 Dec 2015 09:55:07 +0000

Hello Kris:

I certainly buy your arguments, which fit the intuition of the network operation.

There are two additional angles that may influence this proposition, though, both relating to uses cases that minimal enables and that are a lot less engineered than the art TSCH:

-        One is a case where more than one minimal 6TiSCH network are deployed in one interference domain. The networks may not be coordinated and they may not be synchronized. Say they are dimensioned for their own traffic but not for necessarily twice that traffic. If they both operate around the default of 100 slots per slotframe, the chances of contact are very low. Yet there’s this roughly 1/1000 chance that the end up on a same channel at a shifted time, and if the slot duration is the same, the collision becomes systematic. In that case both networks may experience degradation. CCA may still help that case just like it may help coexistence with other types of networks.  If we do CCA, only the network which is slightly lagging will experience bad performances, which is half of the way. It may make sense to provide recommendations for that sort of case, like, if there is a minimum of coordinated configuration available, then at least do not use slotframes of equal length and if possible make them prime to one another to avoid systematic collisions.

-        The other is longer sleep and higher drifts. Would it be possible that because the minimal devices experience more asynchronous / statistical traffic, there may be a wider distribution of interval between frames and thus of time drifts? If so, wouldn’t it be possible that 2 devices are desynchronized enough that one starts emitting while the other is still sensing the channel, in which case CCA would protect the first come?

Also, CCA simplifies the compliance with regulation in Europe and countries that follow the same regulations.

I’m hearing though that 200328 2.0 will be more open to channel hoppers. I’ll try to get the exact wording but I understand that you can be a channel hopper if you hop between 5 channels as opposed to 15 as before. So CCA may be less critical there as it was before.

All in all, I do not see a strong case for CCA, but incremental benefits. I also sense some push back against it but I have less understanding of where that comes from. Is that an battery drain problem? Is that a matter of complexity?

Thanks for all this,
Pascal

From: Kris Pister [mailto:[email-masked]]
Sent: vendredi 18 décembre 2015 19:36
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: 6tisch <[email-masked]>; [email-masked]
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Pascal -

ksjp

Cheers,

Pascal

Cc: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>; Tero Kivinen <[email-masked]><mailto:[email-masked]>; Ralph Droms (rdroms) <[email-masked]><mailto:[email-masked]>; Kris Pister <[email-masked]><mailto:[email-masked]>; 6tisch <[email-masked]><mailto:[email-masked]>; Simon Jonathan <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

regards,
Xavi

Pat

Hello Pat:

Pascal

Pat

Cheers,

Pascal

Jonathan

Pat

Jonathan

Patrick Kinney
Kinney Consulting

Thanks
Qin

Xavi;

Pat

Dear all,

Abstract:

[OLD]

[NEW]

Introduction:

[OLD]

[NEW]

Section 11.2

[OLD]

[NEW]

have a nice weekend,
Xavi

ksjp

---

From: "S.V.R.Anand" <[email-masked]>
Date: Sun, 20 Dec 2015 12:07:13 +0530

Hello All,

I would like to present my thoughts purely from the perspective of protocol
conformance and interoperability tests carried out among various IEEE 
802.15.4e
implementations. The APIs offered by such an implementation are essentially
going to dictate what service interface it is going to provide to its higher
layers, 6TiSCH happens to be one.

If CCA is not a mandatory functionality that an IEEE 802.15.4e 
implementation
MUST have for passing interoperability tests, then it is possible that in a
given implementation either it is disabled or not implemented at all. In the
former case, there may not be an API to enable it! 6TiSCH therefore may 
have to
"probe" the configuration attributes using an appropriate IEEE 802.15.4e 
API to
know the availability of CCA service attribute configuration.

In summary, 6TiSCH has to work within the  the protocol conformance 
rules set by IEEE
802.15.4e standard, irrespective of merits and demerits of CCA. Is this 
argument
reasonable ?

Anand

On Saturday 19 December 2015 03:25 PM, Pascal Thubert (pthubert) wrote:
>  > Hello Kris: > > > > I certainly buy your arguments, which fit the 
intuition of the network operation. > > > > There are two additional 
angles that may influence this proposition, though, both relating to 
uses cases that minimal enables and that are a lot less engineered than 
the art TSCH: > > > > -        One is a case where more than one minimal 
6TiSCH network are deployed in one interference domain. The networks may 
not be coordinated and they may not be synchronized. Say they are 
dimensioned for their own traffic but not for necessarily twice that 
traffic. If they both operate around the default of 100 slots per 
slotframe, the chances of contact are very low. Yet theres this roughly 
1/1000 chance that the end up on a same channel at a shifted time, and 
if the slot duration is the same, the collision becomes systematic. In 
that case both networks may experience degradation. CCA may still help 
that case just like it may help coexistence with other types of 
networks.  If we do CCA, only the network which is slightly lagging will 
experience bad performances, which is half of the way. It may make sense 
to provide recommendations for that sort of case, like, if there is a 
minimum of coordinated configuration available, then at least do not use 
slotframes of equal length and if possible make them prime to one 
another to avoid systematic collisions. > > > > -        The other is 
longer sleep and higher drifts. Would it be possible that because the 
minimal devices experience more asynchronous / statistical traffic, 
there may be a wider distribution of interval between frames and thus of 
time drifts? If so, wouldnt it be possible that 2 devices are 
desynchronized enough that one starts emitting while the other is still 
sensing the channel, in which case CCA would protect the first come? > > 
 > > > > Also, CCA simplifies the compliance with regulation in Europe 
and countries that follow the same regulations. > > > > Im hearing 
though that 200328 2.0 will be more open to channel hoppers. Ill try to 
get the exact wording but I understand that you can be a channel hopper 
if you hop between 5 channels as opposed to 15 as before. So CCA may be 
less critical there as it was before. > > > > All in all, I do not see a 
strong case for CCA, but incremental benefits. I also sense some push 
back against it but I have less understanding of where that comes from. 
Is that an battery drain problem? Is that a matter of complexity? > > > 
 > Thanks for all this, > > Pascal > > > > From: Kris Pister 
[mailto:[email-masked]] > Sent: vendredi 18 décembre 2015 19:36 > To: 
Pascal Thubert (pthubert) <[email-masked]> > Cc: 6tisch 
<[email-masked]>; [email-masked] > Subject: Re: 
[6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > > > 
Pascal - > CCA can be a useful feature in a TSCH network.  It is 
certainly useful if the EU standards > prevent you from selling your 
devices without it.  It doesn't provide much benefit for > the purpose 
that you describe below however. > > Most motes in a TSCH network will 
the synchronized to a small fraction of the guard > time (+/- 1 ms 
default for minimal).  That's just simple statistics - if six sigma of 
the > synchronization error distribution is approach the guard time, 
then you're already > in deep trouble with motes falling out of the 
network. > > Published academic networks routinely run with a few tens 
of microseconds of > synchronization error.  Commercial networks can be 
below one microsecond RMS. > In general, synchronization improves with 
increasing network traffic, as the motes > get updates more frequently. 
 > > Compare these numbers to the RX-to-TX turnaround time specified in 
the 15.4 standard, > which is 192 microseconds.  If I'm supposed to 
start transmitting at time T0, I need > to *end* my CCA RX of the 
channel something like 192 microseconds before T0.  But > everyone who 
might collide with my transmission is also planning to transmit at > 
time TO.  As described above, they will probably succeed with an error 
of a few > microseconds, to possibly tens of microseconds.  Result: I 
won't hear them. > > 192 microseconds is the upper bound given in the 
standard, and most radios are > faster.  But even so CCA is just not 
going to help you very often.  It may be useful > to detect WiFi or 
other interferers, but it won't detect other motes in your > network 
contending for the same slot. > > ksjp > > On 12/18/2015 8:55 AM, Pascal 
Thubert (pthubert) wrote: > >     Hello Xavi: > >     Point is, we are 
doing statistical multiplexing in the minimal time slots. If a node 
starts talking, the others should yield. > >     The draft says that CCA 
is optional; this is not a very strong language. Shouldnt we encourage 
it a bit more loudly? > > > >     Cheers, > > > >     Pascal > > > >     
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Xavier Vilajosana >     Sent: vendredi 18 décembre 2015 17:47 >     To: 
[email-masked] >     Cc: Pascal Thubert (pthubert) 
<[email-masked]>; Tero Kivinen <[email-masked]>; Ralph Droms 
(rdroms) <[email-masked]>; Kris Pister <[email-masked]>; 6tisch 
<[email-masked]>; Simon Jonathan <[email-masked]>; 
[email-masked] >     Subject: Re: [6tisch] #40 
(minimal): Ralph's INT AREA review on minimal > > > >     As Jonathan 
said in a previous thread. CCA is optional and does not bring a big 
advantage as nodes are synchronized and communication occurs at the same 
time and hence CCA does not bring a lot. Maybe to get some benefit in 
duty cycle regulation due to LBT and maybe to avoid some external 
interference. But at the end the behaviour in shared slots is slotted 
aloha if this CCA option is not used. > > > >     regards, > >     Xavi 
 > > > > > >     2015-12-18 17:00 GMT+01:00 
[email-masked] <[email-masked]>: 
 > >         Youre correct, they are very similar so no need to change. 
 > > > >         Pat > > > >         On 18, Dec2015, at 8:57, Pascal 
Thubert (pthubert) <[email-masked]> wrote: > > > >         Hello 
Pat: > > > >         Actually, I provisionally wrote the following in 
last call text for the abstract: > > > >         > This document 
describes a minimal mode of operation for a 6TiSCH > >         > 
Network, to provide IPv6 connectivity over a Non-Broadcast > >         > 
Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Time slotted 
Channel Hopping (TSCH) links. > >         > This minimal mode uses a 
collection of protocols including the 6LoWPAN > >         > framework 
and RPL to enable shared access operations over a static > >         > 
TSCH schedule. > > > > > >         Note that Ralph had an issue with the 
beginning of the sentence which now mentions a collection of 
protocols. > > > >         Otherwise, the last call text seems to be 
very similar to your proposal. Would you suggest to change the above 
abstract or is it OK as is? > > > >         Pascal > > > >         From: 
[email-masked] 
[mailto:[email-masked]] >         Sent: vendredi 18 
décembre 2015 15:41 >         To: Pascal Thubert (pthubert) 
<[email-masked]> >         Cc: Simon Jonathan <[email-masked]>; 
Qin Wang <[email-masked]>; Xavier Vilajosana 
<[email-masked]>; Tero Kivinen <[email-masked]>; Ralph 
Droms (rdroms) <[email-masked]>; Kris Pister <[email-masked]>; 
[email-masked]; 6tisch <[email-masked]> 
 >         Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review 
on minimal > > > >         We could change the sentence to : This 
minimal mode leverages 6LoWPAN and RPL to enable communication links 
over a static TSCH schedule via shared time-slots. > > > >         Pat > 
 > > > > >         On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) 
<[email-masked]> wrote: > > > >         We need to reach consensus 
on this; > > > >         With minimal, we are using a time slotted 
medium with shared access. And we want to do cca to avoid collisions, 
dont we? If thats so, then even if the MAC has that optional, minimal 
needs it. > >         Should we call this TDMA? For some people 
(including Wikipedia and yours truly), TDMA is about exclusive access to 
time slots. Which will be the case of the slots that are assigned by the 
6P protocol between parent and child, but is not the case of the minimal 
draft.  I agree that because we do cca, we are not aloha stricto sensu 
either. > > > >         What we are doing extends slotted-aloha to 
make it polite. In a way that makes minimal compliant with ETSI, since 
politeness is what the regulation is all about. > > > >         Will we 
agree if we replace slotted-aloha by polite slotted-aloha or a 
polite form of slotted-aloha? > > > >         Cheers, > > > >         
Pascal > > > >         From: Jonathan Simon [mailto:[email-masked]] 
 >         Sent: mardi 15 décembre 2015 01:28 >         To: 
[email-masked] >         Cc: Qin Wang 
<[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; 
Xavier Vilajosana <[email-masked]>; Tero Kivinen 
<[email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Kris Pister 
<[email-masked]>; [email-masked]; 6tisch 
<[email-masked]> >         Subject: Re: [6tisch] #40 (minimal): Ralph's 
INT AREA review on minimal > > > >         Pat - Carrier sense (via CCA) 
is an option in TSCH, so it can be used where appropriate (e.g. for 
coexistence), but isn't required in general as part of the media access 
scheme, again because it may not be useable in a tightly synchronized 
network. > > > >         Jonathan > > > >         On Mon, Dec 14, 2015 
at 4:18 PM, [email-masked] 
<[email-masked]> wrote: > >             I made an 
error in my earlier email, although shared slots do not require carrier 
sense, it is really recommended.  In most 15.4 modes (but not TSCH) when 
a device wishes to use a shared medium, the devices use CSMA to avoid 
collisions. Also, devices compliant to ETSI 300-328 must use carrier 
sense for LBT (802.15.4s CSMA is cited in that regulation) > > > 
 >             Pat > > > >             On 12, Dec2015, at 16:29, 
Jonathan Simon <[email-masked]> wrote: > > > >             Pat - 
unless something was changed in 802.15.4-2015, that was not how the 
original TSCH shared slots worked.  Devices don't do carrier sense, 
since transmissions are synchronized and talk at the same time (within 
sync tolerances) - they do however back off using a similar backoff 
mechanism, but counted in shared slots as opposed to time, to avoid 
persistent collision.    I think that's what "slotted Aloha" is supposed 
to mean here - a slotted shared medium without carrier sense. > > > 
 >             Jonathan > > > >             On Sat, Dec 12, 2015 at 4:57 
AM, Pat Kinney <[email-masked]> wrote: > 
 >                 Hi  Qin; > >                 A shared slot is open 
for all devices.  To transmit on this timeslot a device shall sense the 
medium for activity, if active it shall wait for the next available time 
slot.   Hence a shared slot is a contention access period for CSMA-CA.  
This isn't slotted aloha, since it senses the medium first. > 
 >                 Pat > > >                 Patrick Kinney > 
 >                 Kinney Consulting > >                 +1.847.960.3715 
 > >                 [email-masked] > > 
<[email-masked]> wrote: > >                     Hi Pat, > > > 
 >                     According to my understanding, in the TSCH mode 
of 802.15.4, if the attribute of a slot is Shared, slotted- aloha access 
should be allowed in the slot. Right? > > > >                     Thanks 
 > >                     Qin > > > > > >                     On Friday, 
December 11, 2015 2:29 PM, "[email-masked]" 
<[email-masked]> wrote: > > > >                     
Xavi; > > > >                     As I understand slotted-aloha, TSCH is 
really Time Division Multiple Access (TDMA), not slotted-aloha.  
Slotted-aloha access to the medium is used in the 802.15.4 CSMA 
algorithms for some modes but not TSCH. > > > >                     Pat 
 > > > >                     On 11, Dec2015, at 11:24, Xavier Vilajosana 
<[email-masked]> wrote: > > > >                     Dear 
all, > > > >                     I wrapped up the proposed changes and 
integrated them to the version in bitbucket. > >                     
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a 
 > > > >                     For simplicity, see here a summary of the 
changes. > > > > > >                     Abstract: > > > 
 >                     [OLD] > > > >                      This document 
describes the minimal set of rules to operate an IEEE > 
 >                        802.15.4 Timeslotted Channel Hopping (TSCH) 
network.  This minimal > >                        mode of operation can 
be used during network bootstrap, as a fall- > >                        
back mode of operation when no dynamic scheduling solution is > 
 >                        available or functioning, or during early 
interoperability testing > >                        and development. > > 
 > >                     [NEW] > > > >                     This document 
describes a minimal mode of operation for a 6TiSCH > 
 >                        Network, to provide IPv6 connectivity over a 
Non-Broadcast Multi- > >                        Access (NBMA) mesh that 
is formed of IEEE 802.15.4 Timeslotted > >                        
Channel Hopping (TSCH) links.  This minimal mode leverages 6LoWPAN > 
 >                        and RPL to enable slotted-aloha operations 
over a static TSCH > >                        schedule. > > > > > 
 >                     Introduction: > > > >                     [OLD] > 
 > > >                     The nodes in a IEEE 802.15.4 TSCH network 
follow a communication > >                        schedule.  The entity 
(centralized or decentralized) responsible for > 
 >                        building and maintaining that schedule has 
precise control over the > >                        trade-off between 
the network's latency, bandwidth, reliability and > 
 >                        power consumption.  During early 
interoperability testing and > >                        development, 
however, simplicity is more important than efficiency. > 
 >                        One goal of this document is to define the 
simplest set of rules for > >                        building a 
TSCH-compliant network, at the necessary price of lesser > 
 >                        efficiency.  Yet, this minimal mode of 
operation MAY also be used > >                        during network 
bootstrap before any schedule is installed into the > 
 >                        network so nodes can self-organize and the 
management and > >                        configuration information be 
distributed.  In addition, the minimal > >                        
configuration MAY be used as a fall-back mode of operation, ensuring > 
 >                        connectivity of nodes in case that dynamic 
scheduling mechanisms fail > >                        or are not 
available.  The IEEE 802.15.4 specification provides a > 
 >                        mechanism whereby the details of slotframe 
length, timeslot timing, > >                        and channel hopping 
pattern are communicated when a node time > >                        
synchronizes to the network [IEEE802154].  This document describes > 
 >                        specific settings for these parameters. > > > 
 >                     [NEW] > > > >                      A 6TiSCH 
Network provides IPv6 connectivity over a Non-Broadcast > 
 >                        Multi-Access (NBMA) mesh that is formed of 
IEEE 802.15.4 Timeslotted > >                        Channel Hopping 
(TSCH) links. > > > >                        The 6TiSCH 
[I-D.ietf-6tisch-architecture] architecture requires the > 
 >                        use of both RPL and the 6LoWPAN adaptation 
layer framework > >                        ([RFC4944], [RFC6282]) as 
defined over IEEE 802.14.5.  6LoWPAN > >                        Neighbor 
Discovery [RFC6775] (ND) is also required to exchange > 
 >                        Compression Contexts, form IPv6 addresses and 
register them for the > >                        purpose of Duplicate 
Address Detection, Address Resolution and > >                        
Neighbor Unreachability detection over one TSCH link.  In order to > 
 >                        reduce the header overhead of the RPL 
artifacts in data packets, the > >                        Routing header 
[RFC6554], the RPL Option [RFC6553] and the related IP > 
 >                        in IP encapsulation MUST be encoded as 
prescribed in > >                        [I-D.ietf-6lo-routing-dispatch] 
 > > > >                        Nodes in a IEEE 802.15.4 TSCH network 
follow a communication > >                        schedule.  A network 
using the simple mode of operation uses a static > 
 >                        schedule. > > > >                        This 
specification defines a Minimal Configuration to build a 6TiSCH > 
 >                        Network, using the Routing Protocol for LLNs 
(RPL) and a static TSCH > >                        Schedule.  The 
802.15.4 TSCH mode, RPL [RFC6550], and its Objective > 
 >                        Function 0 (OF0) [RFC6552], are used 
unmodified, but parameters and > >                        particular 
operations are specified to guarantee interoperability > 
 >                        between nodes in a 6TiSCH Network. > > > 
 >                        More advanced work is expected in the future 
to complement the > >                        Minimal Configuration with 
dynamic operations that can adapt the > >                        
Schedule to the needs of the traffic in run time. > > > > > 
 >                     Section 11.2 > > > >                     [OLD] > 
 > > >                     In addition to the Objective Function (OF), 
nodes in a multihop > >                        network using RPL MUST 
indicate the preferred mode of operation using > 
 >                        the MOP field in DIO.  Nodes not being able to 
operate in the > >                        specified mode of operation 
MUST only join as leaf nodes.  RPL > >                        
information and hop-by-hop extension headers MUST follow [RFC6553] > 
 >                        and [RFC6554] specification.  In the case that 
the packets formed at > >                        the LLN need to cross 
through intermediate routers, these MUST follow > 
 >                        the IP in IP encapsulation requirement 
specified by the [RFC6282] and > >                        [RFC2460].  
RPI and RH3 extension headers and inner IP headers MUST > 
 >                        be compressed according to [RFC6282]. > > > 
 >                     [NEW] > > > >                     In addition to 
the Objective Function (OF), nodes in a multihop > 
 >                        network using RPL MUST indicate the preferred 
mode of operation using > >                        the MOP field in 
DIO.  Nodes not being able to operate in the > >                        
specified mode of operation MUST only join as leaf nodes.  RPL > 
 >                        information and hop-by-hop extension headers 
MUST follow [RFC6553] > >                        and [RFC6554] 
specification.  In the case that the packets formed at > 
 >                        the LLN need to cross through intermediate 
routers, these MUST follow > >                        the IP in IP 
encapsulation requirement specified by the [RFC6282] and > 
 >                        [RFC2460].  RPI and RH3 extension headers and 
inner IP headers MUST > >                        be compressed according 
to [RFC6282] and [I-D.ietf-6lo-routing-dispatch]. > > > > > 
 >                     have a nice weekend, > >                     Xavi 
<[email-masked]>: > >                         Ralph - to my knowledge 
no one has deployed the specific time-parent >                         
selection scheme described in 802.15.4-*.  The basic scheme will likely 
work, >                         but the devil will be in the real-world 
details. > >                         We've had about 8 years of 
successful deployments of industrial tsch mesh >                         
networks using a time-parent selection scheme similar to what is 
proposed >                         in minimal. > 
 >                         6TiSCH present a rich design space at many 
levels.  The goal of minimal was >                         to do 
something simple, based as closely as possible on things that are 
 >                         known to work in deployed networks.  The hope 
and belief is that new and >                         better ideas will 
emerge, but it is certain that many of the proposed "good 
 >                         ideas" will fail.  By defining minimal we 
provide a reliable interoperable >                         platform on 
which papers like "Comparing time-parent selection in 15.4-* 
 >                         and foo" can be written. > 
 >                         ksjp > >                         On 
12/10/2015 5:43 AM, Ralph Droms (rdroms) wrote: > 
 >                             Is there an analysis published somewhere 
that demonstrates how time synchronization in 802.15.4-* is inadequate 
for 6TiSCH? > > > >                         
_______________________________________________ 
 >                         6tisch mailing list >                         
[email-masked] >                         
https://www.ietf.org/mailman/listinfo/6tisch > > > >                     
_______________________________________________ >                     
6tisch mailing list >                     [email-masked] 
 >                     https://www.ietf.org/mailman/listinfo/6tisch > > 
 > > > >                     
_______________________________________________ >                     
6tisch mailing list >                     [email-masked] 
 >                     https://www.ietf.org/mailman/listinfo/6tisch > > 
 >                     6tisch mailing list >                     
[email-masked] >                     
https://www.ietf.org/mailman/listinfo/6tisch > > >                 
_______________________________________________ >                 6tisch 
mailing list >                 [email-masked] >                 
https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > 
 >         -- > >         Jonathan Simon >         Linear Technology, 
Dust Networks product group >         32990 Alvarado-Niles Road, Suite 
910 >         Union City, CA 94587 >         (510) 400-2936 >         
(510) 489-3799 FAX >         [email-masked] > > > >         
******************LINEAR TECHNOLOGY CORPORATION 
CONFIDENTIAL****************** > >         This e-mail transmission, and 
any documents, files or previous e-mail messages attached to it may 
contain confidential information that is legally privileged. If you are 
not the intended recipient, or person responsible for delivering it to 
the intended recipient, you are hereby notified that any disclosure, 
copying, distribution or use of any of the information contained in or 
attached to this transmission is STRICTLY PROHIBITED. If you have 
received this transmission in error, please immediately notify me by 
reply email or by telephone at 510-400-2936 and delete the original 
transmission and its attachments without reading or saving in any 
manner. Thank you. > > > >         
_______________________________________________ >         6tisch mailing 
list >         [email-masked] >         
https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > 
_______________________________________________ > 6tisch mailing list > 
[email-masked] > https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 20 Dec 2015 14:06:14 +0000

Hello Anand:

Looks very reasonable to me. My reading of your words is that if we were to MUST CCA for minimal then we’d bar a number of platforms. There are identified benefits to CCA, though nothing critical for 6TiSCH operations, and I do not think anyone has suggested a MUST yet.

My question was more like whether it is a MAY of a SHOULD. In the current text, it reads like a MAY. So I’m trying to get all the arguments on the table, and feel that we have not seen everything on the con’s side. I’m reading that you suggest that support of CCA is additional complexity (e.g. the probe) and that’s beginning.

Wha else?
Pascal

From: S.V.R.Anand [mailto:[email-masked]]
Sent: dimanche 20 décembre 2015 07:37
To: Pascal Thubert (pthubert) <[email-masked]>; Kris Pister <[email-masked]>
Cc: 6tisch <[email-masked]>; [email-masked]
Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

Hello All,

conformance and interoperability tests carried out among various IEEE 802.15.4e

If CCA is not a mandatory functionality that an IEEE 802.15.4e implementation
MUST have for passing interoperability tests, then it is possible that in a
given implementation either it is disabled or not implemented at all. In the
former case, there may not be an API to enable it! 6TiSCH therefore may have to
"probe" the configuration attributes using an appropriate IEEE 802.15.4e API to
know the availability of CCA service attribute configuration.

In summary, 6TiSCH has to work within the  the protocol conformance rules set by IEEE
802.15.4e standard, irrespective of merits and demerits of CCA. Is this argument
reasonable ?

Anand

On Saturday 19 December 2015 03:25 PM, Pascal Thubert (pthubert) wrote:
> -        One is a case where more than one minimal 6TiSCH network are deployed in one interference domain. The networks may not be coordinated and they may not be synchronized. Say they are dimensioned for their own traffic but not for necessarily twice that traffic. If they both operate around the default of 100 slots per slotframe, the chances of contact are very low. Yet theres this roughly 1/1000 chance that the end up on a same channel at a shifted time, and if the slot duration is the same, the collision becomes systematic. In that case both networks may experience degradation. CCA may still help that case just like it may help coexistence with other types of networks.  If we do CCA, only the network which is slightly lagging will experience bad performances, which is half of the way. It may make sense to provide recommendations for that sort of case, like, if there is a minimum of coordinated configuration available, then at least do not use slotframes o!
f equal le
ngth and if possible make them prime to one another to avoid systematic collisions.
>
>
>
> -        The other is longer sleep and higher drifts. Would it be possible that because the minimal devices experience more asynchronous / statistical traffic, there may be a wider distribution of interval between frames and thus of time drifts? If so, wouldnt it be possible that 2 devices are desynchronized enough that one starts emitting while the other is still sensing the channel, in which case CCA would protect the first come?
>
>
>
>
>
> Im hearing though that 200328 2.0 will be more open to channel hoppers. Ill try to get the exact wording but I understand that you can be a channel hopper if you hop between 5 channels as opposed to 15 as before. So CCA may be less critical there as it was before.
>
>
>
> To: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>
> Cc: 6tisch <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>     The draft says that CCA is optional; this is not a very strong language. Shouldnt we encourage it a bit more loudly?
>
>
>
>     Cheers,
>
>
>
>     Pascal
>
>
>
>     2015-12-18 17:00 GMT+01:00 [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>:
>
>         On 18, Dec2015, at 8:57, Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]> wrote:
>
>
>
>         Hello Pat:
>
>
>
>         Note that Ralph had an issue with the beginning of the sentence which now mentions a collection of protocols.
>
>
>
>         To: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>
>         Cc: Simon Jonathan <[email-masked]><mailto:[email-masked]>; Qin Wang <[email-masked]><mailto:[email-masked]>; Xavier Vilajosana <[email-masked]><mailto:[email-masked]>; Tero Kivinen <[email-masked]><mailto:[email-masked]>; Ralph Droms (rdroms) <[email-masked]><mailto:[email-masked]>; Kris Pister <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 6tisch <[email-masked]><mailto:[email-masked]>
>         On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]> wrote:
>
>
>
>         With minimal, we are using a time slotted medium with shared access. And we want to do cca to avoid collisions, dont we? If thats so, then even if the MAC has that optional, minimal needs it.
>
>         What we are doing extends slotted-aloha to make it polite. In a way that makes minimal compliant with ETSI, since politeness is what the regulation is all about.
>
>
>
>         Will we agree if we replace slotted-aloha by polite slotted-aloha or a polite form of slotted-aloha?
>
>
>
>         Cheers,
>
>
>
>         Pascal
>
>
>
>         Cc: Qin Wang <[email-masked]><mailto:[email-masked]>; Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>; Xavier Vilajosana <[email-masked]><mailto:[email-masked]>; Tero Kivinen <[email-masked]><mailto:[email-masked]>; Ralph Droms (rdroms) <[email-masked]><mailto:[email-masked]>; Kris Pister <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 6tisch <[email-masked]><mailto:[email-masked]>
>         On Mon, Dec 14, 2015 at 4:18 PM, [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> wrote:
>
>             I made an error in my earlier email, although shared slots do not require carrier sense, it is really recommended.  In most 15.4 modes (but not TSCH) when a device wishes to use a shared medium, the devices use CSMA to avoid collisions. Also, devices compliant to ETSI 300-328 must use carrier sense for LBT (802.15.4s CSMA is cited in that regulation)
>
>
>
>             Pat
>
>
>
>             On 12, Dec2015, at 16:29, Jonathan Simon <[email-masked]><mailto:[email-masked]> wrote:
>
>
>
>             On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney <[email-masked]><mailto:[email-masked]> wrote:
>
>                 Hi  Qin;
>
>                 On Dec 11, 2015, at 5:06 PM, Qin Wang <[email-masked]><mailto:[email-masked]> wrote:
>
>                     Hi Pat,
>
>
>
>                     On Friday, December 11, 2015 2:29 PM, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> wrote:
>
>
>
>                     Xavi;
>
>
>
>                     On 11, Dec2015, at 11:24, Xavier Vilajosana <[email-masked]><mailto:[email-masked]> wrote:
>
>
>
>                     Dear all,
>
>
>
>                     2015-12-11 17:49 GMT+01:00 Kris Pister <[email-masked]><mailto:[email-masked]>:
>