Subject: Re: [6tisch] Questions about 6tisch tsch draft

From: Thomas Watteyne <[email-masked]>
Date: Thu, 2 Oct 2014 12:33:27 -0700

Ines,

Thanks a million for reviewing this document. Please find my answers
*inline*.

On Wed, Sep 24, 2014 at 3:06 PM, Ines Robles <[email-masked]
> wrote:

> Hi,
>
>
> I have some questions:
>
> 1- related with draft-ietf-6tisch-tsch-01:
>
>         1.a-  in A.1 Timeslots, states: "The duration of a timeslot is not
> defined by the standard". The 802.15.4e standard defines in page 176 the
> field:
>
> macTsTimeslotLength
>
> Range:  0x0000– 0xffff
>
> The total length of the timeslot including any  unused time after frame
> transmission and Acknowledgment, in μs
>
> default:  10000 = (10 ms)
>
> and it is mentioned as well in the minimal draft.(page 7)
>
>
*I'm not entirely sure I understand your question. I assume you mean that
the sentence "The duration of a timeslot is not defined by the standard"
isn't clear? Would the following rewording work for you?*

*"The duration of a timeslot is not mandated by the standard"*

*As soon as you confirm this is indeed what you meant, I will create a
ticket.*

>
>           1.b- In the same section  states: "...with a 10 ms slot (a
> typical duration)", would be good maybe if it is added for example the
> amount of khz for these 10 ms, like "10 ms is a typical duration for a
> quartz crystal of  32.768 kHz"?
>
>
*The crystal is just the internal mechanism for the device to measure time.
You can measure 10ms (or other durations) with crystals of different
frequencies, or entirely other clock sources, so I don't see 10ms as being
"typical duration" for 32kHz crystals. If this is confusing, I believe we
should take out the text about crystals, it's just there for illustration.*

*What do others think?*

>              1.c -  In A.11 states: "..EB frames are sent on all
> frequencies.  A mote wishing to join the network listens for EBs....",
> maybe would be good to add in some way that:
>
>             1.c.1 -  EB are sent on all frequencies if CONFIGURE.eb
> (channelOffset) = 0 (pag 25 6top-sublayer draft), right?
>

*Channel hopping turns the [channel offset,timeslot offset, ASN] tuple into
a frequency, and ensures that the frequency is different at
each occurrence of the cell. As consequence, EBs are sent on all
frequencies regardless of the channelOffset configured.*

*Thanks for pointing out that this isn't clear. I created
**http://tools.ietf.org/wg/6tisch/trac/ticket/22
<http://tools.ietf.org/wg/6tisch/trac/ticket/22> to track this, and will
propose some new text as part of resolving this ticket.*

>
>             1.c.2 - a mote listens in all the frequencies as well, until
> find a EB with the low join priority (of a PAN Coordinator is zero - pag.
> 90 of 15.4e)
>
> or explain a little this part of the standard: "When a new device wants to
> join a network, it uses the MLME SCAN.request primitive in order to
> initiate a channel scan over a given list of channels. It searches for all
> coordinators transmitting enhanced beacon frames within the maximum BI
> period ". pag 48 of the Standard, it is for DSME, but I think it applies as
> well for TSCH.  Just to clarify which is the first channel which the mote
> listen for EBs.  I think a mote start in channel 11 until channel 26.
>
>
*The policy of what frequency to listen on when joining a network is up to
the implementation, and I believe that we shouldn't force implementers to
do it a certain way. Would you agree? That being said, I completely agree
that 1-2 sentences much along the lines of the IEEE802.15.4e-2012 standard
will help clarify things. I created
**http://tools.ietf.org/wg/6tisch/trac/ticket/23
<http://tools.ietf.org/wg/6tisch/trac/ticket/23> to track this. Thanks!*

>
> 2- when a mote join to the network in which slot of the slotframe cames
> the EB. In the ietf-minimal draft version 00 states: "The first slot in
> the slotframe is used to send Enhanced Beacons announcing the presence of
> the network" and in the figure (pag. 4) was used the first slot of the
> channel 0. It was deleted in the next versions, since it depends of the
> configuration that 6top does using CONFIGURE.eb - slotOffset (the
> slotOffset where the EBs must be sent. Zero if any Any timeslot can be
> used). so, in this case (slotOffset=0 and channelOffset=0 ) a joining node
> starts listen in all the channels until find a EB in some slot. right?
>
>
*Correct. A joining node is not synchronized to the network (yet). So it
just receives a EB at some point, not really in a slot. I added a comment
in **http://tools.ietf.org/wg/6tisch/trac/ticket/23
<http://tools.ietf.org/wg/6tisch/trac/ticket/23> to make this clearer.
Please let me know if you don't agree to keep these two items in the same
ticket.*

>
> 3- Related to PHY-FH (page 202/203 of 15.4e) [
> http://www.ietf.org/mail-archive/web/6tisch/current/msg01753.html] , in
> case that it were not complex,  should be 6top the layer to handle PHY-FH ?
>
>
*No. Per Pat's comment "**None of the PHY task groups believed the
advantages of a fast hop PHY justified its additional complexity hence it
wasn't standardized**". Since 6TiSCH is chartered to operated on top of
IEEE802.15.4e, I believe (strongly) that we should not considered elements
not currently in the IEEE802.15.4e standard.*

>
> Thank you very much in advance,
>
>
*Thank you! I believe **draft-ietf-6tisch-tsch is close to being ready, so
your review is very timely. Please don't hesitate if you have any other
comments!*

>
> Ines.
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Rene Struik <[email-masked]>
Date: Thu, 02 Oct 2014 16:28:01 -0400

Hi Thomas:

I just read your message to Ines (which I somehow did not get in my 
inbox last week).

Three additional notes that may be relevant tot eh 6tisch-tsch draft and 
that may be worth mentioning:
a) It may be good to mention that the number of timeslots in a slotframe 
is always a prime number (thus, assuring that one cycles through all 
frequencies) {or, has no prime factors smaller than max#frequencies +1, 
if one wants to be more precise}.
b) I think the join priority language in 802.15.4e is irrelevant, at 
least for 6tisch (since it seems to assume a tree-like network formation 
structure, which is only one way of doing things and not necessarily the 
best).
c) The TSCH mode cannot really be set before completion of the join 
protocol (this is an error in the 802.15.4e draft).

Best regards, Rene

On 10/2/2014 3:33 PM, Thomas Watteyne wrote:
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>
>     I have some questions:
>
>
>             1.a-  in A.1 Timeslots, states: "The duration of a
>     timeslot is not defined by the standard". The 802.15.4e standard
>     defines in page 176 the field:
>
>
>     macTsTimeslotLength
>
>
>     Range:  0x0000– 0xffff
>
>
>     The total length of the timeslot including any  unused time after
>     frame transmission and Acknowledgment, in μs
>
>
>     default:  10000 = (10 ms)
>
>
> *I'm not entirely sure I understand your question. I assume you mean 
> that the sentence "The duration of a timeslot is not defined by the 
> standard" isn't clear? Would the following rewording work for you?*
> *
> *
> *"The duration of a timeslot is not mandated by the standard"**
> *
> *
> *
> *
> *
>               1.b- In the same section  states: "...with a 10 ms slot
>     (a typical duration)", would be good maybe if it is added for
>     example the amount of khz for these 10 ms, like "10 ms is a
>     typical duration for a quartz crystal of  32.768 kHz"?
>
>
>
> *The crystal is just the internal mechanism for the device to measure 
> time. You can measure 10ms (or other durations) with crystals of 
> different frequencies, or entirely other clock sources, so I don't see 
> 10ms as being "typical duration" for 32kHz crystals. If this is 
> confusing, I believe we should take out the text about crystals, it's 
> just there for illustration.*
> *
> *
> *What do others think?*
>
>     frequencies.  A mote wishing to join the network listens for
>     EBs....", maybe would be good to add in some way that:
>
>
>                 1.c.1 -  EB are sent on all frequencies if
>     CONFIGURE.eb (channelOffset) = 0 (pag 25 6top-sublayer draft), right?
>
>
> *Channel hopping turns the [channel offset,timeslot offset, ASN] tuple 
> into a frequency, and ensures that the frequency is different at 
> *
> *
> **http://tools.ietf.org/wg/6tisch/trac/ticket/22 to track this, and 
> will propose some new text as part of resolving this ticket.*
>
>
>                 1.c.2 - a mote listens in all the frequencies as well,
>     until find a EB with the low join priority (of a PAN Coordinator
>     is zero - pag. 90 of 15.4e)
>
>     or explain a little this part of the standard: "When a new device
>     wants to join a network, it uses the MLME SCAN.request primitive
>     in order to initiate a channel scan over a given list of channels.
>     It searches for all coordinators transmitting enhanced beacon
>     frames within the maximum BI period ". pag 48 of the Standard, it
>     is for DSME, but I think it applies as well for TSCH.  Just to
>     clarify which is the first channel which the mote listen for EBs. 
>     I think a mote start in channel 11 until channel 26.
>
>
>
> *The policy of what frequency to listen on when joining a network is 
> up to the implementation, and I believe that we shouldn't 
> force implementers to do it a certain way. Would you agree? That being 
> said, I completely agree that 1-2 sentences much along the lines of 
> the IEEE802.15.4e-2012 standard will help clarify things. I created 
> **http://tools.ietf.org/wg/6tisch/trac/ticket/23 to track this. Thanks!*
>
>
>     2- when a mote join to the network in which slot of the slotframe
>     cames the EB. In the ietf-minimal draft version 00 states: "The
>     first slot in the slotframe is used to send Enhanced Beacons
>     announcing the presence of the network" and in the figure (pag. 4)
>     was used the first slot of the channel 0. It was deleted in the
>     next versions, since it depends of the configuration that 6top
>     does using CONFIGURE.eb - slotOffset (the slotOffset where the EBs
>     must be sent. Zero if any Any timeslot can be used). so, in this
>     case (slotOffset=0 and channelOffset=0 ) a joining node starts
>     listen in all the channels until find a EB in some slot. right?
>
>
>
> *Correct. A joining node is not synchronized to the network (yet). So 
> it just receives a EB at some point, not really in a slot. I added a 
> comment in **http://tools.ietf.org/wg/6tisch/trac/ticket/23 to make 
> this clearer. Please let me know if you don't agree to keep these two 
> items in the same ticket.*
>
>
>     3- Related to PHY-FH (page 202/203 of 15.4e)
>     [http://www.ietf.org/mail-archive/web/6tisch/current/msg01753.html] ,
>     in case that it were not complex,  should be 6top the layer to
>     handle PHY-FH ?
>
>
>
> advantages of a fast hop PHY justified its additional complexity hence 
> it wasn't standardized**". Since 6TiSCH is chartered to operated on 
> top of IEEE802.15.4e, I believe (strongly) that we should not 
> considered elements not currently in the IEEE802.15.4e standard.*
>
>
> *Thank you! I believe **draft-ietf-6tisch-tsch is close to being 
> ready, so your review is very timely. Please don't hesitate if you 
> have any other comments!*
>
>
>     Ines.
>
>     [email-masked] <mailto:[email-masked]>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Pat Kinney <[email-masked]>
Date: Thu, 2 Oct 2014 22:13:22 -0500

I would like to add my comments to Rene's and Thomas's:

Thomas:
"The duration of a timeslot is not mandated by the standard"- "is the better way to restate "The duration of a timeslot is not defined by the standard"
"I believe we should take out the text about crystals,"  I agree, crystals are an implementation method that should not be dictated in a standard
"EBs are sent on all frequencies regardless of the channelOffset configured."  I agree
"The policy of what frequency to listen on when joining a network is up to the implementation, and I believe that we shouldn't force implementers to do it a certain way. Would you agree? That being said, I completely agree that 1-2 sentences much along the lines of the IEEE802.15.4e-2012 standard will help clarify things."  I agree with the concept, 6TiSCH shouldn't quote the IEEE 802.15.4 standard rather it should state the intent and then reference the text in the 15.4 standard

Rene:
"It may be good to mention that the number of timeslots in a slotframe is always a prime number (thus, assuring that one cycles through all frequencies)"  - this would be a good informational note
"I think the join priority language in 802.15.4e is irrelevant, at least for 6tisch" - I disagree that the text is irrelevant, but I think that IEEE could edit the text in 15.4 for the sake of clarity along the line of "the join priority field setting gives information to the device to make a better decision of which node to join... " 
"The TSCH mode cannot really be set before completion of the join protocol (this is an error in the 802.15.4e draft)" -   I disagree that this is an error in the 15.4 standard, The current text "Once the listening device has heard a valid Enhanced Beacon, it generates an MLME-BEACON-NOTIFY.indication to a higher layer. The higher layer may initialize the slotframe and links contained in the Enhanced Beacon and switch the device into TSCH mode with a TSCH MODE.request or wait for additional MLME-BEACON-NOTIFY.indication primitives before doing so." essentially states that once the device has received a beacon with acceptable parameters as determined by the upper layer, the upper layer may decide to initiate TSCH by sending the MAC a MLME-TSCH-MODE.request of TSCHMode set to ON

Thanks, Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked]

On Oct 2, 2014, at 3:28 PM, Rene Struik <[email-masked]> wrote:

Hi Thomas:

I just read your message to Ines (which I somehow did not get in my inbox last week).

Three additional notes that may be relevant tot eh 6tisch-tsch draft and that may be worth mentioning:
a) It may be good to mention that the number of timeslots in a slotframe is always a prime number (thus, assuring that one cycles through all frequencies) {or, has no prime factors smaller than max#frequencies +1, if one wants to be more precise}. 
b) I think the join priority language in 802.15.4e is irrelevant, at least for 6tisch (since it seems to assume a tree-like network formation structure, which is only one way of doing things and not necessarily the best).
c) The TSCH mode cannot really be set before completion of the join protocol (this is an error in the 802.15.4e draft). 

Best regards, Rene 

On 10/2/2014 3:33 PM, Thomas Watteyne wrote:
> Ines,
> 
> Thanks a million for reviewing this document. Please find my answers inline.
> 
> On Wed, Sep 24, 2014 at 3:06 PM, Ines Robles <[email-masked]> wrote:
> Hi,
> 
> 
>                     
> I
>                       have some questions:
> 
> 1-
>                               1.a-  in A.1 Timeslots, states: "The
>                       duration of a timeslot is not defined by the
>                       standard". The 802.15.4e standard defines in page
>                       176 the field:
> 
> macTsTimeslotLength
>                     
> 
> Range:
>                        0x0000– 0xffff
> 
> The
>                       total length of the timeslot including any  unused
>                       time after frame transmission and Acknowledgment,
>                       in μs
> 
> default:
>                        10000 = (10 ms)
> 
> and
>                       it is mentioned as well in the minimal draft.(page
>                       7)
> 
> 
> I'm not entirely sure I understand your question. I assume you mean that the sentence "The duration of a timeslot is not defined by the standard" isn't clear? Would the following rewording work for you?
> 
> "The duration of a timeslot is not mandated by the standard"
> 
> As soon as you confirm this is indeed what you meant, I will create a ticket.
> 
>  
> 
> 
>                                 1.b- In the same section  states:
>                       "...with a 10 ms slot (a typical duration)", would
>                       be good maybe if it is added for example the
>                       amount of khz for these 10 ms, like "10 ms is a
> The crystal is just the internal mechanism for the device to measure time. You can measure 10ms (or other durations) with crystals of different frequencies, or entirely other clock sources, so I don't see 10ms as being "typical duration" for 32kHz crystals. If this is confusing, I believe we should take out the text about crystals, it's just there for illustration.
> 
> What do others think?
>  
> 
>                                    1.c -  In A.11 states: "..EB frames
>                       are sent on all frequencies.  A mote wishing to
>                       join the network listens for EBs....", maybe would
>                       be good to add in some way that:
> 
> 
>                                   1.c.1 -  EB are sent on all
>                       frequencies if CONFIGURE.eb (channelOffset) = 0
>                       (pag 25 6top-sublayer draft), right?
> 
> Channel hopping turns the [channel offset,timeslot offset, ASN] tuple into a frequency, and ensures that the frequency is different at each occurrence of the cell. As consequence, EBs are sent on all frequencies regardless of the channelOffset configured.
> 
> Thanks for pointing out that this isn't clear. I created http://tools.ietf.org/wg/6tisch/trac/ticket/22 to track this, and will propose some new text as part of resolving this ticket.
>  
> 
> 
>                                   1.c.2 - a mote listens in all the
>                       frequencies as well, until find a EB with the low
>                       join priority (of a PAN Coordinator is zero - pag.
>                       90 of 15.4e) 
> or
>                       explain a little this part of the standard: "When
>                       a new device wants to join a network, it uses the
>                       MLME SCAN.request primitive in order to initiate a
>                       channel scan over a given list of channels. It
>                       searches for all coordinators transmitting
>                       enhanced beacon frames within the maximum BI
>                       period ". pag 48 of the Standard, it is for DSME,
>                       but I think it applies as well for TSCH.  Just to
>                       clarify which is the first channel which the mote
> The policy of what frequency to listen on when joining a network is up to the implementation, and I believe that we shouldn't force implementers to do it a certain way. Would you agree? That being said, I completely agree that 1-2 sentences much along the lines of the IEEE802.15.4e-2012 standard will help clarify things. I created http://tools.ietf.org/wg/6tisch/trac/ticket/23 to track this. Thanks!
>  
> 
> 2-
>                       when a mote join to the network in which slot of
>                       the slotframe cames the EB. In the ietf-minimal
>                       draft version 00 states: "The
>                       first slot in the slotframe is used to send
>                       Enhanced Beacons announcing the presence of the
>                       network"
>                       and in the figure (pag. 4) was used the first slot
>                       of the channel 0. It was deleted in the next
>                       versions, since it depends of the configuration
>                       that 6top does using CONFIGURE.eb - slotOffset
>                       (the slotOffset where the EBs must be sent. Zero
>                       if any Any timeslot can be used). so, in this case
>                       (slotOffset=0 and channelOffset=0 ) a joining node
> Correct. A joining node is not synchronized to the network (yet). So it just receives a EB at some point, not really in a slot. I added a comment in http://tools.ietf.org/wg/6tisch/trac/ticket/23 to make this clearer. Please let me know if you don't agree to keep these two items in the same ticket.
>  
> 
> 3-
>                       Related to PHY-FH (page
>                       202/203 of 15.4e) [http://www.ietf.org/mail-archive/web/6tisch/current/msg01753.html]
>                       , in case that it were not complex,  should be
>                       6top the layer to handle PHY-FH ?
> 
> 
> No. Per Pat's comment "None of the PHY task groups believed the advantages of a fast hop PHY justified its additional complexity hence it wasn't standardized". Since 6TiSCH is chartered to operated on top of IEEE802.15.4e, I believe (strongly) that we should not considered elements not currently in the IEEE802.15.4e standard.
>  
> 
> Thank
> Thank you! I believe draft-ietf-6tisch-tsch is close to being ready, so your review is very timely. Please don't hesitate if you have any other comments!
>  
> 
> Ines.
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 03 Oct 2014 15:58:27 -0400

Hi Pat:

Please see below.

Best regards, Rene

On 10/2/2014 11:13 PM, Pat Kinney wrote:
>   * "The duration of a timeslot is not mandated by the standard"- "is
>     the better way to restate "The duration of a timeslot is not
>     defined by the standard"
>   * "I believe we should take out the text about crystals," I agree,
>     crystals are an implementation method that should not be dictated
>     in a standard
>   * "*EBs are sent on all frequencies regardless of the channelOffset
>     configured.*" I agree
>
>  *
>     "*The policy of what frequency to listen on when joining a network
>     is up to the implementation, and I believe that we shouldn't
>     force implementers to do it a certain way. Would you agree? That
>     being said, I completely agree that 1-2 sentences much along the
>     lines of the IEEE802.15.4e-2012 standard will help clarify
>     things.*" I agree with the concept, 6TiSCH shouldn't quote the
>     IEEE 802.15.4 standard rather it should state the intent and then
>     reference the text in the 15.4 standard
>
>
> Rene:
>
>   * "It may be good to mention that the number of timeslots in a
>     slotframe is always a prime number (thus, assuring that one cycles
>     through all frequencies)"  - this would be a good informational note
>   * "I think the join priority language in 802.15.4e is irrelevant, at
>     least for 6tisch" - I disagree that the text is irrelevant, but I
>     think that IEEE could edit the text in 15.4 for the sake of
>     clarity along the line of "the join priority field setting gives
>     information to the device to make a better decision of which node
>     to join... "
>
RS>> the join priority metric in 802.15.4e seems to assume that "the 
closer the attachment point is to the PAN coordinator, the better". This 
is debatable, at least with 6TiSCH: as an example, one should consider 
that this value is determined by the order in which other nodes joined 
the network prior, so taken to the extreme, it could mean that all nodes 
try to attach to the PAN coordinator, thereby overloading it). Etc., etc.
<<RS
>
>   * "The TSCH mode cannot really be set before completion of the join
>     protocol (this is an error in the 802.15.4e draft)" - I disagree
>     that this is an error in the 15.4 standard, The current text
>     "/Once the listening device has heard a //valid Enhanced Beacon,
>     it generates an MLME-BEACON-NOTIFY.indication to a higher layer.
>     The higher layer may initialize the slotframe and links contained
>     in the Enhanced Beacon and switch the device into TSCH mode with a
>     TSCH MODE.request or wait for additional
>     MLME-BEACON-NOTIFY.indication primitives before doing so/."
>     essentially states that once the device has received a beacon with
>     acceptable parameters as determined by the upper layer, the upper
>     layer may decide to initiate TSCH by sending the MAC
>     a MLME-TSCH-MODE.request of TSCHMode set to ON
>
RS>> Once a device has been switched into TSCH mode, it has to operate 
in a synchronized fashion and securely (including secure ACKs). However, 
the parms required for this only become available after successful 
completion of the join protocol (which, BTW, is a higher layer protocol, 
so would be triggered by a MCPS-DATA.indication primitive from a MAC 
perspective). In particular, please note that the ASN entry received 
from the neighbor in an enhanced beacon is not necessarily the same as 
the one from the network manager (see outstanding items discussed during 
IETF-90 in Toronto).
<<RS
>
> Thanks, Pat
>
> Pat Kinney
> */Kinney Consulting LLC/*
> <mailto:[email-masked]>
>
> On Oct 2, 2014, at 3:28 PM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi Thomas:
>
> a) It may be good to mention that the number of timeslots in a 
> slotframe is always a prime number (thus, assuring that one cycles 
> through all frequencies) {or, has no prime factors smaller than 
> max#frequencies +1, if one wants to be more precise}.
> least for 6tisch (since it seems to assume a tree-like network 
> formation structure, which is only one way of doing things and not 
> necessarily the best).
>> *As soon as you confirm this is indeed what you meant, I will create 
>> a ticket.*
>> *
>> *
>>
>>
>> different frequencies, or entirely other clock sources, so I don't 
>> see 10ms as being "typical duration" for 32kHz crystals. If this is 
>> *Channel hopping turns the [channel offset,timeslot offset, ASN] 
>> tuple into a frequency, and ensures that the frequency is different 
>> at each occurrence of the cell. As consequence, EBs are sent on all 
>>                 1.c.2 - a mote listens in all the frequencies as
>>     well, until find a EB with the low join priority (of a PAN
>>     Coordinator is zero - pag. 90 of 15.4e)
>>     in order to initiate a channel scan over a given list of
>>     channels. It searches for all coordinators transmitting enhanced
>>     beacon frames within the maximum BI period ". pag 48 of the
>>     Standard, it is for DSME, but I think it applies as well for
>>     TSCH.  Just to clarify which is the first channel which the mote
>> force implementers to do it a certain way. Would you agree? That 
>> being said, I completely agree that 1-2 sentences much along the 
>> lines of the IEEE802.15.4e-2012 standard will help clarify things. I 
>> created **http://tools.ietf.org/wg/6tisch/trac/ticket/23 to track 
>> this. Thanks!*
>>
>>
>>     announcing the presence of the network" and in the figure (pag.
>>     4) was used the first slot of the channel 0. It was deleted in
>>     the next versions, since it depends of the configuration that
>>     6top does using CONFIGURE.eb - slotOffset (the slotOffset where
>>     the EBs must be sent. Zero if any Any timeslot can be used). so,
>>     in this case (slotOffset=0 and channelOffset=0 ) a joining node
>>     [http://www.ietf.org/mail-archive/web/6tisch/current/msg01753.html]
>>     , in case that it were not complex,  should be 6top the layer to
>>     handle PHY-FH ?
>>
>>
>> advantages of a fast hop PHY justified its additional complexity 
>> hence it wasn't standardized**". Since 6TiSCH is chartered to 
>> operated on top of IEEE802.15.4e, I believe (strongly) that we should 
>> not considered elements not currently in the IEEE802.15.4e standard.*
>>
>>
> email:[email-masked]  | Skype: rstruik

---

From: Pat Kinney <[email-masked]>
Date: Fri, 3 Oct 2014 15:59:30 -0500

Rene:
Thanks for your response.

To your comment: "RS>> the join priority metric in 802.15.4e seems to assume that "the closer the attachment point is to the PAN coordinator, the better". This is debatable, at least with 6TiSCH: as an example, one should consider that this value is determined by the order in which other nodes joined the network prior, so taken to the extreme, it could mean that all nodes try to attach to the PAN coordinator, thereby overloading it). Etc., etc"<<RS.  Upon reflecting on this matter after I wrote my original response, I now agree that, while the current joining priority is useful and sufficient in many cases, the joining priority may not lead to the best decision in others.  Other metrics can also be important such as signal strength (both to joining device and to beaconing device), beaconing device's loading (i.e. can it support joining in a timely manner? which is similar to your example), beaconing device's energy supply (is it mains powered?  energy harvesting powered? battery?).  Additionally, how does the backbone router (BBR) fit into this priority?  If a beaconing device is connected to a BBR is the BBR transparent? (i.e. the beaconing device is = other end beaconing device +1?).  So while I believe that the current mechanism is very simple and usually effective, it could be better if we were to enhance the TSCH Synchronization IE to include other parameters.

To your comment: "RS>> Once a device has been switched into TSCH mode, it has to operate in a synchronized fashion and securely (including secure ACKs). However, the parms required for this only become available after successful completion of the join protocol (which, BTW, is a higher layer protocol, so would be triggered by a MCPS-DATA.indication primitive from a MAC perspective). In particular, please note that the ASN entry received from the neighbor in an enhanced beacon is not necessarily the same as the one from the network manager (see outstanding items discussed during IETF-90 in Toronto).<<RS"  I think that my answer is really addressing the device's initial state and its steps towards operation while yours is addressing its operation.  For a device to join a TSCH network, the following three steps must occur:
it must first receive an Enhanced Beacon, and sends an MLME-BEACON-NOTIFY.indication to the higher layer containing the EB's (Time information so new devices can synchronize to the network, Channel hopping information, Time slot information describing when to expect a frame to be transmitted and when to send an acknowledgment, and Initial link and slotframe information so new devices know when to listen for transmissions from the advertising device and when they can transmit to the advertising device
the higher layer then uses the EB information to initialize the slotframe and links via an MLME-SETSLOTFRAME.request and an MLME-SETLINK.request, and then switch the device into TSCH mode via a TSCH MODE.request.  Note that at this point the device is synchronized to the network
higher layer works with the MAC to execute procedures such as allocation of additional communication resources (slotframes and links) to the joining device, a security handshake to mutually authenticate the joining device, configure encryption keys, and configure routing information, etc. 
So a device must be in its TSCH mode before it can join the network.

As far as the ASN goes, it seems that you believe that different devices (e.g. enhanced beacon device and a network manager) could have a sense of a different ASN, but that is contrary to the TSCH principal that the ASN is a global number within the network.  Multiple values of ASN within the network would severely degrade network operation as it is used to compute the channel for any given pairwise communication.

BTW:  I am not sure why you state that security must be used, since I do not recall that security is mandatory for TSCH (I understand that Wireless HART mandates security)

Pat

Pat Kinney
Kinney Consulting LLC

On Oct 3, 2014, at 2:58 PM, Rene Struik <[email-masked]> wrote:

Hi Pat:

Please see below.

Best regards, Rene

On 10/2/2014 11:13 PM, Pat Kinney wrote:
> "The duration of a timeslot is not mandated by the standard"- "is the better way to restate "The duration
>                 of a timeslot is not defined by the standard"
> "I believe we
>                 should take out the text about crystals," I agree, crystals are an implementation
>                 method that should not be dictated in a standard
> "EBs are sent on all frequencies
>                     regardless of the channelOffset configured." I agree
> 
>               
> 
>                 
> 
>                   
> "The
>                           policy of what frequency to listen on when
>                           joining a network is up to the implementation,
>                           and I believe that we shouldn't
>                           force implementers to do it a certain way.
>                           Would you agree? That being said, I completely
>                           agree that 1-2 sentences much along the lines
>                           of the IEEE802.15.4e-2012 standard will help
>                           clarify things." I agree with the concept, 6TiSCH
>                       shouldn't quote the IEEE 802.15.4 standard rather
>                       it should state the intent and then reference the
>                       text in the 15.4 standard
> 
>                   
> 
> 
>                   
> 
>                   
> 
> 
>                   
> 
>                 
> 
>               
> 
>             
> Rene:
RS>> the join priority metric in 802.15.4e seems to assume that "the closer the attachment point is to the PAN coordinator, the better". This is debatable, at least with 6TiSCH: as an example, one should consider that this value is determined by the order in which other nodes joined the network prior, so taken to the extreme, it could mean that all nodes try to attach to the PAN coordinator, thereby overloading it). Etc., etc.
<<RS 
> "The TSCH mode cannot really be set before completion of the join protocol (this is an error in the 802.15.4e draft)" -   I disagree that this is an error in the 15.4 standard, The current text "On…
RS>> Once a device has been switched into TSCH mode, it has to operate in a synchronized fashion and securely (including secure ACKs). However, the parms required for this only become available after successful completion of the join protocol (which, BTW, is a higher layer protocol, so would be triggered by a MCPS-DATA.indication primitive from a MAC perspective). In particular, please note that the ASN entry received from the neighbor in an enhanced beacon is not necessarily the same as the one from the network manager (see outstanding items discussed during IETF-90 in Toronto).
<<RS
>> 1-
>>                                 related with draft-ietf-6tisch-tsch-01:
>> 
>> 
>>                                 defined by the standard". The 802.15.4e
>>                                 standard defines in page 176 the field:
>> 
>> macTsTimeslotLength
>> 
>>                               
>> 
>> Range:
>> 
>>                                  0x0000– 0xffff
>> 
>> The
>> 
>>                                 total length of the timeslot including
>>                                 any  unused time after frame
>>                                 it is mentioned as well in the minimal
>>                                 draft.(page 7)
>> 
>> 
>>                                 typical duration)", would be good maybe
>>                                 if it is added for example the amount of
>>                                 khz for these 10 ms, like "10 ms is a
>>                                 typical duration for a quartz crystal of
>>                                32.768
>> 
>>                                 kHz"?
>> 
>>                               
>> 
>> 
>>                                 frequencies.  A mote wishing to join the
>>                                 network listens for EBs....", maybe
>>                                 would be good to add in some way that:
>> 
>> 
>>                                 frequencies if CONFIGURE.eb
>>                                             1.c.2 - a mote listens in
>>                                 all the frequencies as well, until find
>>                                 a EB with the low join priority (of a
>>                                 PAN Coordinator is zero - pag. 90 of
>>                                 15.4e) 
>> or
>> 
>>                                 explain a little this part of the
>>                                 standard: "When a new device wants to
>>                                 period ". pag 48 of the Standard, it is
>>                                 for DSME, but I think it applies as well
>>                                 for TSCH.  Just to clarify which is the
>>                                 first channel which the mote listen for
>>                                 EBs.  I think a mote start in channel 11
>>                                 until channel 26.
>> 
>> 
>>                                 when a mote join to the network in which
>>                                 slot of the slotframe cames the EB. In
>>                                 the ietf-minimal draft version 00
>>                                 states: "The first slot in the
>>                                 slotframe is used to send Enhanced
>>                                 Beacons announcing the presence of the
>>                                 network"
>>                                 and in the figure (pag. 4) was used the
>>                                 first slot of the channel 0. It was
>>                                 deleted in the next versions, since it
>>                                 depends of the configuration that 6top
>>                                 does using CONFIGURE.eb - slotOffset
>>                                 (the slotOffset where the EBs must be
>>                                 sent. Zero if any Any timeslot can be
>>                                 , in case that it were not complex,
>>                                  should be 6top the layer to handle
>>                                 PHY-FH ?
>> 
>> 
>> Thank
>>                                 you very much in advance,
>> 
>>

---

From: Rene Struik <[email-masked]>
Date: Fri, 03 Oct 2014 17:54:46 -0400

Hi Pat:

Some further comments below.

(BTW - main point of my notes yesterday is that some of these items may 
require more thought or revisiting in light of our current ideas of how 
one could deploy these networks.)

Have a nice weekend.

Best regards, Rene

On 10/3/2014 4:59 PM, Pat Kinney wrote:
> To your comment: _"RS>> the join priority metric in 802.15.4e seems to 
> assume that "the closer the attachment point is to the PAN 
> coordinator, the better". This is debatable, at least with 6TiSCH: as 
> an example, one should consider that this value is determined by the 
> order in which other nodes joined the network prior, so taken to the 
> extreme, it could mean that all nodes try to attach to the PAN 
> coordinator, thereby overloading it). Etc., etc"<<RS._Upon reflecting 
> on this matter after I wrote my original response, I now agree that, 
> while the current joining priority is useful and sufficient in many 
> cases, the joining priority may not lead to the best decision in 
> others.  Other metrics can also be important such as signal strength 
> (both to joining device and to beaconing device), beaconing device's 
> loading (i.e. can it support joining in a timely manner? which is 
> similar to your example), beaconing device's energy supply (is it 
> mains powered?  energy harvesting powered? battery?).  Additionally, 
> how does the backbone router (BBR) fit into this priority?  If a 
> beaconing device is connected to a BBR is the BBR transparent? (i.e. 
> the beaconing device is = other end beaconing device +1?).  So while I 
> believe that the current mechanism is very simple and usually 
> effective, it could be better if we were to enhance the TSCH 
> Synchronization IE to include other parameters.
RS>> good point about the backbone router, etc. With security glasses 
on, in fact it is not a priori clear that the entire trail to the 
network manager/PAN coordinator would have to be TSCH-enabled devices. 
Main point of my original email of yesterday to Thomas Watteyne was to 
suggest that, indeed, join priority is not always the right decision 
variable.
<<RS
>
> To your comment: _"RS>> Once a device has been switched into TSCH 
> mode, it has to operate in a synchronized fashion and securely 
> (including secure ACKs). However, the parms required for this only 
> become available after successful completion of the join protocol 
> (which, BTW, is a higher layer protocol, so would be triggered by a 
> MCPS-DATA.indication primitive from a MAC perspective). In particular, 
> please note that the ASN entry received from the neighbor in an 
> enhanced beacon is not necessarily the same as the one from the 
> network manager (see outstanding items discussed during IETF-90 in 
> Toronto).<<RS_"  I think that my answer is really addressing the 
> device's initial state and its steps towards operation while yours is 
> addressing its operation.  For a device to join a TSCH network, the 
> following three steps must occur:
>
>  1. it must first receive an Enhanced Beacon, and sends
>     an MLME-BEACON-NOTIFY.indication to the higher layer containing
>     the EB's (Time information so new devices can synchronize to the
>     network, Channel hopping information, Time slot information
>     describing when to expect a frame to be transmitted and when to
>     send an acknowledgment, and Initial link and slotframe information
>     so new devices know when to listen for transmissions from the
>     advertising device and when they can transmit to the advertising
>     device
>  2. the higher layer then uses the EB information to initialize the
>     slotframe and links via an MLME-SETSLOTFRAME.request and
>     an MLME-SETLINK.request, and then switch the device into TSCH mode
>     via a TSCH MODE.request.  Note that at this point the device is
>     synchronized to the network
> 3.
>     higher layer works with the MAC to execute procedures such as
>     allocation of additional communication resources (slotframes and
>     links) to the joining device, a security handshake to mutually
>     authenticate the joining device, configure encryption keys, and
>     configure routing information, etc.
>
> As far as the ASN goes, it seems that you believe that different 
> devices (e.g. enhanced beacon device and a network manager) could have 
> a sense of a different ASN, but that is contrary to the TSCH principal 
> that the ASN is a global number within the network.  Multiple values 
> of ASN within the network would severely degrade network operation as 
> it is used to compute the channel for any given pairwise communication.
RS>>
Ideally, indeed the entire network should have the same (plus or minus) 
epsilon notion of time. However, this is not an axiom and requires work. 
If a newbee device corresponds to a neighbor device, it initially has no 
assurances whatsoever that whatever attributes it receives from it are 
proper (if it would, one would have to assume all nodes in any TSCH 
network are always in synch w.r.t. state and, e.g., to be trusted). 
Hence, one conservatively may wish to assume for the worst and that the 
notion of the neighbor and network manager may be off. This can then be 
corrected during the last stage of the join protocol (where newly joined 
device and network manager synchronize info). I hope this explains my 
thinking here.
<<RS

>
> BTW:  I am not sure why you state that security must be used, since I 
> do not recall that security is mandatory for TSCH (I understand that 
> Wireless HART mandates security)
RS>>
At the end of Clause 5.1.6.4.2, it is stated that security of an ACK 
should match that of the frame just received when in TSCH mode. If so, 
the first time a newbee device ACKs a secured message from the neighbor 
device, it should use security as well and, thereby, the ASN value. In 
theory, the neighbor could communicate with the newbee device insecurely 
all the way till the end of the join protocol, but that opens a can of 
worms (details omitted for now).

Main point is that we should carefully reconsider TSCH mode on/off 
switch operations and see whether these indeed work as anticipated when 
the 15.4e draft was written. I think not, but am open to be educated here.
<<RS
> On Oct 3, 2014, at 2:58 PM, Rene Struik <[email-masked] 
>>     "*The policy of what frequency to listen on when joining a
>>     network is up to the implementation, and I believe that we
>>     shouldn't force implementers to do it a certain way. Would you
>>     agree? That being said, I completely agree that 1-2 sentences
>>     much along the lines of the IEEE802.15.4e-2012 standard will help
>>     clarify things.*" I agree with the concept, 6TiSCH shouldn't
>>     quote the IEEE 802.15.4 standard rather it should state the
>>     intent and then reference the text in the 15.4 standard
>>
>>
>> Rene:
>>
>>     slotframe is always a prime number (thus, assuring that one
>>     cycles through all frequencies)"  - this would be a good
>>     informational note
>>   * "I think the join priority language in 802.15.4e is irrelevant,
>>     at least for 6tisch" - I disagree that the text is irrelevant,
>>     but I think that IEEE could edit the text in 15.4 for the sake of
> closer the attachment point is to the PAN coordinator, the better". 
> This is debatable, at least with 6TiSCH: as an example, one should 
> consider that this value is determined by the order in which other 
> nodes joined the network prior, so taken to the extreme, it could mean 
> that all nodes try to attach to the PAN coordinator, thereby 
> overloading it). Etc., etc.
> <<RS
>>
>>     in the Enhanced Beacon and switch the device into TSCH mode with
>>     a TSCH MODE.request or wait for additional
>>     essentially states that once the device has received a beacon
>>     with acceptable parameters as determined by the upper layer, the
>>     upper layer may decide to initiate TSCH by sending the MAC
> in a synchronized fashion and securely (including secure ACKs). 
> However, the parms required for this only become available after 
> successful completion of the join protocol (which, BTW, is a higher 
> layer protocol, so would be triggered by a MCPS-DATA.indication 
> primitive from a MAC perspective). In particular, please note that the 
> ASN entry received from the neighbor in an enhanced beacon is not 
> necessarily the same as the one from the network manager (see 
> outstanding items discussed during IETF-90 in Toronto).
> <<RS
>>
>> Thanks, Pat
>>
>> Pat Kinney
>>>     The total length of the timeslot including any  unused time
>>>     after frame transmission and Acknowledgment, in μs
>>>
>>>     default:  10000 = (10 ms)
>>>
>>>               1.b- In the same section  states: "...with a 10 ms
>>>     slot (a typical duration)", would be good maybe if it is added
>>>     for example the amount of khz for these 10 ms, like "10 ms is a
>>> *The crystal is just the internal mechanism for the device to 
>>> measure time. You can measure 10ms (or other durations) with 
>>> crystals of different frequencies, or entirely other clock sources, 
>>> so I don't see 10ms as being "typical duration" for 32kHz crystals. 
>>> If this is confusing, I believe we should take out the text about 
>>> crystals, it's just there for illustration.*
>>> *
>>> *
>>> *What do others think?*
>>>
>>>     or explain a little this part of the standard: "When a new
>>>     device wants to join a network, it uses the MLME SCAN.request
>>>     primitive in order to initiate a channel scan over a given list
>>>     of channels. It searches for all coordinators transmitting
>>>     enhanced beacon frames within the maximum BI period ". pag 48 of
>>>     the Standard, it is for DSME, but I think it applies as well for
>>>     2- when a mote join to the network in which slot of the
>>>     slotframe cames the EB. In the ietf-minimal draft version 00
>>>     states: "The first slot in the slotframe is used to send
>>>     Enhanced Beacons announcing the presence of the network" and in
>>>     the figure (pag. 4) was used the first slot of the channel 0. It
>>>     was deleted in the next versions, since it depends of the
>>>     configuration that 6top does using CONFIGURE.eb - slotOffset
>>>     (the slotOffset where the EBs must be sent. Zero if any Any
>>>     timeslot can be used). so, in this case (slotOffset=0 and
>>>     channelOffset=0 ) a joining node starts listen in all the
>>>     channels until find a EB in some slot. right?
>>>
>>>
>>> *Correct. A joining node is not synchronized to the network (yet). 
>>> So it just receives a EB at some point, not really in a slot. I 
>>> added a comment in **http://tools.ietf.org/wg/6tisch/trac/ticket/23 
>>> to make this clearer. Please let me know if you don't agree to keep 
>>> these two items in the same ticket.*
>>>
>>>
>>> operated on top of IEEE802.15.4e, I believe (strongly) that we 
>>> should not considered elements not currently in the IEEE802.15.4e 
>>> standard.*
>>>
>>>

---

From: Ines Robles <[email-masked]>
Date: Mon, 6 Oct 2014 01:04:10 +0300

Hi  Thomas,

Thank you very much for your reply :-). My comments bellow.

2014-10-02 22:33 GMT+03:00 Thomas Watteyne <[email-masked]>:

>>         1.a-  in A.1 Timeslots, states: "The duration of a timeslot is
>> not defined by the standard". The 802.15.4e standard defines in page 176
>> the field:
>>
>> macTsTimeslotLength
>>
>> Range:  0x0000– 0xffff
>>
> *"The duration of a timeslot is not mandated by the standard"  *
>

 Sorry If I was not clear,  in the minimal draft states "A 10ms time slot
length is the default value defined by [IEEE802154e
<http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02#ref-IEEE802154e>]"
I understand that the length = duration. Is that correct?

> time. You can measure 10ms (or other durations) with crystals of different

Ok, I got it, thank you :-)

> *Thanks for pointing out that this isn't clear. I created **http://tools.ietf.org/wg/6tisch/trac/ticket/22

Great, thank you :-)

>> or explain a little this part of the standard: "When a new device wants
>> to join a network, it uses the MLME SCAN.request primitive in order to
> do it a certain way. Would you agree? Yes*
>

> * That being said, I completely agree that 1-2 sentences much along the
> created **http://tools.ietf.org/wg/6tisch/trac/ticket/23

 thanks :-)

> Please let me know if you don't agree to keep these two items in the same

Yes, in the same ticket it is Ok,  thank you :-)

> not currently in the IEEE802.15.4e standard.*

Ok

> *Thank you! I believe **draft-ietf-6tisch-tsch is close to being ready,
> so your review is very timely. Please don't hesitate if you have any other
> comments!*
>

:-)

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 6 Oct 2014 18:23:48 -0700

Rene, Pat,

FYI, I am logging this discussion in the following tickets:
- [new] http://tools.ietf.org/wg/6tisch/trac/ticket/25 (clarify use of
MLME-TSCH-MODE.request primitive during joining?)
- [new] http://tools.ietf.org/wg/6tisch/trac/ticket/23 (clarify why EB are
sent on all frequencies)
- [updated] http://tools.ietf.org/wg/6tisch/trac/ticket/23 (now contains
your point about the length of a slotframe)

What I'll do is propose some new language to address those different points
by Thursday, so we can discuss this at the 6TiSCH call on Friday. Once we
reach consensus, I'll publish a new version of draft-ietf-6tisch-tsch.

Thomas

On Fri, Oct 3, 2014 at 2:54 PM, Rene Struik <[email-masked]> wrote:

> require more thought or revisiting in light of our current ideas of how one
> could deploy these networks.)
>
> Have a nice weekend.
>
> Best regards, Rene
>
>  To your comment: *"RS>> the join priority metric in 802.15.4e seems to
> assume that "the closer the attachment point is to the PAN coordinator, the
> better". This is debatable, at least with 6TiSCH: as an example, one should
> consider that this value is determined by the order in which other nodes
> joined the network prior, so taken to the extreme, it could mean that all
> nodes try to attach to the PAN coordinator, thereby overloading it). Etc.,
> etc"<<RS.*  Upon reflecting on this matter after I wrote my original
> response, I now agree that, while the current joining priority is useful
> and sufficient in many cases, the joining priority may not lead to the best
> decision in others.  Other metrics can also be important such as signal
> strength (both to joining device and to beaconing device), beaconing
> device's loading (i.e. can it support joining in a timely manner? which is
> similar to your example), beaconing device's energy supply (is it mains
> powered?  energy harvesting powered? battery?).  Additionally, how does the
> backbone router (BBR) fit into this priority?  If a beaconing device is
> connected to a BBR is the BBR transparent? (i.e. the beaconing device is =
> other end beaconing device +1?).  So while I believe that the current
> mechanism is very simple and usually effective, it could be better if we
> were to enhance the TSCH Synchronization IE to include other parameters.
>
> RS>> good point about the backbone router, etc. With security glasses on,
> in fact it is not a priori clear that the entire trail to the network
> manager/PAN coordinator would have to be TSCH-enabled devices. Main point
> of my original email of yesterday to Thomas Watteyne was to suggest that,
> indeed, join priority is not always the right decision variable.
> <<RS
>
>
>  To your comment: *"RS>> Once a device has been switched into TSCH mode,
> it has to operate in a synchronized fashion and securely (including secure
> ACKs). However, the parms required for this only become available after
> successful completion of the join protocol (which, BTW, is a higher layer
> protocol, so would be triggered by a MCPS-DATA.indication primitive from a
> MAC perspective). In particular, please note that the ASN entry received
> from the neighbor in an enhanced beacon is not necessarily the same as the
> one from the network manager (see outstanding items discussed during
> IETF-90 in Toronto).<<RS*"  I think that my answer is really addressing
> the device's initial state and its steps towards operation while yours is
>    an MLME-BEACON-NOTIFY.indication to the higher layer containing the
>    EB's (Time information so new devices can synchronize to the network, Channel
>    hopping information, Time slot information describing when to expect a
>    frame to be transmitted and when to send an acknowledgment, and Initial
>    link and slotframe information so new devices know when to listen for
>    transmissions from the advertising device and when they can transmit
>    to the advertising device
>    an MLME-SETLINK.request, and then switch the device into TSCH mode via a
>    TSCH MODE.request.  Note that at this point the device is synchronized to
>    the network
>    3. higher layer works with the MAC to execute procedures such as
>    allocation of additional communication resources (slotframes and links) to
>    the joining device, a security handshake to mutually authenticate the
>    joining device, configure encryption keys, and configure routing
>    information, etc.
>
>  As far as the ASN goes, it seems that you believe that different devices
> (e.g. enhanced beacon device and a network manager) could have a sense of a
> different ASN, but that is contrary to the TSCH principal that the ASN is a
> global number within the network.  Multiple values of ASN within the
> network would severely degrade network operation as it is used to compute
> the channel for any given pairwise communication.
>
> RS>>
> epsilon notion of time. However, this is not an axiom and requires work. If
> a newbee device corresponds to a neighbor device, it initially has no
> proper (if it would, one would have to assume all nodes in any TSCH network
> are always in synch w.r.t. state and, e.g., to be trusted). Hence, one
> conservatively may wish to assume for the worst and that the notion of the
> neighbor and network manager may be off. This can then be corrected during
> the last stage of the join protocol (where newly joined device and network
> manager synchronize info). I hope this explains my thinking here.
> <<RS
>
>
>  BTW:  I am not sure why you state that security must be used, since I do
> not recall that security is mandatory for TSCH (I understand that Wireless
> HART mandates security)
>
> RS>>
> should match that of the frame just received when in TSCH mode. If so, the
> first time a newbee device ACKs a secured message from the neighbor device,
> it should use security as well and, thereby, the ASN value. In theory, the
> neighbor could communicate with the newbee device insecurely all the way
> till the end of the join protocol, but that opens a can of worms (details
> omitted for now).
>
> Main point is that we should carefully reconsider TSCH mode on/off switch
> operations and see whether these indeed work as anticipated when the 15.4e
> draft was written. I think not, but am open to be educated here.
> <<RS
>
>
>  Pat
>
>  Pat Kinney
> *Kinney Consulting LLC*
>    - "The duration of a timeslot is not mandated by the standard"- "is
>    the better way to restate "The duration of a timeslot is not defined
>    by the standard"
>    - "I believe we should take out the text about crystals," I agree,
>    crystals are an implementation method that should not be dictated in a
>    standard
>    - "*EBs are sent on all frequencies regardless of the channelOffset
>    configured.*" I agree
>
>
>    -  "*The policy of what frequency to listen on when joining a network
>    said, I completely agree that 1-2 sentences much along the lines of the
>    IEEE802.15.4e-2012 standard will help clarify things.*" I agree with
>    the concept, 6TiSCH shouldn't quote the IEEE 802.15.4 standard rather it
>    should state the intent and then reference the text in the 15.4 standard
>
>
>
>    Rene:
>
>    - "It may be good to mention that the number of timeslots in a
>    slotframe is always a prime number (thus, assuring that one cycles through
>    all frequencies)"  - this would be a good informational note
>    - "I think the join priority language in 802.15.4e is irrelevant, at
>    think that IEEE could edit the text in 15.4 for the sake of clarity along
>    the line of "the join priority field setting gives information to the
>    device to make a better decision of which node to join... "
>
> closer the attachment point is to the PAN coordinator, the better". This is
> debatable, at least with 6TiSCH: as an example, one should consider that
> this value is determined by the order in which other nodes joined the
> network prior, so taken to the extreme, it could mean that all nodes try to
> attach to the PAN coordinator, thereby overloading it). Etc., etc.
> <<RS
>
>
>    - "The TSCH mode cannot really be set before completion of the join
>    that this is an error in the 15.4 standard, The current text "*Once
>    the listening device has heard a **valid Enhanced Beacon, it generates
>    an MLME-BEACON-NOTIFY.indication to a higher layer. The higher layer may
>    initialize the slotframe and links contained in the Enhanced Beacon and
>    switch the device into TSCH mode with a TSCH MODE.request or wait for
>    additional MLME-BEACON-NOTIFY.indication primitives before doing so*."
>    acceptable parameters as determined by the upper layer, the upper layer may
>    decide to initiate TSCH by sending the MAC a MLME-TSCH-MODE.request of TSCHMode
>    set to ON
>
>     RS>> Once a device has been switched into TSCH mode, it has to
> operate in a synchronized fashion and securely (including secure ACKs).
> However, the parms required for this only become available after successful
> completion of the join protocol (which, BTW, is a higher layer protocol, so
> would be triggered by a MCPS-DATA.indication primitive from a MAC
> perspective). In particular, please note that the ASN entry received from
> the neighbor in an enhanced beacon is not necessarily the same as the one
> from the network manager (see outstanding items discussed during IETF-90 in
> Toronto).
> <<RS
>
>
>  Thanks, Pat
>
>  Pat Kinney
> *Kinney Consulting LLC*
> frequencies) {or, has no prime factors smaller than max#frequencies +1, if
> one wants to be more precise}.
> b) I think the join priority language in 802.15.4e is irrelevant, at least
> for 6tisch (since it seems to assume a tree-like network formation
>  *The policy of what frequency to listen on when joining a network is up
> to the implementation, and I believe that we shouldn't
> said, I completely agree that 1-2 sentences much along the lines of the
> IEEE802.15.4e-2012 standard will help clarify things. I created **http://tools.ietf.org/wg/6tisch/trac/ticket/23
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>
> --

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 6 Oct 2014 18:36:18 -0700

Ines,

Thanks for the follow-up. About your point:

"A 10ms time slot length is the default value defined by [IEEE802154e
> I understand that the length = duration. Is that correct?

That's indeed what I had in mind. "Duration" is the right word; you
highlight that it might be confusing to use the term "length". I have
created http://tools.ietf.org/wg/6tisch/trac/ticket/26 to go through all
occurrences of "length" and replace with more explicit wording.

We will discuss draft-ietf-6tisch-tsch at the call on Friday. I plan on
drafting some new language by Thursday, to discuss on the call. After
confirming consensus on the ML, we will publish a new revision sometimes
next week.

Thomas

On Sun, Oct 5, 2014 at 3:04 PM, Ines Robles <[email-masked]>
wrote:

>> force implementers to do it a certain way. Would you agree? Yes*
>>
>
>
>

---

From: Ines Robles <[email-masked]>
Date: Wed, 8 Oct 2014 02:20:03 +0300

Ok, Thank you very much Thomas for your reply.

2014-10-07 4:36 GMT+03:00 Thomas Watteyne <[email-masked]>:

>> <http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02#ref-IEEE802154e>
>> ]" I understand that the length = duration. Is that correct?
>
>
> On Sun, Oct 5, 2014 at 3:04 PM, Ines Robles <
> [email-masked]> wrote:
>
>> Hi  Thomas,
>>
>>  Sorry If I was not clear,  in the minimal draft states "A 10ms time
>> slot length is the default value defined by [IEEE802154e
>> <http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02#ref-IEEE802154e>
>> ]" I understand that the length = duration. Is that correct?
>>
>>>
>>>
>>>
>>>>
>>>> until find a EB with the low join priority (of a PAN Coordinator is zero -
>>>> pag. 90 of 15.4e)
>>>>
>>>> the EB. In the ietf-minimal draft version 00 states: "The first slot
>>>> in the slotframe is used to send Enhanced Beacons announcing the presence
>>>> of the network" and in the figure (pag. 4) was used the first slot of
>>>> the channel 0. It was deleted in the next versions, since it depends of the
>>>> http://www.ietf.org/mail-archive/web/6tisch/current/msg01753.html] ,
>>>> in case that it were not complex,  should be 6top the layer to handle
>>>> PHY-FH ?
>>>>
>>>>