> On Dec 11, 2015, at 10:02 AM 12/11/15, Pascal Thubert (pthubert) > <[email protected]> wrote: > > 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.
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 > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
