Thanks for the comments! Generally, all comments are taken. I will fix them in the next version!
Tengfei On Mon, Mar 25, 2019 at 7:59 AM Thomas Watteyne <thomas.watte...@inria.fr> wrote: > Authors, > > Please find below my review of draft-ietf-6tisch-msf-02. It's a patch > file to the txt version of the draft. > > You will find inline fixes of typos, and comments, which start at the new > line with "TW>" > > Overall, the draft is in good shape. The recommendations I make are > editorial. The biggest remark is that the draft mixes the terms "dedicated > cells" and "managed cells". I also would like to see some text that > describes the reasoning between "autonomous SHARED cells" and "autonomous > non-SHARED cells". Also, because those terms are obscure, you could replace > them throughout by "autonomous upstream cells" and "autonomous > downstream cells". > > Thomas > > ===== > > diff --git > "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt" > "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt" > index 89514c6...49e59bb 100644 > --- > "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt" > +++ "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt" > @@ -135,10 +135,9 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > > The 6TiSCH Minimal Scheduling Function (MSF), defined in this > specification, is a 6TiSCH Scheduling Function (SF). The role of an > - SF is entirely defined in [RFC8480]: it complements [RFC8480] by > + SF is entirely defined in [RFC8480]. This specification complements > [RFC8480] by > providing the rules of when to add/delete cells in the communication > - schedule. The SF defined in this document follows that definition, > - and satisfies all the requirements for an SF listed in Section 4.2 of > + schedule. This specification satisfies all the requirements for an SF > listed in Section 4.2 of > [RFC8480]. > > MSF builds on top of the following specifications: the Minimal IPv6 > @@ -153,11 +152,11 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > the 7 steps described in Section 4. The end state of the join > process is that the node is synchronized to the network, has mutually > authenticated to the network, has identified a preferred routing > - parent, has scheduled one default managed unicast cell (defined in > + parent, and has scheduled one default managed unicast cell (defined in > Section 5.1) to/from its preferred routing parent. After the join > process, the node can continuously add/delete/relocate cells, as > described in Section 5. It does so for 3 reasons: to match the link- > - layer resources to the traffic, to handle changing parent, to handle > + layer resources to the traffic, to handle changing parent, or to handle > a schedule collision. > > MSF is designed to operate in a wide range of application domains. > @@ -172,18 +171,19 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > > the nodes to the root). Appendix C contains a performance evaluation > of MSF. > +TW> I would remove this sentence, as Appexdix C might be removed > > This specification follows the recommended structure of an SF > - specification in Appendix A of [RFC8480], with the following > + specification, given in Appendix A of [RFC8480], with the following > adaptations: > > - o We have reordered part of the sections, in particular to have the > - section on the node behavior at boot Section 4 appear early in > + o We have reordered some sections, in particular to have the > + section on the node behavior at boot (Section 4) appear early in > this specification. > o We added sections on the interface to the minimal 6TiSCH > - configuration Section 2, the use of the SIGNAL command Section 6, > - the MSF constants Section 14, the MSF statistics Section 15, the > - performance of MSF Appendix C. > + configuration (Section 2), the use of the SIGNAL command (Section > 6), > + the MSF constants (Section 14), the MSF statistics (Section 15), > and the > + performance of MSF (Appendix C). > o This specification does not include an examples section. > > 2. Interface to the Minimal 6TiSCH Configuration > @@ -193,8 +193,9 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > shared cell providing minimal connectivity between the nodes in the > network. The MSF implementation provided in this specification is > based on the implementation of the Minimal 6TiSCH Configuration. An > - implementor with full-awareness of the Minimal 6TiSCH Configuration > + implementor with full awareness of the Minimal 6TiSCH Configuration > implications MAY implement MSF without it. > +TW> I don't understand the statement "with full awareness of the Minimal > 6TiSCH Configuration". Rephrase. > > MSF uses the minimal cell to exchange the following packets: > > @@ -203,6 +204,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > 2. DODAG Information Objects (DIOs), defined by [RFC6550], with > broadcast type. Unicast type DIOs SHOULD NOT be sent on minimal > cell. > +TW> just say "broadcast DIOs" and "unicast DIO". "Broadcast type" doesn't > mean much. > > Because the minimal cell is SHARED, the back-off algorithm defined in > [IEEE802154-2015] is used to resolve collisions. To ensure there is > @@ -214,7 +216,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > 2. send any other broadcast packets on a portion of the minimal > cells not exceeding 1/(3(N+1)), where N is the number of > neighbors of the node. For example, the broadcast DIO and DIS, > - IPv6 Neighbor Discovery (ND)[RFC4861] and any other application > + IPv6 Neighbor Discovery (ND) [RFC4861] and any other application > layer broadcast packets. > > > @@ -229,8 +231,8 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > The RECOMMENDED behavior for sending EBs is to have a node send EBs > with a probability of 1/(3(N+1)). The RECOMMENDED behavior for > sending DIOs is to use a Trickle timer with rate-limiting. There is > - no recommendation behavior for sending any other broadcast. However, > - the traffic portion of all broadcast packets on minimal cell, except > + no recommended behavior for sending any other broadcast frame. > However, > + the traffic portion of all broadcast frames on the minimal cell, except > EBs, MUST not exceed 1/(3(N+1)). > > Section 4.3 describes how to evaluate the number of neighbors during > @@ -240,31 +242,33 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > As detailed in Section 2.2 of [RFC8480], MSF MUST schedule cells from > Slotframe 1, while Slotframe 0 is used for traffic defined in the > Minimal 6TiSCH Configuration. The length of Slotframe 0 and > - Slotframe 1 SHOULD be the same value. The default of > + Slotframe 1 SHOULD be the same value. The default value of > SLOTFRAME_LENGTH is RECOMMENDED for both Slotframe 0 and Slotframe 1, > - although any value can be advertised in the EBs. > + although any value can be used, and advertised in the EBs. > +TW> minimal is not required, yet there is a MUST here. I suggest you > start this paragraph by a statement such as "If MSF is used together with > the ..." > > 3. Autonomous Cells > > MSF nodes MUST initialize Slotframe 1 with a set of default cells for > - unicast communication with their neighbors. These cells are referred > - to as 'autonomous cells', because they are maintained autonomously by > - each node. To distinguish from the autonomous cells, the cell > - scheduled by 6P transaction is defined as 'managed cells'. How to > + unicast communication with their neighbors. > +TW> remove the MUST? > + These cells are > + called "autonomous cells", because they are maintained autonomously by > + each node. Cells > + scheduled by 6P transactions are called "managed cells". How to > schedule managed cells is detailed in Section 5. For autonomous > cells, each node has: > > - o One cell at a [slotOffset,channelOffset] computed as a hash of the > - node's EUI64 (detailed next). The cell options for this cell are > + o One cell at a [slotOffset,channelOffset] computed as a hash of its > own EUI64 (detailed next). The cell options for this cell are > TX=1, RX=1, SHARED=0. > o One cell at a [slotOffset,channelOffset] computed as a hash of the > - EUI64 of the Join Proxy or each neighbor in the IPv6 neighbor > - table (detailed in Section 4.4 and Section 4.5). The cell options > + EUI64 for each neighbor in the IPv6 neighbor > + table, including the Join Proxy (detailed in Section 4.4 and > Section 4.5). The cell options > for this cell are TX=1, RX=1, SHARED=1. > > To compute a [slotOffset,channelOffset] from an EUI64 address, nodes > MUST use the hash function SAX [SAX-DASFAA]. The coordinates are > - computed to distribute the cells across all 16 channel offsets, and > + computed to distribute the cells across all channel offsets, and > all but the first time offsets of Slotframe 1. The first time offset > is skipped to avoid colliding with the minimal cell in Slotframe 0. > The slot coordinates derived from a given EUI64 address are computed > @@ -272,7 +276,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > > o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) > o channelOffset(MAC) = hash(EUI64, 16) > - > +TW> don't you need a modulo operator here? THe hash function can return a > very large number. > > > > @@ -282,11 +286,13 @@ Chang, et al. Expires September 12, 2019 > [Page 5] > Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 > > > - For interoperability purpose, an example how the hash function is > + For interoperability purposes, an example how the hash function is > implemented is detailed in Appendix B. > > - Because of hash collisions, there are cases where the autonomous > - SHARED and non-SHARED cells are scheduled at the same time offset > + Because of hash collisions, there will be cases when the autonomous > + SHARED and non-SHARED cells > +TW> what do you call "autonomous SHARED and non-SHARED cells"? Do you > mean autonomous and managed cells? > + are scheduled at the same time offset > and/or channel offset. Hash collisions among a set of cells at a > given time offset is resolved at run-time as follows: > > @@ -294,29 +300,33 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > precedence. > o If all SHARED cells have empty outgoing queues, the non-SHARED > cell takes precedence. > +TW> please specify what you mena by SHARED and non-SHARED > > Both SHARED and non-SHARED autonomous cells are scheduled to transmit > unicast packets. The autonomous SHARED cells can only be used to > - transmit packets to the neighbor whose EUI64 address is used in hash > - function to create this cell. The autonomous non-SHARED cells can be > + transmit packets to the neighbor whose EUI64 address is used in the > hash > + function to schedule this cell. Autonomous non-SHARED cells can be > used to transmit packet to any neighbors. The traffic on the > autonomous cells are scheduled as: > > - o The Join Request MUST be sent on a SHARED cell, the 6P Request > - packet MAY be sent on a SHARED cell. > - o The Join Response MUST be sent on a non-SHARED cell, the 6P > - Response packet MAY send on a non-SHARED cell. > + o Join Request packets MUST be sent on SHARED cells. > + o Join Response packets MUST be sent on non-SHARED cells. > + o 6P Request frames MAY be sent on SHARED cells. > + o 6P Response frames MAY be sent on non-SHARED cells. > > Throughout the network lifetime, nodes MUST maintain the autonomous > cells as follows: > > o The non-SHARED cell MUST always remain scheduled. > +TW> what do you mean? > o Whenever a new IPv6 neighbor is discovered, add a SHARED cell for > it. > o Whenever an IPv6 neighbor is removed, remove the SHARED cell that > was assigned to it. > o 6P CLEAR MUST NOT erase autonomous cells. > > +TW> The whole terminology of shared and non-shared autonomous cells is > confusing, as it is used following a paragraph that explains that there are > autonomous and managed cells. Please start by explaining, possibly with an > example/diagram, what you mean. > + > 4. Node Behavior at Boot > > This section details the behavior the node SHOULD follow from the > @@ -342,9 +352,10 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > > A node implementing MSF MUST implement the Minimal Security Framework > for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this > - means that a pledge, before being switched on, is pre-configured with > + means that a pledge, before being switched on, may be pre-configured > with > the Pre-Shared Key (PSK) for joining, as well as any other > configuration detailed in [I-D.ietf-6tisch-minimal-security]. > + This is not needed if the node implements a security solution not > based on PSKs, such as [draft-ietf-6tisch-dtsecurity-zerotouch-join]. > > 4.2. Step 1 - Choosing Frequency > > @@ -377,14 +388,15 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > The decision of which neighbor to use as a JP is implementation- > specific, and discussed in [I-D.ietf-6tisch-minimal-security]. > > -4.4. Step 3 - Setting up Autonomous Cells during Join Process > +4.4. Step 3 - Setting up Autonomous Cells during the Join Process > > - After selected the JP, nodes MUST set up their autonomous SHARED > - cells, as described in Section 3. A Join Request is sent then by > - pledge to its JP. The JP forwards the request/response between the > - JRC and the JP, possibly over multiple hops. When JP received the > - Join Response from JRC, it sends a Join Response to the pledge, where > - the pledge learns the keying material used in the network, as well as > + After selected a JP, a node MUST set up autonomous SHARED > + cells to that JP, as described in Section 3. A Join Request is then > sent by the > + pledge to its JP. The JP forwards the Join Request to the JRC, > possibly over multiple hops. > + Similarly, the JRC sends the Join Response to the JP, possibly over > multiple hops. > + When the JP receive the > + Join Response from the JRC, it sends that Join Response to the pledge. > + The pledge thereby learns the keying material used in the network, as > well as > other configurations, and becomes a "joined node". The Join Request > > > @@ -394,31 +406,27 @@ Chang, et al. Expires September 12, 2019 > [Page 7] > Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 > > > - and Response traffics are happened on the autonomous cells, which are > + and Response traffic happens on autonomous cells, which are > scheduled as following: > > - o The Joining Request packet MUST be sent on the autonomous SHARED > - cell to the JP by the pledge. A retransmition with backoff > - mechanism will be sent later if collision happens. > - o The Joining Response packet MUST be sent on the autonomous non- > - SHARED cell to the pledge by the JP. A retransmition will be sent > - immediately at next autonomous non-SHARED cell if collision > - happens. > + o The Join Request MUST be sent on the autonomous SHARED > + cell the pledge has to the JP. Because it is SHARED, a back-off > mechanism kicks in at the plegde when it doesn't receive a link-layer > response. > + o The Join Response MUST be sent on the autonomous non- > + SHARED cell the JP has to be pledge. Because it is non-SHARED, the > JP retransmit immediately it case it doesn't receive a link-layer response > (i.e. there is no back-off). > > - After joined, nodes MUST set up their autonomous non-SHARED cell, as > - described in Section 3. The root node MUST set up its autonomous > - non-SHARED cell when it is configured as root. > + After joining, nodes MUST set up their autonomous non-SHARED cell, as > + described in Section 3. The root node is consider "joined" as soon as > it is configured as root. > > 4.5. Step 4 - Installing Autonomous Cells for each neighbor in neighbor > table > > Because it has learnt the link-layer keying material used in the > - network, the joined node can now decrypt any packets sent by its > - neighbors. Once a new neighbor is added to the neighbor table, a new > - autonomous SHARED cell MUST be added to that neighbor. The > + network, a joined node can decrypt any packets sent by its > + neighbors. Once a new neighbor is added a node's neighbor table, the > node MUST add > + an autonomous SHARED cell to that neighbor. The > autonomous SHARED cell MUST be removed if the corresponding neighbor > - is removed from the neighbor table. How to decide the neighbors to > - keep in neighbor table is implementation-specific. > + is removed from the neighbor table. How to decide which neighbors to > + remove in the neighbor table is implementation-specific. > > 4.6. Step 5 - Acquiring a RPL rank > > @@ -459,6 +467,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > managed unicast cells with that neighbor from its own schedule. In > addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at > the link-layer). The node MAY be removed from the neighbor table. > +TW> some context or condition is missing from this last sentence. > If so, the autonomous SHARED cell will be removed following the > procedure described in Section 3. > > @@ -472,10 +481,11 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > o it has identified its preferred routing parent > o it has one autonomous non-SHARED cell and a set of autonomous > SHARED cells to/from its neighbors > +TW> split in multiple bullet points for SHARED and non-SHARED > o it is periodically sending DIOs, potentially serving as a router > for other nodes' traffic > o it is periodically sending EBs, potentially serving as a JP for > - new joining nodes > + new pledges > > 5. Rules for Adding/Deleting Cells > > @@ -526,13 +536,16 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > removed by 6P, so that there always exists an autonomous cell between > a node and its preferred parent, even if no frames are being > exchanged between them. Autonomous cells are used indistinguishably > - together with dedicated cells, for broadcast or unicast traffic with > +TW> what do you mean by "used indistinguishably"? > + together with dedicated cells, > +TW> previously, you used the term managed cells but now dedicated. I > suggest you use the term managed throughout > + for broadcast or unicast traffic with > the target neighbor. The procedure to remove autonomous cells is > described in Section 3. > > Adding/removing/relocating cells involves exchanging frames that > - contain 6P commands. All 6P frames MUST be sent on the autonomous > - cell or managed cell if the node has. > + contain 6P commands. All 6P frames MUST be sent on autonomous > + or managed cells. > > The node MUST maintain the following counters for its preferred > parent: > @@ -551,9 +564,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > * The node sends a frame to its preferred parent. The counter > increments regardless of whether a link-layer acknowledgment > was received or not. > - * The node receives a frame from its preferred parent. The > - frame MUST be able to decrypt with the key assigned during > - joining process. > + * The node receives a frame from its preferred parent, and > unsecuring of that frame is successful. > > > > @@ -570,36 +581,39 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > > 1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when > the node boots. > - 2. After End State defined in Section 4.9, if there is no managed > - unicast cell to the preferred parent, trigger 6P to add a signle > + 2. After the End State defined in Section 4.9, if there is no managed > + unicast cell to the preferred parent, trigger 6P to add a > cell to it. > 3. When the value of NumCellsElapsed reaches MAX_NUMCELLS: > > * If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a > - single cell to the preferred parent > + cell to the preferred parent > * If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a > - single cell to the preferred parent > + cell to the preferred parent > * Reset both NumCellsElapsed and NumCellsUsed to 0 and go to > step 2. > > - To have the counters working, at least one unicast cell need to be > + To have the counters working, at least one unicast cell needs to be > maintained all the time and never be removed. > +TW> OK, so in all cases a node will have 2 cells to its preferred parent: > one autonomous, one managed. > > - The reason why the counter only counts the managed unicast cell, NOT > - including the autonomous SHARED cell is to avoid the effects of > - collision. If the autonomous SHARED cell is counted as well, > + The reason why the counter only counts managed unicast cell (NOT > + autonomous SHARED cells) is to avoid the effect of > + collisions. If autonomous SHARED cell were counted as well, > NumCellsUsed > LIM_NUMCELLSUSED_HIGH could be caused by the collision > - on the cell. A 6P add request on the autonomous SHARED cell will > + on the cell. A 6P add request on the autonomous SHARED cell would > make the collision even worse. > > Both NumCellsElapsed and NumCellsUsed counters can be used to cell > +TW> something missing > with cell option TX=1 or RX=1. With the rules defined above, the > - cell to add or remove can be transmitting cell or receiving cell > + cell to add or remove can be a transmitting or receiving cell > according to which type of cell the two counters are used for. > +TW> don't understand. > > - Similar to Join Request and Response, the 6P Request is scheduled to > - send on the autonomous SHARED cell to the node's parent. The 6P > - Response is scheduled to send back on the autonomous non-SHARED cell > + Similar to Join Request and Response messages, 6P Request frames are > + sent on the autonomous SHARED cell to the node's parent. The 6P > + Response is sent back on the autonomous non-SHARED cell > to the node. > > 5.2. Switching Parent > @@ -607,7 +621,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > A node implementing MSF SHOULD implement the behavior described in > this section. > > - Part of its normal operation, the RPL routing protocol can have a > + As part of its normal operation, the RPL routing protocol can have a > node switch preferred parents. The procedure for switching from the > old preferred parent to the new preferred parent is: > > @@ -619,7 +633,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > > > 1. if the new parent is not in the neighbor table, the autonomous > - SHARED cell MUST be added as defined in Section 3 > + SHARED cell MUST be added, as defined in Section 3 > 2. the node counts the number of managed unicast cell cells it has > per slotframe to the old preferred parent > 3. the node triggers one or more 6P ADD commands to schedule the > @@ -636,6 +650,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > Since scheduling is entirely distributed, there is a non-zero > probability that two pairs of nearby neighbor nodes schedule a > managed unicast cell at the same [slotOffset,channelOffset] location > +TW> why "managed unicast"? why not simply "managed"? > in the TSCH schedule. In that case, data exchanged by the two pairs > may collide on that cell. We call this case a "schedule collision". > > @@ -817,6 +832,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function > (MSF) March 2019 > quarantine, drop all frames received from that node. > waitretry: Abort the 6P Transaction. Wait for a duration randomly > and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. > +TW> these names are a bit obscure. Use WAITRETRYDURATION_MIN and > WAITRETRYDURATION_MAX? > Retry the same transaction. > > 13. Schedule Inconsistency Handling > @@ -1020,10 +1036,10 @@ Appendix B. Example of Implementation of SAX hash > function > o c, which is the characters of string s, to be hashed > > In MSF, the T is replaced by the length slotframe 1. String s is > - replaced by the mote EUI64 address. The characters of the string c0, > + replaced by the mote's EUI64 address. The characters of the string c0, > c1, ..., c7 are the 8 bytes of EUI64 address. > > - The SAX hash function requires shift operation which is defined as > + The SAX hash function requires a shift operation which is defined as > follow: > > o L_shift(v,b), which refers to left shift variable v by b bits > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
