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:[email protected]]
*Sent:* jeudi 10 décembre 2015 09:58
*To:* Pascal Thubert (pthubert) <[email protected]>; Ralph Droms
(rdroms) <[email protected]>
*Cc:* [email protected]; [email protected]
*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) <[email protected]>
<mailto:[email protected]>a écrit :
>>
>>
>>> On Dec 9, 2015, at 12:12 PM 12/9/15, Pascal Thubert (pthubert)
<[email protected]> <mailto:[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] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
> _______________________________________________
> 6tisch mailing list
> [email protected] <mailto:[email protected]>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
