[6tisch] answers Ralph comments for minimal

[Xavi Vilajosana Guillen <[e-mail]>]

Dear Ralph, all,

here answers of your comments after reviewing the minimal draft and
publishing v18.

1 ) MOST IMPORTANT COMMENT

Most importantly, this document needs to explain its intended use.  From
the Abstract: "This document describes a minimal mode of operation for a
6TiSCH Network."  Exactly what is a "minimal mode of operation"?  Is the
document intended to describe:

a starting point for design and deployment of a "6TiSCH network"?

2) a baseline set of required protocols and modes of operation, which
will be extended by future specifications (as suggested in section 1)?

3) initial behavior that will guarantee out of the box
interoperability among devices from, say, different vendors?

4) something else?

As an example, if I were reading the document for point 1, I can see the
value of pointing out, as in this rev of the document, various operational
choices.  However, if I were reading the document for point 3, I don't see
how interoperability can be guaranteed given the variety of specific
choices a vendor might make in the production of a device.

RESOLUTION:

Introduction and abstract have been updated following Brian and your
comments.  We have tried to clarify what is the inteded use of the document
as well as indicate what a minimal mode of operation is.
E.g.,

Abstract:
 This document describes a minimal mode of operation for a 6TiSCH
   Network.  A minimal mode of operation is a baseline set of protocols,
   recommended configurations and modes of operation sufficient to
   enable a 6TiSCH functional network.  6TiSCH provides IPv6
   connectivity over a Time Synchronized Channel Hopping (TSCH) mesh
   composed of IEEE Std 802.15.4 TSCH links.  This minimal mode uses a
   collection of protocols with the respective configurations, including
   the 6LoWPAN framework, enabling interoperable IPv6 connectivity over
   IEEE Std 802.15.4 TSCH.  This minimal configuration provides the
   necessary bandwidth for network and security bootstrap and defines
   the proper link between the IETF protocols that interface to the IEEE
   Std 802.15.4 TSCH.  This minimal mode of operation should be
   implemented by all 6TiSCH compliant devices.

Introduction

A 6TiSCH Network provides IPv6 connectivity [RFC2460] over a Time
   Synchronized Channel Hopping (TSCH) mesh [RFC7554] composed of IEEE
   Std 802.15.4 TSCH links [IEEE802154-2015].  IPv6 connectivity is
   obtained by the use of the 6LoWPAN framework ([RFC4944], [RFC6282],
   [RFC8025],[I-D.ietf-6lo-routing-dispatch] and [RFC6775]), RPL
   [RFC6550], and its Objective Function 0 (OF0) [RFC6552].

   This specification defines operational parameters and procedures for
   a minimal mode of operation to build a 6TiSCH Network.  Any 6TiSCH
   complaint device SHOULD implement this mode of operation.  This
   operational parameters configuration provides the necessary bandwidth
   for nodes to bootstrap the network.  The bootstrap process includes
   initial network configuration and security bootstrap.  In this
   specification, the 802.15.4 TSCH mode, the 6LoWPAN framework, RPL
   [RFC6550], and its Objective Function 0 (OF0) [RFC6552], are used
   unmodified.  Parameters and particular operations of TSCH are
   specified to guarantee interoperability between nodes in a 6TiSCH
   Network.  RPL is specified to provide the framework for time
   synchronization in an 802.15.4 TSCH network.  The specifics for
   interoperable interaction between RPL and TSCH are described.

   In a 6TiSCH network, nodes follow a communication schedule as per
   802.15.4 TSCH.  In it, nodes learn the schedule of the network when
   joining.  When following this specification, the learned schedule is
   the same for all nodes and does not change over time.  Future
   specifications may define mechanisms for dynamically managing the
   communication schedule.  Dynamic scheduling solutions are out of
   scope of this document.

   IPv6 addressing and compression are achieved by the 6LoWPAN
   framework.  The framework includes [RFC4944], [RFC6282], [RFC8025],
   the 6LoWPAN Routing Header dispatch [I-D.ietf-6lo-routing-dispatch]
   for addressing and header compression, and [RFC6775] for duplicate
   address detection (DAD) and address resolution.

   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 at run time.

2) MAJOR ISSUE 1

If this document is concerned with "IPv6 connectivity", why is there
no mention of address selection, prefix advertisement, use of ND,
etc.?  Similarly, why is there no advice about 6LoWPAN compression
modes?

DISCUSSION

This document’s main goal is to explain how to use the IETF LLN upper stack
on top of IEEE802.15.4 TSCH
We treat the IETF LLN upper stack as a functional set of standards, and
(now) list them:
The framework includes <xref target="RFC4944"/>, <xref target="RFC6282"/>,
<xref target="RFC8025"/>, the 6LoWPAN Routing Header dispatch <xref
target="I-D.ietf-6lo-routing-dispatch"/> for addressing and header
compression, and <xref target="RFC6775"/> for duplicate address detection
(DAD) and address resolution.
What we are explicitly trying to avoid discussion such as “here is how you
use 6LoWPAN and RPL together”. Not that such discussions aren’t interesting
(sidenote: should the IETF/a WG/the IoT directorate produce such docs?),
they are, but the goal of this document is much more modest.
We absolutely understand the point of your comments, but need guidance. For
example, about “there no advice about 6LoWPAN compression modes”, what
could we put? Are you looking for text like “SAC=1 SAM=1”? But mandating
something like thing would go against RFC6282’s MUSTs?

RESOLUTION:
We clarified the use of the 6lowpan framework in the abstract and
introduction, but we have not specified any particular compression mode
(for example). We understand that the compression mode used in 6lowpan does
not affect the underlying TSCH configuration and vice-versa. In opposition,
for example, the Join Metric when RPL is used impacts the mapping of the L2
overlay and the L3 overlay and hence we define this mapping.

3) MAJOR ISSUE 2

What is the relationship between the recommended configuration in this
document and protocol semantics that provide the same configuration
parameters?  For example, there are operational parameters provided in
EBs that are also specified in this document.  How does a node choose
which parameters to use?

 RESOLUTION:
this document defines a set of parameters so the network can be bootstrap.
The aim of the defined parameters is to provide the simplest configuration
so a network can be form. Despite nodes learn some of the configurations,
we need to guide vendors to a configuration that supports the network
bootstrap and adapts the underlying MAC layer to support higher layer
protocols such as RPL or security bootstrap mechanisms.

4) MAJOR ISSUE 3

A document such as this one that specifies the use of protocols specified
elsewhere should use pointers to the other specifications wherever possible
and should avoid repeating a description of those other protocols.  The
danger is getting the specifications out of sync or describing them in a
misleading or incorrect way.  In the case of this document, in my opinion
there is text that repeats the description of aspects of the IEEE 802.15.4
and RPL specifications that should be elided.  For example, section 4.2 and
4.3 describe details of cell transmission that appear to be redundant
relative to the IEEE 802.15.4 specification.

 RESOLUTION:
This point was raised a couple of revisions ago, which has triggered an
editorial overhaul to (1) avoid copy-pasting potentially copyrighted text
from other standards, in particular IEEE802.15.4 and (2) avoid getting
out-of-sync exactly as you describe
In our opinion, this exercise has been done. To answer your specific
comments:
About Section 4.2:
IEEE802.15.4 only states this each cell can be assigned bits/flags
This spec specifies the bits to set (TX, RX, Shared, Timekeeping)
About Section 4.3:
IEEE802.15.4 doesn’t specify a number of retries
We say it should be 3
To be crystal clear (the questions has been raised multiple times), we
indicate that these are retransmissions

5) SPECIFIC ISSUE 1

>From the Introduction: "a node learns the schedule of the network when
joining, the schedule is static and the same for all nodes".  This
statement of operational behavior seems important.  How does a node learn
the schedule?  Is it up to the network administrator to configure all the
nodes so that the schedule is "static and the same for all nodes"?  What
happens if different nodes advertise different schedules (or other
operational parameters) in EBs?  Is that situation considered an
administrative error?

DISCUSSION

We agree this is important
A node doesn’t contain a hardcoded schedule; it learns every thing is needs
by reading the contents of an EB
If only this specification is implemented, nodes advertise the same
schedule. Future specifications which can be used alongside this
specification MAY cause different nodes to generate EBs with a different
contents. This situation is therefore not considered and administrative
error.

 RESOLUTION

OLD
When following this specification, a node learns the schedule of the
network when joining, the schedule is static and the same for all nodes.
NEW

 When following this specification, the learnt schedule is
   the same for all nodes and does not change over time.  Future
   specifications may define mechanisms for dynamically managing the
   communication schedule.  Dynamic scheduling solutions are out of
   scope of this document.

6) SPECIFIC ISSUE 2

In a related issue, I found the text in section 4.1 about future use
of unscheduled cells confusing, after the assertion that "There is
only a single scheduled cell in the slotframe“

   All remaining cells in the slotframe are unscheduled.  Dynamic
   scheduling solutions MAY be defined in the future which schedule
   those cells.  One example is the 6top Protocol (6P)
   [I-D.ietf-6tisch-6top-protocol].  Dynamic scheduling solutions are
   out of scope of this document.  Details about the usage of the non-
   scheduled cells are out of scope of this document.  In particular,
   this specification does not make any restriction on the Link Option
   bitmap associated with those dynamically scheduled cells (i.e. they
   can be "Hard" or "Soft" cells, see [I-D.ietf-6tisch-terminology]).

 RESOLUTION: We have changed the text:

OLD
See above
NEW
All remaining cells in the slotframe are unscheduled.
Dynamic scheduling solutions MAY be defined in the future which schedule
those cells.
One example is the 6top Protocol (6P) <xref
target="I-D.ietf-6tisch-6top-protocol"/>.
Dynamic scheduling solutions are out of scope of this document.


7) SPECIFIC ISSUE 3

Similarly, in section 4.2, if the schedule is static, why is it
necessary to state that "The scheduled cell... cannot be moved or
relocated by any dynamic scheduling mechanism"?

   The scheduled cell is a "Hard cell" [I-D.ietf-6tisch-terminology],
   i.e. it cannot be moved or relocated by any dynamic scheduling
   mechanism.

DISCUSSION

Agreed, this is a “historical leftover” when this text actively discussed
hard and soft cells.

 RESOLUTION

Remove the paragraph

8) SPECIFIC ISSUE 4

Section 4.4 seems to me to be a rewording of the IEEE 802.15.4
specification.  Is there some specific reason that the text is
included here?

DISCUSSION

Agreed, this is a repeat of the IEEE802.15.4 standard.

 RESOLUTION
OLD
Entire 4.4 section
NEW
Keep section 4.4, but containing only the following sentence:
Per <xref target="tab_recommended_tsch_settings"/>, the RECOMMENDED
timeslot template is the default one (macTimeslotTemplateId=0) defined in
<xref target="IEEE802154-2015"/>.


9) SPECIFIC ISSUE 6

In section 5.2, what does the word "supported" mean?  Which mode of
operation should be implemented according to this specification?

DISCUSSION

Agreed, this terminology is not the right one. “implemented” is

 RESOLUTION

OLD
When RPL is used, nodes MUST support the non-storing (<xref
target="RFC6550"/> Section 9.7) mode of operation.
The storing (<xref target="RFC6550"/> Section 9.8) mode of operation SHOULD
be supported by nodes with enough capabilities.
Nodes not supporting RPL MUST join as leaf nodes.
NEW
When RPL is used, nodes MUST implement the non-storing (<xref
target="RFC6550"/> Section 9.7) mode of operation.
The storing (<xref target="RFC6550"/> Section 9.8) mode of operation SHOULD
be implemented by nodes with enough capabilities.
Nodes not implementing RPL MUST join as leaf nodes.


10) SPECIFIC ISSUE 7

I don't understand the relation between sections 6.2, "Initial Time
Source Neighbor Selection", 6.4, "Time Source Neighbor Selection" and
section 6.5, "Hysteresis".  In particular, section 6.4 seems to give
only a requirement that a node must have a selected time source
neighbor, but gives no advice on how the node makes the selection.

DISCUSSION

This is indeed confusing, as “Initial Time Source Neighbor Selection” and
“Time Source Neighbor Selection” related to a very similar topic
The node’s time source neighbor must be part of its RPL parent set, i.e.
RPL gives you a time source neighbor selection process “for free”

 RESOLUTION

Section "Initial Time SOurce Neighbor Selection" has been merged with "Time
Source Neighbor Selection.
Hysteresis is kept in a separate section as deals with time source parent
stability.

11) EDITORIAL ISSUE 1

In the Introduction, why is RPL called out specifically as a "natural
choice" without any justification?  Why not just give the explicit
explanation that RPL is specified to provide the framework for
IEEE802.15.4 time sync?

DISCUSSION

Good point, thanks

 RESOLUTION

OLD
RPL is a natural choice for routing on top of IEEE802.15.4 TSCH, and the
specifics for interoperable interaction between RPL and TSCH are described.
NEW
RPL is specified to provide the framework for time synchronization in
IEEE802.15.4 TSCH network.
The specifics for interoperable interaction between RPL and TSCH are
described.

12) EDITORIAL ISSUE 2

Check for consistency of parameter names and protocol fields; e.g., I
assume macTsRxAckDelay and tsRxAckDelay refer to the same information
element.

 RESOLUTION
Using the following:
macTsCCAOffset
macTsCCA
macTsTxOffset
macTsRxOffset
macTsRxAckDelay
macTsTxAckDelay
macTsRxWait
macTsAckWait
macTsRxTx
macTsMaxAck
macTsMaxTx
macTsTimeslotLength

13) EDITORIAL ISSUE 3

In section 4.1, this instance of "MAY" is not an RFC 2119 usage:
"Dynamic scheduling solutions MAY be defined in the future [...]"

DISCUSSION

Agreed, thanks

 RESOLUTION

OLD
Dynamic scheduling solutions MAY be defined in the future which schedule
those cells.
NEW
Dynamic scheduling solutions may be defined in the future which schedule
those cells.

14) EDITORIAL ISSUE 4

In section 4.5.1, the first and third sentences seem to be redundant.

DISCUSSION

Agreed.
A similar change was also suggested by Brian.

 RESOLUTION

OLD
   The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames
   SHOULD include the Source Address field and the Destination Address
   field.  The Frame Version field SHOULD be set to 0b10 (Frame Version
   2).  The IEEE802.15.4 header SHOULD include Source Address field and
   the Destination Address field.  The Sequence Number field MAY be
   elided.
NEW
    The Frame Version field SHOULD be set to 0b10 (Frame Version 2).
    The Sequence Number field MAY be elided.



-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
([phone]
[e-mail] <[e-mail]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
[image: Universitat Oberta de Catalunya]
­