Subject: [6tisch] FW: Summary of proposed resolution for issue 40 V2

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Dec 2015 07:01:08 +0000

Sorry for overlooking one of Ralph's comments when writing this summary. Try again:

Abstract update:

BEFORE

--------------
Abstract 

   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.

---------------
AFTER

---------------
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 Timeslotted Channel Hopping (TSCH) links.
This minimal mode uses a collection of protocols including the 6LoWPAN suite
and RPL to enable slotted-aloha operations over a static TSCH schedule.

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

Intro update:

BEFORE

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

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.

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

AFTER

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

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.  

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

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

Pascal 

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

---

From: Ralph Droms <[email-masked]>
Date: Mon, 14 Dec 2015 07:55:06 -0500

> On Dec 14, 2015, at 2:01 AM 12/14/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 

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?

If I might get on my soapbox briefly, the use of "slotted-aloha" in the Abstract is an example of my concern about the document, generally, that descriptions of IEEE 802.15.4-* in this document may be at odds with the text in the IEEE specs.

I know there are WG members who have experience with the relevant IEEE specs.  Even so, given the apparent close interaction between this document and the IEEE specs, it might be a good idea to get an external IEEE expert reviewer.  As an example, when I first read the document, I was unaware that IEEE 802.15.4-* includes a time synchronization mechanism.  I infer that IEEE 802.15.4-* also includes a network join mechanism.  It would be good to get a review of how the mechanisms in this document interact with those and other similar mechanisms in IEEE 802.15.4-*.

Other comments about the Introduction in line.

- Ralph

"Minimal Configuration" or "operational parameters and procedures for a minimal mode of operation"?

>   between nodes in a 6TiSCH Network.

What about 6LoWPAN HC, 6LoWPAN-ND, etc.?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Dec 2015 16:08:12 +0000

Hello Ralph:

Cheers,
> > 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 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?
> 

Suggestion is to use a "shared access" as opposed to " slotted-aloha operations"

> minimal mode of operation"?

I like this

> What about 6LoWPAN HC, 6LoWPAN-ND, etc.?

There is no proposed change from non-TSCH 802.15.4 (6LoWPAN) operation.
We can say it there if that clarifies. I'll send  a v3.