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

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

Hello Ralph:

If you're OK with this round, we'll open a one week call to the WG to check consensus.

The proposed replacement for slotted aloha is subject to change again in that phase :)

Please let us know;

Pascal

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

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

framework and RPL to enable shared access 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 an operational parameters and procedures

   for a minimal mode of operation to build a 6TiSCH  Network, using

   the Routing Protocol for LLNs (RPL) and a static TSCH Schedule.

  The 802.15.4 TSCH mode, the 6LoWPAN framework, RPL [RFC6550],

   and its Objective Function 0 (OF0) [RFC6552], are used unmodified,

   but  parameters and particular operations of TSCH and RPL 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 (rdroms)" <[email-masked]>
Date: Mon, 14 Dec 2015 18:35:28 +0000

> On Dec 14, 2015, at 11:16 AM 12/14/15, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ralph:
> 
> If you’re OK with this round, we’ll open a one week call to the WG to check consensus.
> The proposed replacement for slotted aloha is subject to change again in that phase J
> 
> Please let us know;

Assessing WG consensus is OK with me.

- Ralph