Hello Ralph: Cheers, > > > > > > 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. > > 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" > > ------------- > > ------------- > > > > 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 > > "Minimal Configuration" or "operational parameters and procedures for a > minimal mode of operation"? I like this > > > 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. > > 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. > > > 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 > > > > _______________________________________________ > > 6tisch mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
