Subject: Re: [6tisch] #18 (terminology): Improve definition of Cell

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 4 Jul 2014 09:01:32 +0000

Dear all,
I have addressed this issue, and in detail, implemented all the changes discussed with Thomas on the ML (as per email below).

Moreover, I have added some references that were missing (as per Thomas' request, and Pascal's suggestion):

COMMENT
 "where QoS and RED".  RED needs to be spelled out, with a possible reference to an RFC
NEW
Quality of Service (QoS) and Random Early Detection (RED) [RFC2309]

COMMENT
 "it is an LBR and also a NEAR" .  NEAR needs to be spelled out, with a possible reference to an RFC
NEW
is an  LBR and also a IPv6 ND-efficiency-aware Router (NEAR) [I-D.chakrabarti-nordmark-6man-efficient-nd].

Finally I have updated the definition of shared cell, as agreed with Thomas and Kazu

OLD
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
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"/>.

Best regards,
Maria Rita

-----Original Message-----
From: 6tisch issue tracker [mailto:[email-masked]] 
Sent: Wednesday, July 02, 2014 1:59 PM
To: Maria Rita PALATTELLA; [email-masked]
Cc: [email-masked]
Subject: Re: [6tisch] #18 (terminology): Improve definition of Cell

#18: Improve definition of Cell

Comment (by [email-masked]):

 Maria Rita,
 Thanks for going through the list. I agree with all your comments.
 Thomas

 On Mon, Jun 30, 2014 at 2:03 PM, Maria Rita PALATTELLA <maria-  [email-masked]> wrote:
 Thomas, many thanks for having gone through all the definitions, and fixed  all the details. I mainly agree on almost all your suggested changes.
 Please find inline some few comments.
 Thank you!
 Maria Rita

 From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas  Watteyne
 Sent: Monday, June 30, 2014 8:56 PM
 To: Maria Rita PALATTELLA
 Cc: Patrick Wetterwald (pwetterw); Qin Wang; Pascal Thubert (pthubert);  [email-masked]
 Subject: Re: 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. +1

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

 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 +1

 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"/>.
 +1

 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"/>.
 The reference should be the 15.4e standard (as per Patrick’s suggestion.
 And I do agree with him, given that ASN is defined there).

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

 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. +1

 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). +1

 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"/>. +1

 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"/>. +1

 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"/>. +1

 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. +1

 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"/>. +1

 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"/> . +1

 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.
 +1

 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. +1

 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.
 I think it is important to specify width and height of the matrix.

 On Mon, Jun 30, 2014 at 8:30 AM, Maria Rita PALATTELLA <maria-  [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

-- 
-------------------------------+----------------------------------------
-------------------------------+---
 Reporter:                     |       Owner:  [email-masked]
  [email-masked]           |      Status:  new
     Type:  defect             |   Milestone:  milestone1
 Priority:  major              |     Version:  1.0
Component:  terminology        |  Resolution:
 Severity:  Active WG          |
  Document                     |
 Keywords:  cell               |
-------------------------------+----------------------------------------
-------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/18#comment:1>
6tisch <http://tools.ietf.org/6tisch/>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Jul 2014 10:48:23 +0000

Looks good to me Maria Rita:

Please note that you do not want to reply to issue tracker but rather add a comment on the ticket at http://trac.tools.ietf.org/wg/6tisch/trac/ticket/18
For this particular case I did it on your behalf : )

Cheers,

Pascal

> From: Maria Rita PALATTELLA [mailto:[email-masked]]
> Sent: vendredi 4 juillet 2014 11:02
> To: 6tisch issue tracker; Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: RE: [6tisch] #18 (terminology): Improve definition of Cell
> 
> Dear all,
> I have addressed this issue, and in detail, implemented all the changes
> discussed with Thomas on the ML (as per email below).
> 
>  "where QoS and RED".  RED needs to be spelled out, with a possible
> reference to an RFC NEW Quality of Service (QoS) and Random Early
> Detection (RED) [RFC2309]
> 
> COMMENT
>  "it is an LBR and also a NEAR" .  NEAR needs to be spelled out, with a
> possible reference to an RFC NEW is an  LBR and also a IPv6 ND-efficiency-
> aware Router (NEAR) [I-D.chakrabarti-nordmark-6man-efficient-nd].
> 
> 
> 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 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"/>.
> 
> Best regards,
> Maria Rita
> 
> 
> 
> 
>  Thomas, many thanks for having gone through all the definitions, and fixed
> all the details. I mainly agree on almost all your suggested changes.
>  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.
> 
>  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. +1
> 
>  COMMENT
>  "where QoS and RED"
>  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"/>.
>  +1
> 
>  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"/>.
>  "Given the length of the slotframe, the size of the bundle translates  directly
> into bandwidth, either logical, or physical."
>  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). +1
> 
>  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"/>. +1
> 
>  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"/>. +1
> 
>  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"/>. +1
> 
>  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. +1
> 
>  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"/>. +1
> 
>  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
>  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.
>  +1
> 
> 
>  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.
>  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.
>  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.

---

From: "Patrick Wetterwald (pwetterw)" <[email-masked]>
Date: Fri, 4 Jul 2014 10:57:22 +0000

I still have a question on the chunks.

I may be wrong but for me a chunk is not within a slotframe but within a
CDU.

The slotframe is a notion internal to a node. Chunks are known by all the
nodes.

Let me know if my understanding is wrong or not.

Patrick

On 04/07/14 12:48, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

>Please note that you do not want to reply to issue tracker but rather add
>a comment on the ticket at
>http://trac.tools.ietf.org/wg/6tisch/trac/ticket/18
>> Finally I have updated the definition of shared cell, as agreed with
>>Thomas
>> and Kazu
>> 
>> OLD
>> marked with both the "TX" and ³shared² flags. This cell can be used by
>>more
>>  All, please go over these proposed changes and voice your opinion. If
>>you
>> agree with all, simply +1.
>> 
>>  6top: 6top is the adaptation sublayer between TSCH and upper layers
>>like
>> 6LoWPAN and RPL +1
>> 
>>  OLD
>>  The reference should be the 15.4e standard (as per Patrick¹s
>>suggestion.
>>  I don't understand the "either logical, or physical" part, and suggest
>>to
>> remove. +1
>> 
>>  OLD
>> in <xref target="RFC5191"/> . +1
>> 
>> 
>>  COMMENT
>>  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
>> Ticket URL: 
>><http://trac.tools.ietf.org/wg/6tisch/trac/ticket/18#comment:1>
>_______________________________________________
>6tisch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6tisch

---

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

Patrick, thanks for having come back to this issue of the chunk definition. 
Actually I have been thinking about again :) and check the definition of CDU, chunk, and slotframe.
And I do agree with you, the chunk is within a CDU, and not within a slotframe. Not only because, as you pointed out, a slotframe is a notion internal to a node, while chunks are known by all the nodes.
But also and mainly because slotframe does not contain any information related to the channels, while chunk does, and this is its main aim.
At the same time, we still need to clarify the relationship between chunk and slotframe, because all the cells belonging to a chunk should belong to the same slotframe.
If we agree on all that, I would suggest to keep the definition of CDU and slotframe as they are in the current version, and update the definition of chunk as below:
Regards,
Maria Rita

OLD
Chunk:      A well-known list of cells, well-distributed in time and
               frequency, within a slotframe; a chunk represents a
               portion of a slotframe that is globally known by all the
               nodes in the network, but it can be managed separately by
               a single node.  A node can have multiple chunks, and use
               them according to a specific policy.  Chunks may overlap.
               They can be pre-programmed, or can be computed by an
               external entity at the network bootstrap.
NEW
Chunk:      A well-known list of cells, well-distributed in time and
               frequency, within a CDU; a chunk represents a
               portion of a CDU, slotframe that is globally known by all the
               nodes in the network, but it can be managed separately by
               a single node.  A node can have multiple chunks, EACH OF THEM BELONGING to a GIVEN SLOTFRAME, and use
               them according to a specific policy.  Chunks may overlap.
               They can be pre-programmed, or can be computed by an
               external entity at the network bootstrap.

  Channel distribution/usage (CDU) matrix:  : Matrix of height equal to
               the number of available channels (i.e, ChannelOffsets),
               representing the spectrum (channel) distribution among
               the different (RPL parent) nodes in the networks.  Every
               single element of the matrix belongs to a specific chunk.
               It has to be noticed that such matrix, even though it
               includes all the cells grouped in chunks, belonging to
               different slotframes, is different from the TSCH
               schedule.

Slotframe:  A MAC-level abstraction that is internal to the node and
               contains a series of timeslots of equal length and
               priority.  It is characterized by a slotframe_ID, and a
               slotframe_size.  Multiple slotframes can coexist in a
               node's schedule, i.e., a node can have multiple
               activities scheduled in different slotframes, based on
               the priority of its packets/traffic flows.  The timeslots
               in the Slotframe are indexed by the SlotOffset; the first
               timeslot is at SlotOffset 0.

-----Original Message-----
From: Patrick Wetterwald (pwetterw) [mailto:[email-masked]] 
Sent: Friday, July 04, 2014 12:57 PM
To: Pascal Thubert (pthubert); Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] #18 (terminology): Improve definition of Cell

I may be wrong but for me a chunk is not within a slotframe but within a CDU.

The slotframe is a notion internal to a node. Chunks are known by all the nodes.

Patrick

On 04/07/14 12:48, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

>Please note that you do not want to reply to issue tracker but rather 
>add a comment on the ticket at
>> I have addressed this issue, and in detail, implemented all the 
>> changes discussed with Thomas on the ML (as per email below).
>> 
>>  "it is an LBR and also a NEAR" .  NEAR needs to be spelled out, with 
>>a  possible reference to an RFC NEW is an  LBR and also a IPv6
>>ND-efficiency-
>>Thomas  and Kazu
>> 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 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"/>.
>> 
>> Best regards,
>> Maria Rita
>> 
>> 
>> 
>> 
>>  Thomas, many thanks for having gone through all the definitions, and 
>>fixed  all the details. I mainly agree on almost all your suggested 
>>changes.
>>  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.
>> 
>>  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. +1
>> 
>>  COMMENT
>>  "where QoS and RED"
>>like  6LoWPAN and RPL +1
>>  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"/>.
>>  +1
>> 
>>  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"/>.
>>  "Given the length of the slotframe, the size of the bundle 
>>translates directly  into bandwidth, either logical, or physical."
>>  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
>>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). +1
>> 
>>  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.
>>  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"/>. +1
>> 
>>  OLD
>>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
>>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. +1
>> 
>>  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-
>>  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
>>  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.
>>  +1
>> 
>> 
>>  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.
>>  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.
>>(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.
>> -------------------------------+-------------------------------------
>> -------------------------------+-------------------------------------

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 4 Jul 2014 16:04:41 +0000

Dear all,
This is the new definition of chunk and CDU I suggest to update in the draft:

Chunk:      A well-known list of cells, well-distributed in time and
               frequency, within a CDU matrix; a chunk represents a
               portion of a CDU matrix that is globally known by all the
               nodes in the network, but it can be managed separately by
               a single node.  A node can have multiple chunks, and use
               them according to a specific policy.  Chunks may overlap.
               They can be pre-programmed, or can be computed by an
               external entity at the network bootstrap.

  Channel distribution/usage (CDU) matrix:  : Matrix of height equal to
               the number of available channels (i.e, ChannelOffsets), and width equal to the slotframesize,
               representing the spectrum (channel) distribution among
               the different (RPL parent) nodes in the networks.  Every
               single element of the matrix belongs to a specific chunk.
               It has to be noticed that such matrix, even though it
               includes all the cells grouped in chunks, belonging to
               a given slotframe, is different from the TSCH
               schedule.

@Pascal: please, let me know if you are happy with that :)

Thanks!
Maria Rita

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Maria Rita PALATTELLA
Sent: Friday, July 04, 2014 3:13 PM
To: Patrick Wetterwald (pwetterw); Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [6tisch] #18 (terminology): Improve definition of Cell

OLD

-----Original Message-----
From: Patrick Wetterwald (pwetterw) [mailto:[email-masked]]
Sent: Friday, July 04, 2014 12:57 PM
To: Pascal Thubert (pthubert); Maria Rita PALATTELLA
Cc: [email-masked]
Subject: Re: [6tisch] #18 (terminology): Improve definition of Cell

Patrick

On 04/07/14 12:48, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

>>defined  in <xref target="RFC5191"/> . +1
>> 
>> 
>>  COMMENT

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Jul 2014 16:59:24 +0000

Hello Maria Rita:

What about

               nodes in the network, with typically at most one cell per

                slotOffset for single radio devices.

               Once appropriated, a chunk can be managed separately by

               a single node within its interference domain.

                A node may appropriate multiple chunks, and use

Happy with the CDU

: )

Cheers,

Pascal

> Sent: vendredi 4 juillet 2014 18:05

> To: Maria Rita PALATTELLA; Patrick Wetterwald (pwetterw); Pascal Thubert

> (pthubert)

>                the number of available channels (i.e, ChannelOffsets), and width

>                equal to the slotframesize,

> From: 6tisch [mailto:[email-masked]] On Behalf Of Maria Rita

> PALATTELLA

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

> Actually I have been thinking about again :) and check the definition of CDU,

> chunk, and slotframe.

> And I do agree with you, the chunk is within a CDU, and not within a

> slotframe. Not only because, as you pointed out, a slotframe is a notion

> internal to a node, while chunks are known by all the nodes.

> But also and mainly because slotframe does not contain any information

> related to the channels, while chunk does, and this is its main aim.

> At the same time, we still need to clarify the relationship between chunk

> and slotframe, because all the cells belonging to a chunk should belong to

> the same slotframe.

> If we agree on all that, I would suggest to keep the definition of CDU and

> slotframe as they are in the current version, and update the definition of

> chunk as below:

>                a single node.  A node can have multiple chunks, EACH OF THEM

> BELONGING to a GIVEN SLOTFRAME, and use

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

> On 04/07/14 12:48, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>

> wrote:

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

> >> Moreover, I have added some references that were missing (as per

> Thomas'

> >> request, and Pascal's suggestion):

> >> To: Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>

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

> >> Comment (by [email-masked]<mailto:[email-masked]>):

> >>  On Mon, Jun 30, 2014 at 2:03 PM, Maria Rita PALATTELLA <maria-

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

> >>  From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of

> >> Thomas  Watteyne

> >>  Cc: Patrick Wetterwald (pwetterw); Qin Wang; Pascal Thubert

> >> (pthubert); [email-masked]<mailto:[email-masked]>

> >>  All, please go over these proposed changes and voice your opinion.

> >>If you  agree with all, simply +1.

> >>  6top: 6top is the adaptation layer between TSCH and upper layers

> >>like  6LoWPAN and RPL  NEW

> >>  I don't understand the "either logical, or physical" part, and

> >>suggest to  remove. +1

> >>channel offset value into a frequency (i.e., PHY channel). See <xref

> >>channel offset value into a frequency (i.e., PHY channel). See <xref

> >>communicate  at the link layer, i.e., the layer immediately below IP.

> >>Thus, the

> >>communicate  at the link layer, i.e., the layer immediately below IP.

> >>Thus, the

> >>  It looks like all the functionality of the NME is encompassed in the

> >>PCE.

> >>  I strongly disagree with the last sentence, and suggest to remove it.

> >>  On Mon, Jun 30, 2014 at 8:30 AM, Maria Rita PALATTELLA <maria-

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

> >>  Reporter:                     |       Owner:

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

> >>   [email-masked]<mailto:[email-masked]>           |      Status:  new

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

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

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 4 Jul 2014 19:25:51 +0000

Fine also with me, thanks Pascal!
Have just updated the draft, and I am going to submit it.
Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Friday, July 04, 2014 6:59 PM
To: Maria Rita PALATTELLA; Patrick Wetterwald (pwetterw)
Cc: [email-masked]
Subject: RE: [6tisch] #18 (terminology): Improve definition of Cell

Hello Maria Rita:

What about

Happy with the CDU

: )

Cheers,

Pascal