Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement
Note: This ballot was opened for revision 05 and is now closed.
(Ted Lemon) Yes
(Jari Arkko) No Objection
(Alia Atlas) No Objection
(Richard Barnes) No Objection
Comment (2015-03-04 for -05)
The reference to 2119 appears to be unnecessary.
(Spencer Dawkins) No Objection
(Adrian Farrel) No Objection
Comment (2015-02-28 for -05)
I don't object to the publication of this document, but I have a swathe of Comments that I think you should address before the draft is published as an RFC. Some of these comments arise from Deborah Brungard's review as "AD in training". In general, I found this document a very heavy way of saying "we need an adaptation function, and we need a control plane that can determine and enforce end-to-end paths subject to timeslot assignment." I don't suppose there is anything to be done about that now, but you used a lot of words! --- There are a number of abbreviations that the RFC Editor will ask you to expand on first use both in the Abstract and in the main body of text. If you have te document open for other edits, you should take a pass at this to make sure the right expansions are used. --- Section 1, para 3 Not sure whether "ultra-lower power" is a typo or an undefined term. --- Section 1 Bringing industrial-like performance into the LLN stack... I'm not sure what "industrial-like performance" is supposed to mean. Two paragraphs earlier you described the industrial environment, but not anything that matches the term "industrial-like performance". Could you usefully reword as "Enabling the LLN protocol stack to operate in industrial environments..." --- Section 1 What is missing is a Logical Link Control (LLC) layer between the IP abstraction of a link and the TSCH MAC, which is in charge of scheduling a timeslot for a given packet coming down the stack from the upper layer. I found this odd. Do you mean to say... What is missing is a link layer control protocol that is in charge of scheduling a timeslot for a given IP packet that will be encapsulated in the TSCH MAC. But in Section 4 I see you have come back to the term "LLC". I'm not comfortable with this use of the term. It doesn't fit (as far as I can see) with the conventional (i.e., OSI) usage of the term. You might look to GMPLS for the way that this terminology issue was handled for adaptation into layer 2 or 1 technologies, and the way that those technologies are controlled by signaling or management protocols. --- It would seem that Section 2 is redundant and can be removed. --- Section 3 Low-power WPANs are characterized by small packet sizes Is this the characterisation that you want to call to our attention or is it the small maximum frame size? --- The last paragraph of Section 3 seems to be out of place. It is certainly worth noting any implementation information, but, as recommended by RFC 6982 this information is better placed either in an implementation report (a separate document) or in a wiki. There are good political reasons for doing this, and also good practical reasons as the RFC will be an ossified record - you don't want endless updates to the RFC just because someone else has written some more code! --- Section 4 As highlighted in Appendix A, TSCH differs from traditional low-power MAC protocols because of its scheduled nature. Is there a long tradition? Did your father's father code low-power MAC protocols, perhaps whittling them by hand from a single piece of hornbeam? :-) Maybe s/traditional/other/ --- Section 4.1 1. Define the Information Elements included in the Enhanced Beacons advertising the presence of the network. Am I supposed to know what an "Enhanced Beacon" is? Should there be an explanation of a reference? --- Section 4.1 4. Define a mechanism to secure the joining process and the subsequent optional process of scheduling more communication cells. This is the first mention of a cell. It would hav helped to either explain it or give a reference. Ah! There is the definition in 4.5. Is something out of order, or would a forward pointer be enough? Turns out a "cell" was not what I thought it was. --- Section 4.5 mentions PCE. That is OK, but you will need to expand the abbreviation, and you should give a reference. Similarly, while 4.8 does expand "PCE" a reference would help. --- Section 4.6 has The LLC needs to: 1. Define a queuing policy for incoming and outgoing packets. It is not clear (to me) whether this needs to be a network-wide policy, a per-node policy that can be standardised and/or communicated, or is a per-node policy that can be configured or hard-wired at implementation. Maybe "the LLC has to allow for the implementation and configuration of a policy..." --- Section 4.7 1. Ensure timely delivery of such data. "Timely" might be subjective. What do you really mean? --- Section 4.8 An example of decentralized algorithm is provided in [tinka10decentralized]. This mechanism can be used to establish multi-hop paths in a fashion similar to RSVP. I'm afraid I didn't hunt down the referenced paper. I wonder whether you mean RSVP or RSVP-TE. Probably you *do* mean RSVP in that the decentralised approach allows the reservations to form along the routes the packets happen to follow. Perhaps including a reference (probably RFC 2205 if you do man RSVP) and some explanation of what you mean by "decentralised" would help. I can see "decentralised" as meaning classic RSVP or just a signaling plane like RSVP-TE allowing the hops to select cells. --- Section 4.8 1. Provide a mechanism for two 6TiSCH devices to negotiate the allocation and deallocation of cells between them. This is the first mention of 6TiSCH in a 6TiSCH document! Don't you think it would be good to define the term? --- Section 4.9 3. Define a mechanism to allow for the secure transfer of signaling data between nodes and the LLC. This reads as though the LLC is now being treated as the centralised control entity not a "layer" as previously defined. Certainly, the transfer of data between a node and a "layer" is probably achieved within the node so security is not an issue. Fix this with s/and/within/ ? --- I'm not convinced by your choice to put all but one reference as non- normative. [I-D.ietf-6tisch-terminology] seems to be required reading to understand the terms used in this document. [IEEE802154e] might reasonably be assumed to be fundamental to understanding what TSCH is. Equally, some of the references seemed a little gratuitous. For example: To map the services required by the IP layer to the services provided by the link layer, an adaptation layer is used [palattella12standardized]. I'm sure there are other issues with references, but I lacked the energy to go through them. Could you please work this issue with your AD. --- It would have been good to have included proper forward references to the two Appendixes from early in the document. --- Why is Appendix B titled "TSCH Gotchas" when many of the features described are positive attributes of TSCH?
(Stephen Farrell) No Objection
Comment (2015-03-05 for -05)
I didn't see explicit mention of privacy (as opposed to confidentiality), but that's not a huge deal given (I think) TSCH supports encryption. However, if privacy is a goal (and I hope it is) wouldn't mentioning that be good, and maybe it'd spur someone to later thing about e.g. traffic analysis and whether or not some mechanisms to counter that might be needed in these contexts.