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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Dec 2015 15:02:09 +0000

Dear all:

You've seen a long thread discussing Ralph's issues and suggestions on Minimal.
Ralph and I came up with the following proposal, which impacts the abstract and the intro, and are now asking feedback:

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 leverages 6LoWPAN 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

---

From: Ralph Droms <[email-masked]>
Date: Fri, 11 Dec 2015 10:21:23 -0500

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

At the risk of appearing to wordsmith yet again, this comment of mine from an earlier post seems to have been overlooked:

[...] why mention only 6LoWPAN and RPL?  Why not all the relevant protocols or "This minimal mode of operation uses a collection of protocols [...]"

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Dec 2015 16:52:22 +0000

That's a oups. 

And at the call, we mentioned including 6LoRH more explicitly as well. We'll debate that on another thread.
Before I reformulate the whole thing do we agree on the following 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."

I agree that as written it seemed limitative but not mentioning 6LoWPAN and RPL seems  awkward...

Cheers,

Pascal

> -----Original Message-----
> From: Ralph Droms [mailto:[email-masked]]
> Sent: vendredi 11 décembre 2015 16:21
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [6tisch] Summary of proposed resolution for issue 40:
> 
> 
> > Ralph and I came up with the following proposal, which impacts the abstract
> and the intro, and are now asking feedback:
> >
> >
> > Abstract update:
> >
> > BEFORE
> >
> >
> > --------------
> > 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.
> At the risk of appearing to wordsmith yet again, this comment of mine from an
> earlier post seems to have been overlooked:
> 
> [...] why mention only 6LoWPAN and RPL?  Why not all the relevant protocols or
> "This minimal mode of operation uses a collection of protocols [...]"
> 
> >
> >
> > -------------
> > -------------
> > -------------
> >
> > Intro update:
> >
> >
> >
> > BEFORE
> >
> >
> > --------------
> >
> > 1.  Requirements Language
> >

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Dec 2015 14:09:32 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > You've seen a long thread discussing Ralph's issues and suggestions on
    > Minimal.  Ralph and I came up with the following proposal, which
    > impacts the abstract and the intro, and are now asking feedback:

I like all the changes.
You don't tell me if will be Informational, BCP, or Standards track.

(I am still in favour of PS/IS, but my previous objection to BCP is withdrawn)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-