Subject: Re: [6tisch] Draft terminology

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 1 Jul 2014 11:42:09 +0000

Thanks Kazu and Thomas.
I am fine with the rewording proposed by Thomas.
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Tuesday, July 01, 2014 1:24 AM
To: Kazushi Muraoka
Cc: Maria Rita PALATTELLA; [email-masked]; Pascal Thubert (pthubert); Patrick Wetterwald (pwetterw)
Subject: Re: [6tisch] Draft terminology

Kazu,

Good catch! Absolutely, it's not because multiple nodes use the same cell that it magically has the "SHARED" IEEE802.15.4e flag set.

I agree with your first definition, but would slightly reword.

To be clear:

  1.  current definition:
A cell that is used by more than one transmitter node at the same time and on the same channelOffset. Only cells with TX flag can be marked as "shared". A backoff algorithm is used to resolve contention
  2.  proposal Kazu:
A cell marked with the “shared” and “TX”. The cell can be used by more than one transmitter node at the same slotOffset and on the same channelOffset. A backoff algorithm is used to resolve contention.
  3.  rewording Thomas:
A cell marked with both the "TX" and “shared” flags. This cell can be used by more than one transmitter node. A backoff algorithm is used to resolve contention. See <xref target="I-D.ietf-6tisch-tsch"/>.
Thoughts? Please add to the list.

Thomas

On Mon, Jun 30, 2014 at 4:14 PM, Kazushi Muraoka <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

The definition of shared cell is not clear for me, because a cell which is used by more than one node may not be marked as “shared”.

For example, a node can use a cell which is being used by another node, when the former node is out of the interference range of the latter node’s transmission (i.e. spatial reuse). In this case, “shared” flag of the cell may not be set, but two nodes actually use the same slotOffset and the same channelOffset in a network.

If we think the cell in the above case is different from the “shared cell”, how about the following definition?

1.      Shared Cell: A cell marked as “shared” and “TX”. The cell can be used by more than one transmitter node at the same slotOffset and on the same channelOffset. A backoff algorithm is used to resolve contention.

Or, if we think that the cell in the above case is also the “shared cell”, it’s better to clarify that the “shared” flag is not necessary for the “shared cell”.

2.       Shared Cell: A cell that is used by more than one transmitter node at the same slotOffset and on the same channelOffset. The flag of “shared” is option for the cell. Only cells with TX flag can be marked as "shared". A backoff algorithm is used to resolve contention.

I think the first definition is easy to use and is better. What do you think?

Kazu

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: Monday, June 30, 2014 11:56 AM
To: Maria Rita PALATTELLA
Cc: [email-masked]<mailto:[email-masked]>; Pascal Thubert (pthubert); Patrick Wetterwald (pwetterw)
Subject: Re: [6tisch] Draft terminology

Maria Rita,

Thanks for updating the draft. I've gone through the I-D draft at [1] and made a couple of editorial changes (indentation, obvious typos, updating references, etc) which I already pushed to the repo. I did not change anything to the actual content of the draft

This e-mail is to get consensus from the WG before making changes to this WG doc. At the bottom are a number of proposed rewording and comments.

All, please go over these proposed changes and voice your opinion. If you agree with all, simply +1.

I would like to rev the draft by the 7/4 deadline.

Thomas

[1] https://bitbucket.org/6tisch/draft-ietf-6tisch-terminology/src

---

OLD
6TiSCH: IPv6 over the Timeslotted Channel Hopping (TSCH) mode of IEEE 802.15.4e. It defines a set of IETF sublayers and protocols (in particular, for setting up a schedule with a centralized or distributed approach, managing the resource allocation), as well as the architecture to bind them together, for use in IPv6 TSCH based networks.
NEW
6TiSCH: IPv6 over the Timeslotted Channel Hopping (TSCH) mode of IEEE 802.15.4e. It defines the 6top sublayer and a set of protocols (in particular, for setting up a schedule with a centralized or distributed approach, managing the resource allocation), as well as the architecture to bind them together, for use in IPv6 TSCH based networks.

COMMENT
"where QoS and RED"
RED needs to be spelled out, with a possible reference to an RFC

OLD
6top: 6top is the adaptation layer between TSCH and upper layers like 6LoWPAN and RPL
NEW
6top: 6top is the adaptation sublayer between TSCH and upper layers like 6LoWPAN and RPL

OLD
6top Data Convey Model: Model describing how the 6top adaptation layer feeds the data flow coming from upper layers into TSCH. It is composed by an I-MUX module, a MUX module, a set of priority queues, and a PDU (Payload Data Unit).
NEW
6top Data Convey Model: Model describing how the 6top adaptation layer feeds the data flow coming from upper layers into TSCH. It is composed by an I-MUX module, a MUX module, a set of priority queues, and a PDU (Payload Data Unit). See <xref target="I-D.wang-6tisch-6top-sublayer"/>.

OLD
ASN: Absolute Slot Number, the timeslot counter, incremented by one at each timeslot. It is wide enough to not roll over in practice. See <xref target="IEEE802154e"/>.
NEW
ASN: Absolute Slot Number, the total number of timeslots that has elapsed since the start of the network or an arbitrary start time. It is wide enough to not roll over in practice. See <xref target="I-D.ietf-6tisch-tsch"/>.

COMMENT
"it is an LBR and also a NEAR"
NEAR needs to be spelled out, with a possible reference to an RFC

COMMENT
"Given the length of the slotframe, the size of the bundle translates directly into bandwidth, either logical, or physical."
I don't understand the "either logical, or physical" part, and suggest to remove.

OLD
EB: Enhanced Beacon frame used by an advertising node to announce the presence of the network. It contains information about the timeslot length, the current ASN value, the slotframes and timeslots the beaconing mote is listening on, and a 1-byte join priority (i.e., number of hops separating the node sending the EB, and the PAN coordinator).
NEW
EB: Enhanced Beacon frame used by a node to announce the presence of the network. It contains information about the timeslot length, the current ASN value, the slotframes and timeslots the beaconing mote is listening on, and a 1-byte join priority (i.e., number of hops separating the node sending the EB, and the PAN coordinator).

OLD
Hopping Sequence: Sequence of frequencies, identified by a Hopping_Sequence_ID, used for channel hopping, when translating the channel offset value into a frequency (i.e., PHY channel). See <xref target="I-D.ietf-6tisch-tsch"/>.
NEW
Hopping Sequence: Ordered sequence of frequencies, identified by a Hopping_Sequence_ID, used for channel hopping, when translating the channel offset value into a frequency (i.e., PHY channel). See <xref target="I-D.ietf-6tisch-tsch"/>.

OLD
IE: Information Elements, a list of Type-Length-Value containers placed at the end of the MAC header, used to pass data between layers or devices. A small number of types are defined by TSCH, but a range of types is available for extensions, and thus, is exploitable by 6TiSCH. See <xref target="IEEE802154e"/>.
NEW
IE: Information Elements, a list of Type-Length-Value containers placed at the end of the MAC header, used to pass data between layers or devices. A small number of types are defined by <xref target="IEEE802154e"/>, but a range of types is available for extensions, and thus, is exploitable by 6TiSCH. See <xref target="IEEE802154e"/>.

OLD
I-MUX module: Inverse-Multiplexer, a classifier that receives 6LoWPAN frames and places them into priority queues.
NEW
I-MUX module: Inverse-Multiplexer, a classifier that receives 6LoWPAN frames and places them into priority queues. See <xref target="I-D.wang-6tisch-6top-sublayer"/>.

OLD
Link: A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Thus, the IETF parlance for the term "Link" is adopted, as opposed to the <!--incompatible --> IEEE802.15.4e terminology. In the context of the 6TiSCH architecture, which applies to Low Power Lossy Networks (LLNs), an IPv6 subnet is usually not congruent to a single link and techniques such as IPv6 Neighbor Discovery Proxying and Routing Over LLNs are required to achieve reachability within the multilink subnet. A link is distinct from a track. In fact, link local addresses are not expected to be used over a track for end to end communication. Finally, from the Layer 3 perspective (where the inner complexities of TSCH operations are hidden to enable classical IP routing and Forwarding), a single radio interface may be seen as a number of Links with different capabilities for unicast or multicast services.
NEW
Link: A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Thus, the IETF parlance for the term "Link" is adopted, as opposed to the <!--incompatible --> IEEE802.15.4e terminology. In the context of the 6TiSCH architecture, which applies to Low Power Lossy Networks (LLNs), an IPv6 subnet is usually not congruent to a single link and techniques such as IPv6 Neighbor Discovery Proxying are used to achieve reachability within the multilink subnet. A link is distinct from a track. In fact, link local addresses are not expected to be used over a track for end to end communication. Finally, from the Layer 3 perspective (where the inner complexities of TSCH operations are hidden to enable classical IP routing and Forwarding), a single radio interface may be seen as a number of Links with different capabilities for unicast or multicast services.

OLD
MUX module: Multiplexer, the entity that dequeues frames from priority queues and associates them to a cell for transmission.
NEW
MUX module: Multiplexer, the entity that dequeues frames from priority queues and associates them to a cell for transmission. See <xref target="I-D.wang-6tisch-6top-sublayer"/>.

OLD
PANA: Protocol for carrying Authentication for Network Access, as defined in <xref target="RFC5191"/> . It is the protocol used in the 6TiSCH architecture for handling authentication during the join process.
NEW
PANA: Protocol for carrying Authentication for Network Access, as defined in <xref target="RFC5191"/> .

COMMENT
It looks like all the functionality of the NME is encompassed in the PCE. Maybe remove NME?

OLD
Shared Cell: A cell that is used by more than one transmitter node at the same time and on the same channelOffset. Only cells with TX flag can be marked as "shared". A backoff algorithm is used to resolve contention.
NEW
Shared Cell: A cell that is used by more than one transmitter node at the same slotOffset and on the same channelOffset. Only cells with TX flag can be marked as "shared". A backoff algorithm is used to resolve contention.

COMMENT
Timeslot: A basic communication unit in TSCH which allows a transmitter node to send a frame to a receiver neighbor, and that receiver neighbor to optionally send back an acknowledgment. The length of the timeslot determines the maximum size of the frame that can be exchanged.
I strongly disagree with the last sentence, and suggest to remove it.

OLD
TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset and a channelOffset. The TSCH schedule contains all the scheduled cells from all slotframes and is sufficient to qualify the communication in the TSCH network. The "width of the matrix is equal to the number of scheduled timeslots in all the concurrent active slotframes. The number of channelOffset values (the "height" of the matrix) is equal to the number of available frequencies.
NEW
TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset and a channelOffset. The TSCH schedule contains all the scheduled cells from all slotframes and is sufficient to qualify the communication in the TSCH network.

On Mon, Jun 30, 2014 at 8:30 AM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,
I have updated the draft according to Patrick’s comments.
Because we didn’t manage to have a specific telco on the terminology (for letting Pascal present the slides he prepared long time ago), I don’t know if you want to publish a new version of the draft.
Being now a WG document, I let the chairs decide.
Thank you!
Maria Rita

From: Patrick Wetterwald (pwetterw) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 20, 2014 11:43 AM
To: Maria Rita PALATTELLA; Thomas Watteyne; Qin Wang; Pascal Thubert (pthubert)
Subject: Draft terminology

Dear draft authors,

I’m late on this action.

Please find my remarks on the terminology draft:

  1.  ASN: We should reference the place where it is defined. In this case the 15.4e standard instead of Thomas’s IETF draft
  2.  Broadcast Cell: A cell does not have a MAC address. The frame that uses the cell has a MAC address.
  3.  Cell: Question: does a cell identified by a slotframehandle? I don’t think so.
  4.  Chunk: It is not within a slot frame but within a CDU.
  5.  I.E. : Same think as 1 (15.4e reference)
  6.  Link: Incompatible seems to be a strong term. I would remove it.
  7.  TSCH schedule: there is a sentence that specify the slot frame size. This sentence has nothing to do here. It is not related to TSH schedule.

Hope this helps.

Many thanks,

Patrick

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Jul 2014 12:04:35 +0000

Dear all:

I have opened issue 18 for this thread.

Maria Rita: we seem to converge here; will you have a chance to apply the changes before Friday?
Ideally, we’d go through the update during the call Friday for a last check and then submit.

Would that be OK with you ?

Cheers,
Pascal

From: Maria Rita PALATTELLA [mailto:[email-masked]]
Sent: mardi 1 juillet 2014 13:42
To: Thomas Watteyne; Kazushi Muraoka
Cc: [email-masked]; Pascal Thubert (pthubert); Patrick Wetterwald (pwetterw)
Subject: RE: [6tisch] Draft terminology

Thanks Kazu and Thomas.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Tuesday, July 01, 2014 1:24 AM
To: Kazushi Muraoka
Cc: Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>; Pascal Thubert (pthubert); Patrick Wetterwald (pwetterw)
Subject: Re: [6tisch] Draft terminology

Kazu,

To be clear:

  1.  current definition:

Thomas

Kazu

Maria Rita,

Thomas

---

OLD

COMMENT
"where QoS and RED"

OLD

OLD

OLD

COMMENT

COMMENT

OLD

OLD

OLD

OLD

OLD

OLD

OLD

COMMENT

OLD

COMMENT

OLD

Dear draft authors,

I’m late on this action.

Hope this helps.

Many thanks,

Patrick

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 2 Jul 2014 20:20:05 +0000

Pascal, sure, I will do my best for updating the document before Friday call.
Regards,
Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Wednesday, July 02, 2014 2:05 PM
To: Maria Rita PALATTELLA; Thomas Watteyne; Kazushi Muraoka
Cc: [email-masked]; Patrick Wetterwald (pwetterw)
Subject: RE: [6tisch] Draft terminology

Dear all:

Cheers,
Pascal

Thanks Kazu and Thomas.

Kazu,

To be clear:

  1.  current definition:

Thomas

Kazu

Maria Rita,

Thomas

---

OLD

COMMENT
"where QoS and RED"

OLD

OLD

OLD

COMMENT

COMMENT

OLD

OLD

OLD

OLD

OLD

OLD

OLD

COMMENT

OLD

COMMENT

OLD

Dear draft authors,

I’m late on this action.

Hope this helps.

Many thanks,

Patrick

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 4 Jul 2014 08:23:52 +0000

Dear Pascal,
I have updated the terminology draft, according to the last suggested (and agreed on the ML) changes. Hopefully I didn’t forget anything.
If you have a chance to double check, let me know if anything is missing and still needed.
Best Regards,
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Maria Rita PALATTELLA
Sent: Wednesday, July 02, 2014 10:20 PM
To: Pascal Thubert (pthubert); Thomas Watteyne; Kazushi Muraoka
Cc: [email-masked]; Patrick Wetterwald (pwetterw)
Subject: Re: [6tisch] Draft terminology

Cc: [email-masked]<mailto:[email-masked]>; Patrick Wetterwald (pwetterw)

Dear all:

Cheers,
Pascal

Thanks Kazu and Thomas.

Kazu,

To be clear:

  1.  current definition:

Thomas

Kazu

Maria Rita,

Thomas

---

OLD

COMMENT
"where QoS and RED"

OLD

OLD

OLD

COMMENT

COMMENT

OLD

OLD

OLD

OLD

OLD

OLD

OLD

COMMENT

OLD

COMMENT

OLD

Dear draft authors,

I’m late on this action.

Hope this helps.

Many thanks,

Patrick