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

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

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).


> >
> > 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.

> 
> >> 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.

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, ...).

Finally you say that the first sentence is not right but it appears that you comment on the second. 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.
"

> 
> >
> > ------------
> >
> >
> >
> > 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.
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].

   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?
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.




> 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.
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.

I added a paragraph to indicate the inheritance from the architecture and the need of all the 6LoWPAN suite.

Does that work?

Pascal