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

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

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]> a écrit : >> >> >>> On Dec 9, 2015, at 12:12 PM 
12/9/15, Pascal Thubert (pthubert) <[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] >>> https://www.ietf.org/mailman/listinfo/6tisch >> 
 > > _______________________________________________ > 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.