Hello Ruben: Looks good. Is the text in the consensus call OK with you then?
Pascal > -----Original Message----- > From: Salazar, Ruben [mailto:[email protected]] > Sent: vendredi 18 décembre 2015 16:13 > To: Ralph Droms (rdroms) <[email protected]>; > [email protected] > Cc: Pascal Thubert (pthubert) <[email protected]>; Xavier Vilajosana > <[email protected]>; Kris Pister <[email protected]>; Tero Kivinen > <[email protected]>; 6tisch <[email protected]>; Simon Jonathan > <[email protected]>; [email protected] > Subject: RE: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > I tend to agree that we should either be high level in the description of the > document, like suggested by Ralph, or if we want to go into the detail then we > must use the naming adopted already in the cited-standards, like TSCH with > cca. > TSCH with cca is more than "polite" slotted-aloha: it has a significant > impact on > the overall network throughput, it has much higher throughput than slotted > aloha: it would be misleading to use term "slotted aloha" just because it is > more > familiar. By now, with all the work been done in 6TiSCH, I believe that most > of > the participants are already familiar with TSCH. > Regards > > _________________________________________________________________ > ___________________________________________ > Ruben Salazar, PhD | Landis+Gyr | Global Head of Research and > Technology > Office: +1 678 258 3165 | Email: [email protected] | Address: > 30000 Mill Creek Av., Alpharetta, GA 30022, USA > > -----Original Message----- > From: 6tisch [mailto:[email protected]] On Behalf Of Ralph Droms > (rdroms) > Sent: Friday, December 18, 2015 9:59 AM > To: [email protected] > Cc: Pascal Thubert (pthubert) <[email protected]>; Xavier Vilajosana > <[email protected]>; Kris Pister <[email protected]>; Tero Kivinen > <[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 > > > P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. > > This e-mail (including any attachments) is confidential and may be legally > privileged. If you are not an intended recipient or an authorized > representative > of an intended recipient, you are prohibited from using, copying or > distributing > the information in this e-mail or its attachments. If you have received this > e-mail > in error, please notify the sender immediately by return e-mail and delete all > copies of this message and any attachments. Thank you. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
