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]> 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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
