Your recommendation makes full sense Ralph; the point here is that what we are doing with minimal is one of the many ways we can use TSCH, shared slot vs. not, CCA vs. not. We want to express that. The text in the consensus call echoes your suggestion below, and I'm trying to get consensus around it.
Pascal > -----Original Message----- > From: Ralph Droms (rdroms) > Sent: vendredi 18 décembre 2015 15:59 > To: [email protected] > Cc: Pascal Thubert (pthubert) <[email protected]>; Tero Kivinen > <[email protected]>; Kris Pister <[email protected]>; Xavier Vilajosana > <[email protected]>; 6tisch <[email protected]>; Simon Jonathan > <[email protected]>; [email protected] > Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > I posted a similar suggestion on 2015-12-14: > https://mailarchive.ietf.org/arch/search/?email_list=6tisch > > > > 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? > > I will reiterate my broader point - there is a serious risk of getting the > text in this > document out of sync with the published IEEE 802.15.4 specs. You can > minimized that risk by making maximum use of pointers to the IEEE specs and > minimize the text in this document that restates the IEEE (and IETF and other) > specs. > > - Ralph > > > > On Dec 18, 2015, at 9:40 AM 12/18/15, [email protected] > wrote: > > > > We could change the sentence to : This minimal mode leverages 6LoWPAN > and RPL to enable communication links over a static TSCH schedule via shared > time-slots. > > > > Pat > > > > > > On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) <[email protected]> > wrote: > > > > We need to reach consensus on this; > > > > With minimal, we are using a time slotted medium with shared access. And we > want to do cca to avoid collisions, don’t we? If that’s so, then even if the > MAC > has that optional, minimal needs it. > > Should we call this TDMA? For some people (including Wikipedia and yours > truly), TDMA is about exclusive access to time slots. Which will be the case > of > the slots that are assigned by the 6P protocol between parent and child, but > is > not the case of the minimal draft. I agree that because we do cca, we are not > aloha stricto sensu either. > > > > What we are doing extends slotted-aloha to make it “polite”. In a way that > makes minimal compliant with ETSI, since politeness is what the regulation is > all > about. > > > > Will we agree if we replace “slotted-aloha” by “polite slotted-aloha” or “a > polite form of slotted-aloha”? > > > > Cheers, > > > > Pascal > > > > From: Jonathan Simon [mailto:[email protected]] > > Sent: mardi 15 décembre 2015 01:28 > > To: [email protected] > > Cc: Qin Wang <[email protected]>; Pascal Thubert (pthubert) > > <[email protected]>; Xavier Vilajosana > > <[email protected]>; Tero Kivinen <[email protected]>; Ralph > > Droms (rdroms) <[email protected]>; Kris Pister <[email protected]>; > > [email protected]; 6tisch <[email protected]> > > Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on > > minimal > > > > Pat - Carrier sense (via CCA) is an option in TSCH, so it can be used where > appropriate (e.g. for coexistence), but isn't required in general as part of > the > media access scheme, again because it may not be useable in a tightly > synchronized network. > > > > Jonathan > > > > On Mon, Dec 14, 2015 at 4:18 PM, [email protected] > <[email protected]> wrote: > > I made an error in my earlier email, although shared slots do not > > require carrier sense, it is really recommended. In most 15.4 modes > > (but not TSCH) when a device wishes to use a shared medium, the > > devices use CSMA to avoid collisions. Also, devices compliant to ETSI > > 300-328 must use carrier sense for LBT (802.15.4’s CSMA is cited in > > that regulation) > > > > Pat > > > > On 12, Dec2015, at 16:29, Jonathan Simon <[email protected]> wrote: > > > > Pat - unless something was changed in 802.15.4-2015, that was not how the > original TSCH shared slots worked. Devices don't do carrier sense, since > transmissions are synchronized and talk at the same time (within sync > tolerances) - they do however back off using a similar backoff mechanism, but > counted in shared slots as opposed to time, to avoid persistent collision. > I think > that's what "slotted Aloha" is supposed to mean here - a slotted shared medium > without carrier sense. > > > > Jonathan > > > > On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney > <[email protected]> wrote: > > Hi Qin; > > A shared slot is open for all devices. To transmit on this timeslot a > > device shall > sense the medium for activity, if active it shall wait for the next available > time > slot. Hence a shared slot is a contention access period for CSMA-CA. This > isn't > slotted aloha, since it senses the medium first. > > Pat > > > > Patrick Kinney > > Kinney Consulting > > +1.847.960.3715 > > [email protected] > > > > On Dec 11, 2015, at 5:06 PM, Qin Wang <[email protected]> wrote: > > > > Hi Pat, > > > > According to my understanding, in the TSCH mode of 802.15.4, if the > > attribute > of a slot is Shared, slotted- aloha access should be allowed in the slot. > Right? > > > > Thanks > > Qin > > > > > > > > On Friday, December 11, 2015 2:29 PM, "[email protected]" > <[email protected]> wrote: > > > > > > Xavi; > > > > As I understand slotted-aloha, TSCH is really Time Division Multiple Access > (TDMA), not slotted-aloha. Slotted-aloha access to the medium is used in the > 802.15.4 CSMA algorithms for some modes but not TSCH. > > > > Pat > > > > On 11, Dec2015, at 11:24, Xavier Vilajosana <[email protected]> > wrote: > > > > Dear all, > > > > I wrapped up the proposed changes and integrated them to the version in > bitbucket. > > https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63f > > de078a0aec8307d416e82cdf482c0608a > > > > For simplicity, see here a summary of the changes. > > > > > > Abstract: > > > > [OLD] > > > > 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. > > > > [NEW] > > > > 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. > > > > > > Introduction: > > > > [OLD] > > > > 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. > > > > [NEW] > > > > 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. In order to > > reduce the header overhead of the RPL artifacts in data packets, the > > Routing header [RFC6554], the RPL Option [RFC6553] and the related IP > > in IP encapsulation MUST be encoded as prescribed in > > [I-D.ietf-6lo-routing-dispatch] > > > > 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. > > > > > > Section 11.2 > > > > [OLD] > > > > In addition to the Objective Function (OF), nodes in a multihop > > network using RPL MUST indicate the preferred mode of operation using > > the MOP field in DIO. Nodes not being able to operate in the > > specified mode of operation MUST only join as leaf nodes. RPL > > information and hop-by-hop extension headers MUST follow [RFC6553] > > and [RFC6554] specification. In the case that the packets formed at > > the LLN need to cross through intermediate routers, these MUST follow > > the IP in IP encapsulation requirement specified by the [RFC6282] and > > [RFC2460]. RPI and RH3 extension headers and inner IP headers MUST > > be compressed according to [RFC6282]. > > > > [NEW] > > > > In addition to the Objective Function (OF), nodes in a multihop > > network using RPL MUST indicate the preferred mode of operation using > > the MOP field in DIO. Nodes not being able to operate in the > > specified mode of operation MUST only join as leaf nodes. RPL > > information and hop-by-hop extension headers MUST follow [RFC6553] > > and [RFC6554] specification. In the case that the packets formed at > > the LLN need to cross through intermediate routers, these MUST follow > > the IP in IP encapsulation requirement specified by the [RFC6282] and > > [RFC2460]. RPI and RH3 extension headers and inner IP headers MUST > > be compressed according to [RFC6282] and [I-D.ietf-6lo-routing-dispatch]. > > > > > > have a nice weekend, > > Xavi > > > > 2015-12-11 17:49 GMT+01:00 Kris Pister <[email protected]>: > > Ralph - to my knowledge no one has deployed the specific time-parent > > selection scheme described in 802.15.4-*. The basic scheme will > > likely work, but the devil will be in the real-world details. > > > > We've had about 8 years of successful deployments of industrial tsch > > mesh networks using a time-parent selection scheme similar to what is > > proposed in minimal. > > > > 6TiSCH present a rich design space at many levels. The goal of > > minimal was to do something simple, based as closely as possible on > > things that are known to work in deployed networks. The hope and > > belief is that new and better ideas will emerge, but it is certain > > that many of the proposed "good ideas" will fail. By defining minimal > > we provide a reliable interoperable platform on which papers like > > "Comparing time-parent selection in 15.4-* and foo" can be written. > > > > ksjp > > > > On 12/10/2015 5:43 AM, Ralph Droms (rdroms) wrote: > > Is there an analysis published somewhere that demonstrates how time > synchronization in 802.15.4-* is inadequate for 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 > > > > > > > > > > > > > > > > > > -- > > Jonathan Simon > > Linear Technology, Dust Networks product group > > 32990 Alvarado-Niles Road, Suite 910 > > Union City, CA 94587 > > (510) 400-2936 > > (510) 489-3799 FAX > > [email protected] > > > > ******************LINEAR TECHNOLOGY CORPORATION > > CONFIDENTIAL****************** > > > > This e-mail transmission, and any documents, files or previous e-mail > messages attached to it may contain confidential information that is legally > privileged. If you are not the intended recipient, or person responsible for > delivering it to the intended recipient, you are hereby notified that any > disclosure, copying, distribution or use of any of the information contained > in or > attached to this transmission is STRICTLY PROHIBITED. If you have received > this > transmission in error, please immediately notify me by reply email or by > telephone at 510-400-2936 and delete the original transmission and its > attachments without reading or saving in any manner. Thank you. > > > > > > _______________________________________________ > > 6tisch mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
