Subject: [6tisch] proposed rewording for last 2 issues draft-ietf-6tisch-tsch

From: Thomas Watteyne <[email-masked]>
Date: Thu, 23 Oct 2014 15:25:26 -0700

All,

We have two last remaining issues open on draft-ietf-6tisch-tsch. This
e-mail suggests a rewording for both. Please +1 if you agree, or propose
alternate rewording.

Thomas

---

For http://tools.ietf.org/wg/6tisch/trac/ticket/25:

OLD
A mote wishing to join the network listens for EBs. Since EBs are sent on
all frequencies, the joining node can listen on any frequency until it
hears an EB. What frequency it listens on, and whether it slowly changes
frequency during this joining period is implementation-specific. Using the
ASN and the other timing information of the EB, the new mote synchronizes
to the network. Using the slotframe and cell information from the EB, it
knows how to contact other nodes in the network.
NEW
A mote wishing to join the network listens for EBs. Since EBs are sent on
all frequencies, the joining node can listen on any frequency until it
hears an EB. What frequency it listens on is implementation-specific. Once
it has received one or more EBs, the new node enables the TSCH mode and
uses the ASN and the other timing information of the EB to synchronize to
the network. Using the slotframe and cell information from the EB, it knows
how to contact other nodes in the network.

---

For http://tools.ietf.org/wg/6tisch/trac/ticket/24

OLD
Motes already part of the network can periodically send Enhanced Beacon
(EB) frames to announce the presence of the network. These contain
information about the size of the timeslot used in the network, the current
ASN, information about the slotframes and timeslots the beaconing mote is
listening on, and a 1-byte join priority. Even if a node is configured to
send all EB frames on the same channel offset, because of the channel
hopping nature of TSCH described in <xref target="sec_channel_hopping" />,
this channel offset translates into a different frequency at different
slotframe cycles. As a result, EB frames are sent on all frequencies.
NEW
Motes already part of the network can periodically send Enhanced Beacon
(EB) frames to announce the presence of the network. These contain
information about the size of the timeslot used in the network, the current
ASN, information about the slotframes and timeslots the beaconing mote is
listening on, and a 1-byte join priority. The join priority field gives
information to make a better decision of which node to join. Even if a node
is configured to send all EB frames on the same channel offset, because of
the channel hopping nature of TSCH described in <xref
target="sec_channel_hopping" />, this channel offset translates into a
different frequency at different slotframe cycles. As a result, EB frames
are sent on all frequencies.

---

From: Kris Pister <[email-masked]>
Date: Thu, 23 Oct 2014 16:01:33 -0700

+1

ksjp

On 10/23/2014 3:25 PM, Thomas Watteyne wrote:
> e-mail suggests a rewording for both. Please +1 if you agree, or 
> propose alternate rewording.
>
> Thomas
>
> ---
>
> A mote wishing to join the network listens for EBs. Since EBs are sent 
> on all frequencies, the joining node can listen on any frequency until 
> it hears an EB. What frequency it listens on, and whether it slowly 
> changes frequency during this joining period is 
> implementation-specific. Using the ASN and the other timing 
> information of the EB, the new mote synchronizes to the network. Using 
> the slotframe and cell information from the EB, it knows how to 
> contact other nodes in the network.
> NEW
> A mote wishing to join the network listens for EBs. Since EBs are sent 
> on all frequencies, the joining node can listen on any frequency until 
> it hears an EB. What frequency it listens on is 
> implementation-specific. Once it has received one or more EBs, the new 
> node enables the TSCH mode and uses the ASN and the other timing 
> information of the EB to synchronize to the network. Using the 
> slotframe and cell information from the EB, it knows how to contact 
> other nodes in the network.
>
> ---
>
> Motes already part of the network can periodically send Enhanced 
> Beacon (EB) frames to announce the presence of the network. These 
> contain information about the size of the timeslot used in the 
> network, the current ASN, information about the slotframes and 
> timeslots the beaconing mote is listening on, and a 1-byte join 
> priority. Even if a node is configured to send all EB frames on the 
> same channel offset, because of the channel hopping nature of TSCH 
> described in <xref target="sec_channel_hopping" />, this channel 
> offset translates into a different frequency at different slotframe 
> cycles. As a result, EB frames are sent on all frequencies.
> NEW
> Motes already part of the network can periodically send Enhanced 
> Beacon (EB) frames to announce the presence of the network. These 
> contain information about the size of the timeslot used in the 
> network, the current ASN, information about the slotframes and 
> timeslots the beaconing mote is listening on, and a 1-byte join 
> priority. The join priority field gives information to make a better 
> decision of which node to join. Even if a node is configured to send 
> all EB frames on the same channel offset, because of the channel 
> hopping nature of TSCH described in <xref target="sec_channel_hopping" 
> />, this channel offset translates into a different frequency at 
> different slotframe cycles. As a result, EB frames are sent on all 
> frequencies.
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 24 Oct 2014 05:08:14 +0200

+1 too!
X

2014-10-24 1:01 GMT+02:00 Kris Pister <[email-masked]>:

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

---

From: Alfredo Grieco <[email-masked]>
Date: Fri, 24 Oct 2014 08:51:41 +0200

+1. thanks. Alfredo
Il giorno 24/ott/2014, alle ore 00:25, Thomas Watteyne <[email-masked]> ha scritto:

> All,
> 
> We have two last remaining issues open on draft-ietf-6tisch-tsch. This e-mail suggests a rewording for both. Please +1 if you agree, or propose alternate rewording.
> 
> Thomas
> 
> ---
> 
> A mote wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on, and whether it slowly changes frequency during this joining period is implementation-specific. Using the ASN and the other timing information of the EB, the new mote synchronizes to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network.
> NEW
> A mote wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on is implementation-specific. Once it has received one or more EBs, the new node enables the TSCH mode and uses the ASN and the other timing information of the EB to synchronize to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network.
> 
> ---
> 
> Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1-byte join priority. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in <xref target="sec_channel_hopping" />, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies.
> NEW
> Motes already part of the network can periodically send Enhanced Beacon (EB) frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing mote is listening on, and a 1-byte join priority. The join priority field gives information to make a better decision of which node to join. Even if a node is configured to send all EB frames on the same channel offset, because of the channel hopping nature of TSCH described in <xref target="sec_channel_hopping" />, this channel offset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies.
> 

-- 
Luigi Alfredo Grieco, PhD 
Assistant Professor
Dep. of Electrical and Information Engineering (DEI)
Politecnico di Bari
Via Orabona, 4
70125 - Bari - Italy
Phone: +39 080 5963 911
url: telematics.poliba.it
mail: [email-masked]

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 24 Oct 2014 10:08:47 +0000

+1 for me too.
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: Friday, October 24, 2014 5:08 AM
To: Kris Pister
Cc: [email-masked]
Subject: Re: [6tisch] proposed rewording for last 2 issues draft-ietf-6tisch-tsch

+1 too!
X

2014-10-24 1:01 GMT+02:00 Kris Pister <[email-masked]<mailto:[email-masked]>>:
+1

ksjp

Thomas

---

OLD

---

OLD

6tisch mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: A Paventhan <[email-masked]>
Date: Fri, 24 Oct 2014 15:45:38 +0530

+1

Paventhan

On Fri, Oct 24, 2014 at 3:38 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  +1 for me too.
>
> Maria Rita
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* Friday, October 24, 2014 5:08 AM
> *To:* Kris Pister
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] proposed rewording for last 2 issues
> draft-ietf-6tisch-tsch
>
>
>
> +1 too!
>
> X
>
>
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 24 Oct 2014 09:41:00 -0400

Hi Thomas:

Quick note: I think the text on TSCH mode and join priorities is not 
entirely right (see my earlier emails of around two weeks ago).

I intended to participate in the 6TiSCH conf call today, October 24, 
2014, but have a personal emergency to deal with - my apologies.

I will catch up when back at my desk in the next ~ 2-3 days.

Best regards, Rene

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

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Fri, 24 Oct 2014 13:43:55 +0000

Hello, Thomas.
The paragraph starts discussing a "mote" then switches to use the term "node".
May I suggest using same terminology throughout?
Regards,
Pat

Thomas

---

OLD

---

OLD

6tisch mailing list

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: "Timothy J. Salo" <[email-masked]>
Date: Fri, 24 Oct 2014 09:35:31 -0500

On 10/24/2014 8:43 AM, Brett, Patricia (PA62) wrote:
> The paragraph starts discussing a “mote” then switches to use the term
> “node”.
>

I suggest "node".  For me, "mote" has connotations of a particular
class of hardware implementations.  I think that a protocol
standard ought to use a more generic term, namely "node".

Besides, ten years from now, the term "node" will still be in
widespread usage.

-tjs

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 24 Oct 2014 08:01:48 -0700

Pat, Timothy,

Both "mote" and "node" and used in the draft, I agree we should pick a term
and stick with it. I created http://tools.ietf.org/wg/6tisch/trac/ticket/29
to track.

We have settle on "node" in
https://tools.ietf.org/html/draft-ietf-6tisch-terminology-02, so I agree to
use that. I'll bring this up on the call today.

@all, please chime in if you have any opinion one way or another.

Thanks,
Thomas

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Oct 2014 11:14:46 -0400

Thomas Watteyne <[email-masked]> wrote:
    > Both "mote" and "node" and used in the draft, I agree we should pick a
    > term and stick with it. I created
    > http://tools.ietf.org/wg/6tisch/trac/ticket/29 to track.

    > https://tools.ietf.org/html/draft-ietf-6tisch-terminology-02, so I
    > agree to use that. I'll bring this up on the call today.

I will agree to using the word "node", but I feel it does not adequately make
it clear that it's an LLN node (vs some machine on the internet which might
communicate with the LLN), where the word "mote" is much clearer to people
outside the LLN community.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 26 Oct 2014 14:08:48 -0700

Michael,

Thanks for the remark.

Also per the agreement during our discussion on Friday, I plan on doing the
following:
- use the term "node" in the text, BUT
- add the paragraph at the beginning. Suggested text:

   IEEE802.15.4e has been designed for low-power constrained devices,
   often called "motes".  Several terms are used in the IETF to refer to
   those devices, including "LLN nodes" [RFC7102] and "constrained
   nodes" [RFC7228].  In this document, we use the generic (and shorter)
   term "node", used as a synonym for "LLN node", "constrained node" or
   "mote".

Thomas