(Moving discussion of the Abstract in "RE: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal" to this thread.)
> On Dec 18, 2015, at 9:13 AM 12/18/15, Pascal Thubert (pthubert) > <[email protected]> wrote: > > Dear all; > > In order to address Ralph's issues on the minimal draft, we proposed a > rewording of the abstract and the introduction. > This reopens a 2-weeks period of last call for these particular sections, > with the text as below. > If you disagree with the text, please let us know before January 1st. > > Cheers, > > Pascal > > > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: lundi 14 décembre 2015 19:35 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: [email protected] > Subject: Re: Summary of proposed resolution for issue 40 V3 > > >> 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 I'll reiterate my suggestion to use a higher level description here in the abstract: This minimal mode uses a collection of protocols including the 6LoWPAN framework and RPL to enable interoperable IPv6 connectivity over IEEE 802.15.4 TSCH with minimal network configuration and infrastructure. >> >> ------------- >> ------------- >> ------------- >> >> 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 s/an// >> for a minimal mode of operation to build a 6TiSCH Network, using >> the Routing Protocol for LLNs (RPL) and a static TSCH Schedule. Either delete ", using the Routing Protocol for LLNs (RPL) and a static TSCH Schedule" or mention all the other protocols in use here, as well. Do you want to mention the join process? Security? >> 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>_______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
