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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
