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