Dear authors:
All in all, I think the document is ready but believe that a pass on language
from a native person may help.
Also, the document should include a terminology where all the terms are
defined, e.g. NumCandidates and so on.
Still, Please find my comments, with a [PT] tag associated with text snippets,
below:
<snip>
Abstract
This document defines the 6top Protocol (6P), which enables
distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes
to add/delete TSCH cells to one another. 6P is part of the 6TiSCH
Operation Sublayer (6top), the next higher layer to the IEEE Std
802.15.4 TSCH medium access control layer. The 6top Scheduling
Function (SF) decides when to add/delete cells, and triggers 6P
Transactions. Several SFs can be defined, each identified by a
different 6top Scheduling Function Identifier (SFID). This document
lists the requirements for an SF, but leaves the definition of the SF
out of scope. SFs are expected to be defined in future companion
specifications.
[PT] that's too much text on SF which is out of scope. Enough to say that the
6top sublayer comprises the 6P protocol defined here, and a SF that "decides
when to add/delete cells, and triggers 6P Transactions"
This must be repeated in the intro to position 6P vs. 6top vs. SF
<snip>
1. Introduction
All communication in a 6TiSCH network is orchestrated by a schedule
[RFC7554]. This specification defines the 6top Protocol (6P), part
of the 6TiSCH Operation sublayer (6top). 6P allows a node to
[PT] that's concise! Please introduce that the schedule indicates transmission
cells in the [slotOffset,channelOffset] CDU matrix and point at the terminology
draft and RFC 7554 for more information.
You'll be needing this a few lines below.
communicate with a neighbor to add/delete TSCH cells to one another.
This results in distributed schedule management in a 6TiSCH network.
<snip>
In the context of this specification, all the cells used by 6top are
soft cells. Hard cells can be used for example when "hard-coding" a
schedule [RFC8180].
[PT] Also ref the 6TiSCH architecture.
<snip>
The 6P messages exchanged between nodes A and B during a 6P
Transaction SHOULD be exchanged on dedicated cells between A and B.
If no dedicated cells are scheduled between nodes A and B, shared
cells MAY be used.
[PT] Define dedicated, the reader does not necessarily know what is meant here.
Do we need a terminology?
<snip>
A 6P Transaction can consist of 2 or 3 steps. An SF MUST specify
whether to use 2-step transactions, 3-step transactions, or both.
[PT] Hum, the fact that 2 step and 3 steps are meant to enable respectively the
requester or the responder to allocate the cells should be said clearly here,
before 3.1.1.
When the reader is here, he does not figure why there are 2 models.
<snip>
3.1.1. 2-step 6P Transaction
Figure 4 shows an example 2-step 6P Transaction. In a 2-step
transaction, node A selects the candidate cells. Several elements
are left out to simplify understanding.
+----------+ +----------+
| Node A | | Node B |
+----+-----+ +-----+----+
| |
| 6P ADD Request |
| Type = REQUEST |
| Code = ADD |
| SeqNum = 123 |
| NumCells = 2 |
timeout | CellList = [(1,2),(2,2),(3,5)] |
--- |-------------------------------------->|
| | |
| | 6P Response |
| | Type = RESPONSE |
| | Code = SUCCESS |
| | SeqNum = 123 |
| | CellList = [(2,2),(3,5)] |
X |<--------------------------------------|
| |
Figure 4: An example 2-step 6P Transaction.
In this example, the 2-step transaction occurs as follows:
[PT] MAC-layer acks should be shown for completeness, since they are being
used in the logic of the protocol.
<snip>
6P messages travel over a single hop. 6P messages are carried as
payload of an IEEE 802.15.4 Payload Information Element (IE)
[IEEE802154]. The messages are encapsulated with the Payload IE
Header (per Section 7.4.3 of the [IEEE802154]). The Group ID is set
[PT] Be careful when citing down to a section. I think that this implies that
you place a dated reference to the IEEE spec, like 2015. And you do not want
that.
=> I think you have to omit "per Section 7.4.3 of the"
<snip>
Other Fields: The list of other fields depends on the type of
messages, and is detailed in Section 3.3.
[PT] More precisely the other fields are the options below and how they are
used is detailed in 3.3, no?
+-------------+-------------------------------------------------+
| CellOptions | cells scheduled with A that are to be selected |
| Value | by B when receiving a 6P message from A |
+-------------+-------------------------------------------------+
|TX=0,RX=0,S=0| select all cells |
+-------------+-------------------------------------------------+
|TX=1,RX=0,S=0| select the cells scheduled marked as RX |
+-------------+-------------------------------------------------+
|TX=0,RX=1,S=0| select the cells marked as TX |
+-------------+-------------------------------------------------+
[PT] Did you mix up RX and TX above?
<snip>
3.2.4. 6P CellList
A CellList field MAY be present in a 6P ADD Request, a 6P DELETE
Request, a 6P RELOCATE Request, a 6P Response or a 6P Confirmation.
It is composed of zero, one or more 6P Cell containers. The contents
of the CellOptions field specify the options associated with all
cells in the CellList. This necessarily means that the same options
are associated with all cells in the CellList.
[PT] If a CellList is as I expect the concatenation of 6P Cells, then maybe you
should clarify it; also clarify where NumCandidate is found.
<snip>
The 6P Cell is a 4-byte field, its RECOMMENDED format is:
[PT] Is there another format less RECOMMENDED? If not, just say, "its format
is" or something:
<snip>
[Page 12]
Internet-Draft 6tisch-6top-protocol September 2017
Figure 10 defines the format of a 6P ADD Response and Confirmation.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| T | R | Code | SFID | SeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CellList ...
+-+-+-+-+-+-+-+-+-
Figure 10: 6P ADD Response and Confirmation Formats.
CellList: A list of 0, 1 or multiple 6P Cells.
Consider the topology in Figure 1 where the SF on node A decides to
add NumCells cells to node B.
Node A's SF selects NumCandidate cells from its schedule as candidate
[PT] First use of NumCandidate. Is that a definition? Should be in introduced
and defined better. Maybe a terminology?
<snip>
In a 2-step 6P RELOCATE Transaction, the candidate CellList MUST
therefore contain at least NumCells entries.
[PT] No, it must contain exactly NumCells entries; otherwise, how do we know
where the first CellList ends?
<snip>
specified offset. Node B SHOULD include as many cells as fit in the
frame. If the response contains the last cell, Node B MUST set the
Code field in the response to EOL, indicating to Node A that there no
more cells that match the request. Node B MUST return at least one
cell, unless the specified Offset is beyond the end of B's cell list
in its schedule. If node B has less than Offset cells that match the
request, node B returns an empty CellList and a Code field set to
EOL.
[PT] define EOL. Is there a table of Codes?
<snip>
3.4. Protocol Functional Details
3.4.1. Version Checking
All messages contain a Version field. If multiple Versions of the 6P
protocol have been defined (in future specifications for Version
values different from 0), a node MAY implement multiple protocol
versions at the same time. When receiving a 6P message with a
Version number it does not implement, a node MUST reply with a 6P
Response with a Return Code field set to VER_ERR. The Version field
in the 6P Response MUST be the same as the Version field in the
corresponding 6P Request. In a 3-step transaction, the Version field
in the 6P Confirmation MUST match that of the 6P Request and 6P
Response in the same transaction.
[PT] How does the node signal the version it supports? How can it even build a
message that matches the version it does not know? I think it should respond
with a format that it understands and hat hopefully the requester also
understands.
I wonder if there should not be an ERROR message used to report any error. It
would be defined in this version and would be mandatory to implement in all
further versions with this version number.
For instance, If a node with an old version receives a message with an unknown
version, it could return error, wrong version, with the supported version as
data.
<snip>
3.4.2. SFID Checking
Similar, there is now way to enumerate which SFs are supported.
<snip>
Response with return code BUSY. In case the requested cells are
locked, it MUST reply to that request with a 6P Response with return
code NORES. The node receiving BUSY or a NORES MAY implement a retry
mechanism, defined by the SF.
Again, all these codes should have been introduced earlier, at least by a
forward pointer to table 34.
<snip>
3.4.4. Timeout
A timeout occurs when the node sending the 6P Request has not
received the 6P Response within a specified amount of time determined
by the SF. In a 3-step transaction, a timeout also occurs when the
node sending the 6P Response has not received the 6P Confirmation.
The timeout should be longer than the longest possible time it can
take for the exchange to finish. The value of the timeout hence
depends on the number of cells scheduled between the neighbor nodes,
the maximum number of link-layer retransmissions, etc. The SF MUST
determine the value of the timeout. The value of the timeout is out
of scope of this document.
Is there a dependency on the value of a timer on one side vs. the other? Eg in
a 3-step, do we want the requester to time out first and retry, or the
responder to retry his response before the requester times out?
<snip>
3.4.6.2. Detecting and Handling Schedule Inconsistency
Inconsistency may happen when L2 acknowledgment of the last packet in
a transaction is lost, i.e. RESPONSE (in 2-step 6P transaction) or
CONFIRMATION (in 3-step 6P transaction) have been received on one
side while timeout happens on the other side. Take 2-step 6P
transaction as example, i.e. timeout happens when node B is waiting
for L2 acknowledgment to its Response message. Upon the timeout, the
SF running on the node that timeout (e.g node B) MUST take action to
validate the schedule state on both sides.
What makes the node decide what the best course is? Shouldn't you RECOMMEND a
way?
Isn't the last transaction the one that brings an issue? Can we ask the number
of the last transaction on the other side and use to figure if it is the req or
the ack that was missed?
<snip>
inconsistency is detected. When such inconsistency is detected, node
B MUST respond with the return code INCON_ERR and the transaction
MUST be discarded. It is up to the SF to decide what to do next.
For example, upon receiving INCON_ERR, node A starts a LIST
transaction to node B to obtain the scheduled cells with B.
I disagree, it is not up to the SF. The SF asks something, and should be
answered whether it happened or not. Trouble and cleaning trouble should be
done at 6P.
OTOH, SF needs to know when an action happens like a clear or something,
otherwise we have an inconsistency between 6P and SF.
BTW upon a clear that is not on both sides, the right action is probably to
clear again, no? After a number of tries, failure means a software issue.
<snip>
4. Guidelines for 6top Scheduling Functions (SF)
This is more like a dependency, things that SF MUST do. The title above should
be changed, and real guidelines should go to appendix (e.g. 4.3)
<snip>
o MAY redefine the format of the CellList field.
o MAY redefine the format of the CellOptions field.
o MAY redefine the meaning of the CellOptions field.
No, all SF knows about Cells is via APIs, not packet formats.
The format on the wire is 6P business. 6P must parse it and it must understand
it.
If this is changed, then we need a new protocol version.
<snip>
4.3. Recommended Structure of an SF Specification
These are guideline that should go in the appendix sc
<snip>
5. Implementation Status
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC6982], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
The 2 sections above should go.
<snip>
6. Security Considerations
6P messages are carried inside 802.15.4 Payload Information Elements
(IEs). Those Payload IEs are encrypted and authenticated at the link
layer through CCM*. 6P benefits from the same level of security as
Nede ref on CCM*
<snip>
The IANA policy for future additions to this sub-registry is "IETF
Review or IESG Approval" as described in [RFC5226].
Please reference normatively https://tools.ietf.org/html/rfc8126 Instead of
RFC 5226
Several occurences
<snip>
Voila!
Take care,
Pascal
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
