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

["Pascal Thubert (pthubert)" <[e-mail]>]

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

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.