Dear Pascal, Pat, I updated the current version of minimal in bitbucket. I addressed issue #42 and Pat comments (thanks!).
let me know when to publish v14. regards, Xavi 2016-01-08 19:19 GMT+01:00 [email protected] < [email protected]>: > There are 2 typos in the "Introduction: > 1) change "IEEE 802.14.5” to "IEEE 802.15.4” > 2) change "Nodes in a IEEE 802.15.4 TSCH” to "Nodes in an IEEE 802.15.4 > TSCH” > > I would also suggest a clarification of the following to only refer to one > type of a network: > "IEEE 802.15.4 TSCH nodes adhere to a communication schedule. A 6TiSCH > network using the simple mode of operation uses a static schedule." > > Pat > > > On 8, Jan2016, at 12:01, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Dear all: > > We had a final call on this at the interim, and the text below is now > adopted. > Xavi: can you please retrofit the text below in the minimal draft? > I created ticket 42 for you > https://trac.tools.ietf.org/wg/6tisch/trac/ticket/42 > > Thanks in advance! > > Pascal > > > -----Original Message----- > From: 6tisch [mailto:[email protected]] On Behalf Of Pascal Thubert > (pthubert) > Sent: lundi 4 janvier 2016 18:48 > To: 6tisch <[email protected]> > Cc: Ralph Droms <[email protected]> > Subject: Re: [6tisch] Consensus call on Summary of proposed resolution for > issue 40 V3 > > Dear all: > > With my best wishes for a great year 2016, please find a reminder that we > have a consensus (last) call running on the abstract and introduction of > the minimal draft. > In order to cope with the Year-End break, the call continues till next > Friday. So far, all I've been seeing is consensus with the latest change > that Ralph proposed. > Where we are at now is as below: > > -------------- > Abstract > > BEFORE > > 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 > > 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 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 operational parameters and procedures > for a minimal mode of operation to build a 6TiSCH Network. > 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]. > > > Cheers, > > Pascal > > > > -----Original Message----- > > From: 6tisch [mailto:[email protected]] On Behalf Of Ralph Droms > > Sent: vendredi 18 décembre 2015 17:24 > > To: 6tisch <[email protected]> > > Subject: Re: [6tisch] Consensus call on Summary of proposed resolution > > for issue > > 40 V3 > > > > (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 > _______________________________________________ > 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 >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
