Yes Ralph, we have converged. I like and agree with your suggestions below.
Take care, Pascal > Le 9 déc. 2015 à 21:27, Ralph Droms (rdroms) <[email protected]> a écrit : > > >> On Dec 9, 2015, at 12:12 PM 12/9/15, Pascal Thubert (pthubert) >> <[email protected]> wrote: >> >> Hello Ralph: >> >> >>>>> Does a network that follows these rules provide an L2 IEEE 802.15.4 >>>>> service, an >>>>> IPv6 6TiSCH service, ??? >>> >>> This is the key question I was trying to get an answer for. I think what I >>> read >>> below is that the intention for this document is to define "a set of rules >>> for >>> simplest operation of an 6TiSCH network". >> >> Yes. That is what I'm expecting as shepherd of the doc to match the charter >> item. >> >> >> <snip> >> >>>> 6TiSCH was put together to address the NBMA nature of the multihop network >>> as opposed to considering only one hop, like BTLE does, which would probably >>> be have been 6lo work. >>> >>> My key question is whether this document aimed at a description of how to >>> use >>> IEEE 802.15.4 TSCH or 6TiSCH. As the goal is a description of 6TiSCH, a >>> description of how to use RPL is, of course, appropriate. >> >> It is a 6TiSCH spec about minimal 6TiSCH Network, not a description of TSCH, >> which is already a completed charter item >> (https://tools.ietf.org/html/rfc7554). > > OK. > >>>> 6TiSCH requires RPL for data and time synchronization over multiple hops. >>> That capability is part of our bare minimum. If someone only cares for hub >>> and >>> spoke, then RPL is not needed, but supporting only that model is below the >>> bar >>> of the 6TiSCH bare minimum. >>> >>> I still think tying the join process to the use of RPL is a bad idea, but >>> that's a >>> minor design point for the WG. >> >> If it was only that, I'd agree. >> >> But we also need RPL to build a loop-less structure for the clock >> synchronization, so we do not need an additional routing method for that >> purpose only. >> As you know, clock synchronization is key to the TSCH operation and if a >> node loses its sense of time, it lose connectivity and will need to rejoin. >> >> So RPL ends up as a core mechanism in 6TiSCH and if that makes things >> simpler or better, then we are happy to leverage it elsewhere. > > OK. > >>>>> I looked at draft-ietf-6tisch-minimal-13, and I see that there are no >>>>> changes to the abstract or the introduction. As I read that text, >>>>> this document is intended to give minimal operational parameters for >>>>> IEEE802.15.4 TSCH. However, the title of the document is "Minimal >>>>> 6TiSCH Configuration" and the content goes far beyond the parameters >>>>> needed to run IEEE802.15.4 TSCH. As an aside, I don't see any >>>>> mention of TiSCH or 6TiSCH in the document, other than in the title. >>>> >>>> I agree, Ralph; >>>> >>>> Proposals: >>>> >>>> >>>> >>>> -------------- >>>> 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. >>>> >>>> ---------- >>>> Abstract (after) >>>> >>>> This document describes the minimal set of rules to operate a 6TiSCH >>>> Network, which provides 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 set only >>>> provides static scheduling, but it can be complemented in operating >>>> networks by distributed, or centrally controlled, dynamic scheduling >>>> extensions. >>>> >>>> ---------- >>> >>> I apologize if I appear to be wordsmithing (or even bikeshedding). >>> >>> I don't think the first sentence is right. I think what this document >>> describes is a >>> simple mode of operation to provide IPv6-over-6Tisch service. The >>> motivation >>> for this mode of operation is testing, initial deployment and/or "required >>> to >>> implement" to provide a baseline of interoperability. I think the focus >>> should be >>> on the purpose of the document as a whole and the details of the scheduling >>> mechanism can be left for the Introduction. >> >> Hum: >> >> "IPv6-over-6Tisch" is redundant since the 6 in 6TiSCH is already that IPv6. > > Yes, that was a typo... > >> >> Our terminology says : 6TiSCH: IPv6 over the Timeslotted Channel >> Hopping (TSCH) mode of IEEE 802.15.4e. >> >> Also we have learnt that the initial motivation and how the protocol ends up >> being used are totally different beast so I'd rather stick to what minimal >> is as opposed to what we thought we'd be using it for. It is mostly minimal >> because it uses a static schedule and slotted-aloha over it. It is also >> minimal because it is based on the IETF standards that are designed to >> enable IPv6 on the most constrained environments that we support (6LoWPAN, >> RPL, CoAP, ...). > > OK. I see now that the motivations from the original Introduction were left > out of the new Introduction you proposed. > >> >> Finally you say that the first sentence is not right but it appears that you >> comment on the second. > > I think the document describes a simple mode of operation for a collection of > protocols to provide 6TiSCH server. It's probably good to describe that > simple mode of operation with as few rules as possible, but the important > objective, in my opinion, is simple mode of operation. > >> Putting all the above together, and if that's really your point, then yes, >> I'd agree with you to remove the second sentence. What about: >> >> " >> ---------- >> Abstract (2nd try) >> >> 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. > > I apologize again for appearing to wordsmith - but why mention only 6LoWPAN > and RPL? Why not all the relevant protocols or "This minimal mode of > operation uses a collection of protocols [...]" >> " >> >>> >>>> >>>> ------------ >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> ------------------------------ >>>> >>>> 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. >>> >>> Good - a crisp definition of "6TiSCH" is critical. >> >> <snip> >> >>> >>> What about all the other protocols required to run an IPv6 network? >>> >>> I would assume that the reader knows about IEEE 802.15.4 TSCH, RPL, etc., >>> and >>> their principles of operation. In the interest of conciseness, I recommend >>> eliding >>> motivations and descriptions of protocols that are available elsewhere. If >>> I were >>> reading this document, I would want to know what protocols I need to >>> implement, what is the default operation of those protocols, what >>> operational >>> parameters a device will receive through the network, what defaults a device >>> should use for other operational parameters. >> >> Yes, we agree on the goal; " motivations and descriptions of protocols that >> are available elsewhere" is exactly what I've been trying to do. >> But I fail to see which text in the intro still fits that description. Would >> you have a suggestion there? Note that we need to insist on the static >> schedule because that's where the minimalistic thing comes from. > > Ah, I jumped ahead to talk about the document as a whole at this point. > Sorry for the confusion. > >> Below I'm adding a paragraph to address the need to mention 6LoWPAN as >> mandatory parts of the minimal solution, in an attempt to cover your points >> above and further down this mail. >> >> ------------------------------ >> >> 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. >> >> <added in v2> >> >> 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. >> >> </added in v2> >> >> Nodes in a IEEE 802.15.4 TSCH network follow a communication >> schedule. An 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. The degree of optimization that is obtained >> depends on the capabilities of the controlling entity and the acceptable >> complexity for a given deployment. In a minimal configuration, >> this controlling entity is omitted, and the schedule is static. >> >> The IEEE 802.15.4 specification provides a mechanism whereby the >> schedule, expressed as details of slotframe length, timeslot timing, >> and channel hopping pattern, is obtained by a node at the time it joins >> the network [IEEE802154]. > > We're probably arguing style at this point; I would write (replacing both > paragraphs): > > 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. > > Perhaps, considering that a static schedule is mentioned in the next > paragraph, I would simply omit the previous two paragraphs. > >> 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. >> >>>> 3. Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH >>>> network using the Routing Protocol for LLNs (RPL) and a static TSCH >>>> schedule. It >>>> is expected that RPL and the Objective Function 0 (OF0) will be reused >>>> as-is. >>> >>> On reflection, I think this charter item is incomplete. It focuses on only >>> two >>> aspects of how to build a simple 6TiSCH network: scheduling and routing. A >>> complete IPv6-over-TSCH definition needs to specify the use of 6LoWPAN, ND, >>> address management, prefix management, etc. >> >> Yes, we need to add text on reusing 6LoWPAN HC as is. Then there's the >> question of 6LoRH (in adoption call at 6lo); should we mention it? > > I would consider 6LoRH to be part of 6LoWPAN header compression, so there's > no need to mention it in the Introduction. > >> The deployment and interaction with backbone router for those deployments >> that need it is described in the architecture. >> Left to be debated is whether we point only on RFC 6775 for the other items >> or add draft-thubert-6lo-backbone-router (also in adoption call at 6lo) in >> the picture. > > OK. > >>> Ideally, this document would be paired with a complete IPv6-over-6TSCH >>> specification, so that this document specifies only those particular >>> operational >>> parameters required for the simple subset of the IPv6-over-6TSCH >>> specification. >>> I understand that there is a circular dependency in that it's likely this >>> simple >>> 6TiSCH definition will be needed for development and testing before a >>> complete >>> 6TiSCH definition is published. In that case, this document will need to >>> be a >>> standalone document and include descriptions of how to use all of the >>> protocols >>> required for 6TiSCH service. >> >> My thought too. The high level informational view is supposed to be the >> architecture, which may be ill-named since as you pointed out in your >> review, it goes deeper than that. > > I don't know whether the WG wants to produce separate architecture and 6TiSCH > (IPvr-over-IEEE802.15.4TSCH) documents. The specification I think the > minimal mode document should depend on is the 6TiSCH specification. > >> We do not want to overload the minimal draft with things that are in the >> architecture already. It is in line with your earlier comment on " eliding >> motivations and descriptions of protocols that are available elsewhere" to >> which I do agree. > > OK. > >> I added a paragraph to indicate the inheritance from the architecture and >> the need of all the 6LoWPAN suite. >> >> Does that work? > > Yes ... I think we're converging. > > It would be good to hear from other WG members in this discussion. > > - Ralph > >> >> Pascal >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
