Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal

["S.V.R.Anand" <[e-mail]>]

Hi Pascal,

I understand your point.

Just a wishful thought prompted by the desire to keep the layers perform 
their activities.

Anand

On Thursday 10 December 2015 02:55 PM, Pascal Thubert (pthubert) wrote:
>
> Hello Anand:
>
> This would mean running to protocols for building loopless structures. 
> Considering the constraints of the devices, that’s one too many.
>
> Cheers,
>
> Pascal
>
> *From:*S.V.R.Anand [mailto:[e-mail]]
> *Sent:* jeudi 10 décembre 2015 09:58
> *To:* Pascal Thubert (pthubert) <[e-mail]>; Ralph Droms 
> (rdroms) <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal
>
> Hi Pascal and Ralph,
>
> Very engrossing discussion :)
>
> The use of RPL as a means to achieve network time synchronization is
> interesting but essential too for 6TiSCH network opertation. I am sort of
> wondering, if NMBA networks are common and network time 
> synchronization is so
> imporant, shouldn't there be native mechanisms built into IEEE 
> 802.15.4e that
> ensure this happens for TSCH to succeed ? I would ideally liked to 
> have left
> this job to L2 rather than pushing it to a higher layer to manage an
> essentially a L2 property. Does it make sense ?
>
> Anand
>
>
> On Thursday 10 December 2015 02:24 AM, Pascal Thubert (pthubert) wrote:
> > 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) <[e-mail]> 
> <mailto:[e-mail]>a écrit :
>
> >>
>
> >>
>
> >>> On Dec 9, 2015, at 12:12 PM 12/9/15, Pascal Thubert (pthubert) 
> <[e-mail]> <mailto:[e-mail]> 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
>
> >>> [e-mail] <mailto:[e-mail]>
>
> >>> https://www.ietf.org/mailman/listinfo/6tisch
>
> >>
>
> >
>
> > _______________________________________________
>
> > 6tisch mailing list
>
> > [e-mail] <mailto:[e-mail]>
>
> > https://www.ietf.org/mailman/listinfo/6tisch 
> <https://www.ietf.org/mailman/listinfo/6tisch>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.