Subject: [6tisch] Jonathan's review on draft-ietf-6tisch-6top-interface-01

From: Jonathan Simon <[email-masked]>
Date: Fri, 24 Oct 2014 17:31:33 -0700

Finally got around to reviewing this.  Better late than never?

p2 - odd sentence “This document also defines a list commands internal to the 6top sublayer.”

p5 - CellType option is mandatory (2.1), but it seems to also be implicit in how the cell is created (2.1.1 & 2.1.2). Does MUST in these sections mean that this option must be set explicitly? 

p7 - what does unicast (resp.broadcast) mean?

p9 - channelOffset should be 16-bit (per 802.15.4e-2012 table 52d)

p13 & 14 - the metrics listed do not correspond to those defined in 802.15.4e-2012 table 4i.    PDR, ETX, RSSI and LQI are not used in TSCH or macMetrics descriptions.
- 4e defines a counter size, macCounterOctets, that needs to be specified by 6top - could be a fixed value or set via YANG.
- “Window” measurement period is specified in "Number of the slotframe size” - Does “Number” here mean multiples? what if metrics apply to all slotframes?

p15 - “Peroid” instead of period.  
- CellID - cell ID’s are local to a particular slotframe, so this is meaningless without a slotframe ID
- If the period is in seconds, and the cell repeat rate is not, how is this supposed to work?

p 17 - why is last comms ASN being stored?

general questions/comments:

* Are all things in the YANG model required?  For example, must one support reading the READ.timesource for minTimeCorrection? Must all nodes support chunks, and tracks, and softcells, labelSwitching, or is this policy?
* Are all things in the YANG model expected to be encoded and sent over the air?
* There is no mechanism to specify additional IEs in an EB - is this outside of YANG?
* There’s no way to set the PANID.

* Certain PIBs must be set in a generic 15.4e MAC to get TSCH behavior. I don’t know if these are needed in YANG, but need to be in 6TiSCH:
** some Table 52n on EBs entries need to be set
** Table 60 macFrameCounterMode needs to be 5 octets for ASN to work
** The fields needed to form the IEs contained in the EB are specified, but whether they are sent explicitly or by ID isn’t defined
** macTSCHcapable, and macTSCHEnabled, macMetricsCapable, macMetricsEnabled, aren’t discussed.
** There is no explicit configuration of EBs (e.g. macUseEnhancedBeacon) at the MAC or a discussion of MLME-BEACON.request.
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

**LINEAR TECHNOLOGY CORPORATION** 
*****Internet Email Confidentiality Notice***** 
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: Xavier Vilajosana <[email-masked]>
Date: Sat, 25 Oct 2014 08:31:01 +0200

Dear Jonathan,

Thanks for your comments!  See inline my answers and I will move forward to
address some of your comments on the current draft.

---------

p2 - odd sentence “This document also defines a list commands internal to
the 6top sublayer.”

thanks I'll reword it.

p5 - CellType option is mandatory (2.1), but it seems to also be implicit
in how the cell is created (2.1.1 & 2.1.2). Does MUST in these sections
mean that this option must be set explicitly?

CellType is the way to indicate if the cell to be created is Hard or Soft.
This field is mandatory to create a cell and thus we considered it to be
explicit. However, as you say, let us consider if CellType might be
inferred from context as the procedure to create a Hard Cell and a Soft
Cell is different.

p7 - what does unicast (resp.broadcast) mean?
queues may be organized in different manners, here we indicate that there
might be queues for packets to be sent to an specific neighbor (unicast) or
packets to be broadcasted. Different queues might be used for unicast
packets for example when we have different tracks where one ore more queues
are mapped to the packets that flow on that track.

thanks, we correct that.

p13 & 14 - the metrics listed do not correspond to those defined in
802.15.4e-2012 table 4i.    PDR, ETX, RSSI and LQI are not used in TSCH or
macMetrics descriptions.
OK, here we thought top down, i.e what would be good for the upper layer to
have. THis information can be computed at 6top or obtained from the
LMAC/radio. RPL might be interested on that information.

- 4e defines a counter size, macCounterOctets, that needs to be specified
by 6top - could be a fixed value or set via YANG.

We will add this field.

- “Window” measurement period is specified in "Number of the slotframe
size” - Does “Number” here mean multiples? what if metrics apply to all
slotframes?
This is thought to be a running window with a certain size. The comment is
wrong and has a weak meaning. We wanted to indicate number of slots that
form the window. Per your comments this should be extended to:

1- number of slotframes that form the window
2- All (all slotframes during mac lifetime)
3- number of slots that form the window (small windows)

so in conclusion windows should be configurable and be of one of these
types.

p15 - “Peroid” instead of period.
- CellID - cell ID’s are local to a particular slotframe, so this is
meaningless without a slotframe ID
you are right, we will add slotframeId as a primary key.

- If the period is in seconds, and the cell repeat rate is not, how is this
supposed to work?

good point. We thought EBs are sent periodically. If not then Period field
do not apply. Note however that every entry in the EBList represents a cell
where an EB is sent. Do you think that during the lifetime of a TSCH
network that cell will not be used more than once to send an EB? If it is
used more than once there is a period and an expiration date.
If not we need to think what is the best way to express cells in particular
slots within slotframes. Maybe indicating ASN?

p 17 - why is last comms ASN being stored?
we thought it as a timestamp to know when the last communication occurred.
this might be used to force Keep Alive or to remove neighbors from the
neighbor table. DO you see a better approach?

* Are all things in the YANG model required?  For example, must one support
reading the READ.timesource for minTimeCorrection? Must all nodes support
chunks, and tracks, and softcells, labelSwitching, or is this policy?
This is policy. Here we define all the DATA model.

* Are all things in the YANG model expected to be encoded and sent over the
air?
This is not decided yet. In principle this are configurable elements taht
eventually need to be installed in a node. If this is done over the air,
some of them are pre-configured is a thing we need to decide.

* There is no mechanism to specify additional IEs in an EB - is this
outside of YANG?
We need to discuss about that. It is a good point.

We will add it. thanks!

* Certain PIBs must be set in a generic 15.4e MAC to get TSCH behavior. I
don’t know if these are needed in YANG, but need to be in 6TiSCH:
** some Table 52n on EBs entries need to be set
** Table 60 macFrameCounterMode needs to be 5 octets for ASN to work
** The fields needed to form the IEs contained in the EB are specified, but
whether they are sent explicitly or by ID isn’t defined
** macTSCHcapable, and macTSCHEnabled, macMetricsCapable,
macMetricsEnabled, aren’t discussed.
** There is no explicit configuration of EBs (e.g. macUseEnhancedBeacon) at
the MAC or a discussion of MLME-BEACON.request.

THis are 15.4e specific fields. 6tisch (6top) should provide delegation
interface so upper layers can configure these fields. Not sure thought that
they need to be part of the YANG Model.

2014-10-25 2:31 GMT+02:00 Jonathan Simon <[email-masked]>:

> p5 - CellType option is mandatory (2.1), but it seems to also be implicit
> in how the cell is created (2.1.1 & 2.1.2). Does MUST in these sections
> mean that this option must be set explicitly?
>
> p13 & 14 - the metrics listed do not correspond to those defined in
> 802.15.4e-2012 table 4i.    PDR, ETX, RSSI and LQI are not used in TSCH or
> macMetrics descriptions.
> - 4e defines a counter size, macCounterOctets, that needs to be specified
> by 6top - could be a fixed value or set via YANG.
> - “Window” measurement period is specified in "Number of the slotframe
> size” - Does “Number” here mean multiples? what if metrics apply to all
> slotframes?
>
> * Are all things in the YANG model required?  For example, must one
> support reading the READ.timesource for minTimeCorrection? Must all nodes
> support chunks, and tracks, and softcells, labelSwitching, or is this
> policy?
> * Certain PIBs must be set in a generic 15.4e MAC to get TSCH behavior. I
> don’t know if these are needed in YANG, but need to be in 6TiSCH:
> ** The fields needed to form the IEs contained in the EB are specified,
> but whether they are sent explicitly or by ID isn’t defined
> ** There is no explicit configuration of EBs (e.g. macUseEnhancedBeacon)
> at the MAC or a discussion of MLME-BEACON.request.
> --
> Jonathan Simon, Ph. D
>  This e-mail transmission, and any documents, files or previous
> e-mail messages attached to it may contain confidential information that
> is legally privileged. If you are not the intended recipient, or a
> person responsible for delivering it to the intended recipient, you are
> hereby notified that any disclosure, copying, distribution or use of any of
> the information contained in or attached to this transmission is
> STRICTLY PROHIBITED. If you have received this transmission in error,
> please immediately notify me by reply e-mail, or by telephone at (510)
> 400-2936, and destroy the original transmission and its
> attachments without reading or saving in any manner. Thank you.
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 26 Oct 2014 11:06:34 -0700

Jonathan,
Thanks for the super detailed review

Xavi,
Congratulatsion on the uber-quick action!

I'd like to further some of these points:

> This is policy. Here we define all the DATA model.

This is a larger discussion, I'll start a new thread.

> some of them are pre-configured is a thing we need to decide.

In my mind, the YANG model is a formal description of all the resources one
can access over the air. We are defining two mechanisms which translate the
YANG model into actual bits and bytes: draft-ietf-6tisch-coap allows remote
control, draft-wang-6tisch-6top-coapie allows neighbor to neighbor control.

Thoughts?

Thomas

On Fri, Oct 24, 2014 at 11:31 PM, Xavier Vilajosana <
[email-masked]> wrote:

> Dear Jonathan,
>
> Thanks for your comments!  See inline my answers and I will move forward
> to address some of your comments on the current draft.
>
> ---------
> OK, here we thought top down, i.e what would be good for the upper layer
> to have. THis information can be computed at 6top or obtained from the
> If not we need to think what is the best way to express cells in
> particular slots within slotframes. Maybe indicating ASN?
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 26 Oct 2014 19:00:16 +0000

Pascal

Le 26 oct. 2014 à 19:07, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> a écrit :

Jonathan,

Xavi,

* Are all things in the YANG model expected to be encoded and sent over the air?
This is not decided yet. In principle this are configurable elements taht eventually need to be installed in a node. If this is done over the air, some of them are pre-configured is a thing we need to decide.

In my mind, the YANG model is a formal description of all the resources one can access over the air. We are defining two mechanisms which translate the YANG model into actual bits and bytes: draft-ietf-6tisch-coap allows remote control, draft-wang-6tisch-6top-coapie allows neighbor to neighbor control.

Thoughts?

Same here, though we could define a subset that must be configurable over the air whereas the rest may be...

Pascal

Thomas

On Fri, Oct 24, 2014 at 11:31 PM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Dear Jonathan,

Thanks for your comments!  See inline my answers and I will move forward to address some of your comments on the current draft.

---------

thanks I'll reword it.

CellType is the way to indicate if the cell to be created is Hard or Soft. This field is mandatory to create a cell and thus we considered it to be explicit. However, as you say, let us consider if CellType might be inferred from context as the procedure to create a Hard Cell and a Soft Cell is different.

p7 - what does unicast (resp.broadcast) mean?
queues may be organized in different manners, here we indicate that there might be queues for packets to be sent to an specific neighbor (unicast) or packets to be broadcasted. Different queues might be used for unicast packets for example when we have different tracks where one ore more queues are mapped to the packets that flow on that track.

p13 & 14 - the metrics listed do not correspond to those defined in 802.15.4e-2012 table 4i.    PDR, ETX, RSSI and LQI are not used in TSCH or macMetrics descriptions.
OK, here we thought top down, i.e what would be good for the upper layer to have. THis information can be computed at 6top or obtained from the LMAC/radio. RPL might be interested on that information.

We will add this field.

- “Window” measurement period is specified in "Number of the slotframe size” - Does “Number” here mean multiples? what if metrics apply to all slotframes?
This is thought to be a running window with a certain size. The comment is wrong and has a weak meaning. We wanted to indicate number of slots that form the window. Per your comments this should be extended to:

so in conclusion windows should be configurable and be of one of these types.

good point. We thought EBs are sent periodically. If not then Period field do not apply. Note however that every entry in the EBList represents a cell where an EB is sent. Do you think that during the lifetime of a TSCH network that cell will not be used more than once to send an EB? If it is used more than once there is a period and an expiration date.
If not we need to think what is the best way to express cells in particular slots within slotframes. Maybe indicating ASN?

p 17 - why is last comms ASN being stored?
we thought it as a timestamp to know when the last communication occurred. this might be used to force Keep Alive or to remove neighbors from the neighbor table. DO you see a better approach?

* Are all things in the YANG model expected to be encoded and sent over the air?
This is not decided yet. In principle this are configurable elements taht eventually need to be installed in a node. If this is done over the air, some of them are pre-configured is a thing we need to decide.

THis are 15.4e specific fields. 6tisch (6top) should provide delegation interface so upper layers can configure these fields. Not sure thought that they need to be part of the YANG Model.

2014-10-25 2:31 GMT+02:00 Jonathan Simon <[email-masked]<mailto:[email-masked]>>:
Finally got around to reviewing this.  Better late than never?

* Certain PIBs must be set in a generic 15.4e MAC to get TSCH behavior. I don’t know if these are needed in YANG, but need to be in 6TiSCH:
** some Table 52n on EBs entries need to be set
** Table 60 macFrameCounterMode needs to be 5 octets for ASN to work
** The fields needed to form the IEs contained in the EB are specified, but whether they are sent explicitly or by ID isn’t defined
** macTSCHcapable, and macTSCHEnabled, macMetricsCapable, macMetricsEnabled, aren’t discussed.
** There is no explicit configuration of EBs (e.g. macUseEnhancedBeacon) at the MAC or a discussion of MLME-BEACON.request.
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936<tel:%28510%29%20400-2936>
(510) 489-3799<tel:%28510%29%20489-3799> FAX
[email-masked]<mailto:[email-masked]>

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936<tel:%28510%29%20400-2936>, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

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

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

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