I'll respond on the thread for the consensus call. - Ralph
> On Dec 18, 2015, at 10:52 AM 12/18/15, Pascal Thubert (pthubert) > <[email protected]> wrote: > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
