Subject: Re: [6tisch] minimal and beyond

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 3 Jun 2014 08:16:43 +0200

Hello,

I want to propose a formal modification to the minimal draft following what
we discussed last week

I propose:
1) minimal will not specify any slotframe size, this will be open and
configurable according to network size, bw requirements, etc..
2) dagroot will advertise the slotframe length in the EB using the
slotframe and link IE as defined in 15.4e
3) the number of active slots per slotframe will be 1
4) this active slot  will have a linkOption bitmap indicating that it is
RX, TX and SHARED (i.e slotted aloha)
5) we opt to do not have a dedicated EB slot in the slotframe, in contrast
we assume EBs will be sent in the slotted aloha slot.

Question: is it correct to assume that an slotframe will not have a
dedicated EB slot?

Opinions?

regards,
X

2014-05-30 17:10 GMT+02:00 Kris Pister <[email-masked]>:

>  quACK
>
> :)
>
> ksjp
>
>
> On 5/30/2014 7:19 AM, Pascal Thubert (pthubert) wrote:
>
>  Hi Kris:
>
>
>
> I agree that the quack exchange is necessary; nodes need to agree on what
> they can do and what they will do.
>
> This is also the essence of the control bits I was alluding to. SNA had
> done that quite well if not a bit chattily with the XID with negotiable and
> non-negotiable fields.
>
> I like the term quack better as long as there are not too many of them : )
>
>
>
> Can we consider that the initial well known key is the first quack?
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Kris Pister
> *Sent:* mardi 27 mai 2014 22:28
> *To:* [email-masked]
> *Subject:* Re: [6tisch] minimal and beyond
>
>
>
> I think that they are both good questions.  I'm reminded of the Far Side
> cartoon
> of the scientist speaking to a duck.
> "Parlez vous Francais?"  <blank stare>
> "Sprechen Sie Deutsch?" <blank stare>
> "Quack?"                         "Quack! Quack quack quack!"
>
> It's important that motes A, B,C know when to give a blank stare, but it's
> also
> useful to have an efficient mechanism to enumerate which protocols are
> supported, much like TLS cipher suite negotiation.  Perhaps something like
> a "client hello" message?
>
> ksjp
>
> On 5/27/2014 12:04 PM, Michael Richardson wrote:
>
>
>
> Thomas Watteyne <[email-masked]> <[email-masked]> wrote:
>
>     > One question this raises is whether/how entities in network discover
>
>     > their capabilities. Do [R2,X,Y,Z] know [R1,A,B,C] only speak minimal?
>
>     > Does X, upon joining, announce "I know about PNP"?
>
>
>
> Again, it's the wrong question.
>
>
>
> The correct question is:
>
>     What does A do when confronted with a schedule that contains schedule
>
>     descriptions which go beyond minimal.  The answer may be "ignore that
>
>     entry", or it be, "return an error to sender".
>
>
>
> X, upon joining, simply speaks "PNP", and may find that "A" says, "huh".
>
>
>
>
>
> --
>
> Michael Richardson <[email-masked]> <[email-masked]>, Sandelman Software Works
>
>  -= IPv6 IoT consulting =-
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> 6tisch mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Qin Wang <[email-masked]>
Date: Tue, 3 Jun 2014 06:44:56 -0700 (PDT)

Hi Xavi,

I'm not sure I understand the item 3). Why is there only one active aloha slot in a slotframe? In addition, I guess the only one aloha slot will not be hard coded, because the device does not know the slotframe size before it receives EB.  

Maybe I missed something.

Thanks
Qin

On Tuesday, June 3, 2014 2:16 PM, Xavier Vilajosana <[email-masked]> wrote:

Hello,
I want to propose a formal modification to the minimal draft following what we discussed last week

I propose:
1) minimal will not specify any slotframe size, this will be open and configurable according to network size, bw requirements, etc..
2) dagroot will advertise the slotframe length in the EB using the slotframe and link IE as defined in 15.4e
3) the number of active slots per slotframe will be 1 
4) this active slot  will have a linkOption bitmap indicating that it is RX, TX and SHARED (i.e slotted aloha)
5) we opt to do not have a dedicated EB slot in the slotframe, in contrast we assume EBs will be sent in the slotted aloha slot.

Question: is it correct to assume that an slotframe will not have a dedicated EB slot?

Opinions?

regards,
X 

quACK 
>>I agree that the quack exchange is necessary; nodes need to agree on what they can do and what they will do.
>>This is also the essence of the control bits I was alluding to. SNA had done that quite well if not a bit chattily with the XID with negotiable and non-negotiable fields.
>>From:6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
>>Sent: mardi 27 mai 2014 22:28
>>To: [email-masked]
>>Subject: Re: [6tisch] minimal and beyond
>> 
>>I think that they are both good questions.  I'm reminded of the Far Side cartoon
>>It's important that motes A, B,C know when to give a blank
            stare, but it's also
>>>Thomas Watteyne <[email-masked]> wrote:
>>>    > One question this raises is whether/how entities in network discover
>>>    > their capabilities. Do [R2,X,Y,Z] know [R1,A,B,C] only speak minimal?
>>>    > Does X, upon joining, announce "I know about PNP"?
>>> 
>>>Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 3 Jun 2014 15:18:39 -0700

An EB could be sent in a single slot slotframe if the link was marked appropriately. 
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(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. 

On Jun 2, 2014, at 11:16 PM, Xavier Vilajosana <[email-masked]> wrote:

>> From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
>> It's important that motes A, B,C know when to give a blank stare, but it's also

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Jun 2014 22:58:25 -0400

> An EB could be sent in a single slot slotframe if the link was marked

Question about the Extended Beacon:  Could it contain an IPv6 RA (with an ABRO) as well?

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 4 Jun 2014 05:09:36 +0200

Hi Qin,

the origiinal idea is that a node not being part of the network will be
listening until it receives an EB, the EB will inform about the slotframe
size and the position of the active cell. The cell will be slotted aloha
marked with the LinkOption bitmap as TX,RX,Shared. I checked also 15.4e
document after Jonathan comment, and I think that as you suggest only one
active cell is *not* *possible* as the cell used to transmit Data packet
needs to be of LinkType = NORMAL while EB cells need to be of LinkType=
ADVERTISEMENT (see page 175 - table 52d)

The conclusion on my side is that we need 2 cells per slotframe, one of
LinkType=NORMAL and the other of LinkType=ADVERTISEMENT.

what bothers me is the overhead of EB cells in the receiver side when we
have short slotframes. Any suggestion to reduce the impact of that?

regards,
Xavi

2014-06-03 15:44 GMT+02:00 Qin Wang <[email-masked]>:

> Hi Xavi,
>
> I'm not sure I understand the item 3). Why is there only one active aloha
> slot in a slotframe? In addition, I guess the only one aloha slot will not
> be hard coded, because the device does not know the slotframe size before
> it receives EB.
>
>   *From:* 6tisch [mailto:[email-masked] <[email-masked]>]
> *On Behalf Of *Kris Pister

---

From: Qin Wang <[email-masked]>
Date: Tue, 3 Jun 2014 21:37:15 -0700 (PDT)

Hi Xavi,

Are you worrying the energy consumption for listening on EB cells while short slotframe is used? 

I think, just like the EB cells from transmitter point of view, it is not "MUST" for receivers to listen on every EB cell. For a in-network node, listening EB is mainly for synchronization. So, maybe a timer (like the timer for KA) can be used to trigger node to start listening on EB cell, and keep listening until it gets an EB.

Does it make sense?

Thanks
Qin

On Wednesday, June 4, 2014 11:09 AM, Xavier Vilajosana <[email-masked]> wrote:

Hi Qin,

the origiinal idea is that a node not being part of the network will be listening until it receives an EB, the EB will inform about the slotframe size and the position of the active cell. The cell will be slotted aloha marked with the LinkOption bitmap as TX,RX,Shared. I checked also 15.4e document after Jonathan comment, and I think that as you suggest only one active cell is not possible as the cell used to transmit Data packet needs to be of LinkType = NORMAL while EB cells need to be of LinkType= ADVERTISEMENT (see page 175 - table 52d)

The conclusion on my side is that we need 2 cells per slotframe, one of LinkType=NORMAL and the other of LinkType=ADVERTISEMENT.

what bothers me is the overhead of EB cells in the receiver side when we have short slotframes. Any suggestion to reduce the impact of that?

regards,
Xavi

Hi Xavi,
            stare, but it's also

---

From: Kris Pister <[email-masked]>
Date: Wed, 04 Jun 2014 09:32:47 -0700

Qin - the reason for a single active slot was to get back to the idea of 
"minimal".
One benefit is that active slots are uniformly spread out in time 
automatically, resolving
that particular email thread.
If we choose to pick a particular active cell (e.g. slot 0, offset 0), 
then everything about the
MAC timing can be hard coded except the slotframe length.

ksjp

On 6/3/2014 6:44 AM, Qin Wang wrote:
> Hi Xavi,
>
> I'm not sure I understand the item 3). Why is there only one active 
> aloha slot in a slotframe? In addition, I guess the only one aloha 
> slot will not be hard coded, because the device does not know the 
> slotframe size before it receives EB.
>
> 5) we opt to do not have a dedicated EB slot in the slotframe, in 
> contrast we assume EBs will be sent in the slotted aloha slot.
>
> 2014-05-30 17:10 GMT+02:00 Kris Pister <[email-masked] 
> <mailto:[email-masked]>>:
>
>     quACK
>
>     :)
>
>     ksjp
>
>
>>     I agree that the quack exchange is necessary; nodes need to agree
>>     on what they can do and what they will do.
>>     This is also the essence of the control bits I was alluding to.
>>     SNA had done that quite well if not a bit chattily with the XID
>>     with negotiable and non-negotiable fields.
>>     *From:*6tisch [mailto:[email-masked]] *On Behalf Of
>>     *Kris Pister
>>     *To:* [email-masked] <mailto:[email-masked]>
>>         Thomas Watteyne<[email-masked]>  <mailto:[email-masked]>  wrote:
>>
>>         Michael Richardson<[email-masked]>  <mailto:[email-masked]>, Sandelman Software Works
>>
>>         [email-masked]  <mailto:[email-masked]>
>>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Jonathan Simon <[email-masked]>
Date: Wed, 4 Jun 2014 09:48:12 -0700

Yes, the Enhanced Beacon can contain any kind of extra information, either encapsulated as an information element (IE) or as raw payload.  The question is whether the AR will fit, given the current content of the EB used for TSCH (synchronization, timeslot template, hopping sequence, slotframe & link).
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

On Jun 3, 2014, at 7:58 PM, Michael Richardson <[email-masked]> wrote:

> http://cp.mcafee.com/d/2DRPos96QmbELfT78LCXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVIw-guZVB_HYOy-yyZRXBQXLnVxxyXXTbnjIyyHuXfaxVZicHs3jq9J4TvAm4TDNOb2pEVdTdAVPmEBC5eBYTu00U9GX33VkDa3JssDaBypJOsGm9BO5mUm-waBYTu00CTTS7PobZ8Qg6BJOsGm9CBQQgaOx9njPh1I43h0gYJm21JB4TDv5

---

From: Kris Pister <[email-masked]>
Date: Wed, 04 Jun 2014 09:52:43 -0700

Xavi, Qin - good points.
In a network with plenty of traffic (e.g. each node generating a packet 
every 5s), there is
no *synchronization* need to listen to EBs, since normal traffic will 
keep the network
synchronized.
For low traffic networks, the energy cost of synchronization via 
keepalives is typically
lower than the cost of listening on every EB slot.
Additionally, from a network formation standpoint, it is undesirable to 
have all nodes
using the same slot for EBs, due to collisions.

One possible solution:
The dodag root chooses a random cell in which to send EBs.  The EB announces
the single-cell slotframe of length L, with an aloha slot at (0,0).
After synchronization, a new node uses that cell for all traffic except 
it's own EBs,
which it sends in a random (static) cell.
As you point out, this does not preclude a child node from listening to 
parent(s) beacons
if it's chooses to do so, but this is not required, or necessary.

Your approach (put the EB RX in your schedule, but only listen based on 
timeout)
is fine too.

ksjp

On 6/3/2014 9:37 PM, Qin Wang wrote:
> I think, just like the EB cells from transmitter point of view, it is 
> not "MUST" for receivers to listen on every EB cell. For a in-network 
> node, listening EB is mainly for synchronization. So, maybe a timer 
> (like the timer for KA) can be used to trigger node to start listening 
> on EB cell, and keep listening until it gets an EB.
>
> Does it make sense?
>
> Thanks
> Qin
>
>
> the origiinal idea is that a node not being part of the network will 
> be listening until it receives an EB, the EB will inform about the 
> slotframe size and the position of the active cell. The cell will be 
> slotted aloha marked with the LinkOption bitmap as TX,RX,Shared. I 
> checked also 15.4e document after Jonathan comment, and I think that 
> as you suggest only one active cell is *not* *possible* as the cell 
> used to transmit Data packet needs to be of LinkType = NORMAL while EB 
> cells need to be of LinkType= ADVERTISEMENT (see page 175 - table 52d)
>
> The conclusion on my side is that we need 2 cells per slotframe, one 
> of LinkType=NORMAL and the other of LinkType=ADVERTISEMENT.
>
> what bothers me is the overhead of EB cells in the receiver side when 
> we have short slotframes. Any suggestion to reduce the impact of that?
>
> regards,
> Xavi
>
>
> 2014-06-03 15:44 GMT+02:00 Qin Wang <[email-masked] 
> <mailto:[email-masked]>>:
>
>     Hi Xavi,
>
>     I'm not sure I understand the item 3). Why is there only one
>     active aloha slot in a slotframe? In addition, I guess the only
>     one aloha slot will not be hard coded, because the device does not
>     know the slotframe size before it receives EB.
>
>     On Tuesday, June 3, 2014 2:16 PM, Xavier Vilajosana
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>     Hello,
>
>     1) minimal will not specify any slotframe size, this will be open
>     and configurable according to network size, bw requirements, etc..
>     4) this active slot  will have a linkOption bitmap indicating that
>     it is RX, TX and SHARED (i.e slotted aloha)
>>         I agree that the quack exchange is necessary; nodes need to
>>         agree on what they can do and what they will do.
>>         This is also the essence of the control bits I was alluding
>>         to. SNA had done that quite well if not a bit chattily with
>>         the XID with negotiable and non-negotiable fields.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Jun 2014 17:39:09 +0000

Hello Kris

I suspect that with one slot per slotframe the minimal will have to live on a slotframe with a different duration than other coexisting industrial processes flows, and that as a result a deterministic timeslots may periodically overlap with an minimal one.

Taking the assumption of time-aligned slots, it would make sense to be able to:

1)      Enforce CCA including energy above threshold for the minimal slot (respecting EN300328 rules for adaptive devices)

2)      use a longer CCA for minimal to leave a better chance for deterministic traffic

What do you think ?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: mercredi 4 juin 2014 09:33
To: Qin Wang; [email-masked]
Subject: Re: [6tisch] minimal and beyond

Qin - the reason for a single active slot was to get back to the idea of "minimal".
One benefit is that active slots are uniformly spread out in time automatically, resolving
that particular email thread.
If we choose to pick a particular active cell (e.g. slot 0, offset 0), then everything about the
MAC timing can be hard coded except the slotframe length.

ksjp

Thanks
Qin

On Tuesday, June 3, 2014 2:16 PM, Xavier Vilajosana <[email-masked]><mailto:[email-masked]> wrote:

Hello,

I propose:

Opinions?

regards,
X

2014-05-30 17:10 GMT+02:00 Kris Pister <[email-masked]<mailto:[email-masked]>>:
quACK

:)

ksjp

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Kris Pister
Sent: mardi 27 mai 2014 22:28
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] minimal and beyond

ksjp

The correct question is:

--

Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works

6tisch mailing list

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

_______________________________________________
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

---

From: Kris Pister <[email-masked]>
Date: Wed, 04 Jun 2014 11:11:38 -0700

I have no (net) opinion on item 1.  There are pluses and minuses.

If item 2 is described in the 15.4 standard and implemented by chip 
vendors, then
we should examine the pluses and minuses of 1 more closely.  If not, 
then it seems
to me that item 2 is out.

ksjp

On 6/4/2014 10:39 AM, Pascal Thubert (pthubert) wrote:
>
> Hello Kris
>
> I suspect that with one slot per slotframe the minimal will have to 
> live on a slotframe with a different duration than other coexisting 
> industrial processes flows, and that as a result a deterministic 
> timeslots may periodically overlap with an minimal one.
>
> 1)Enforce CCA including energy above threshold for the minimal slot 
> (respecting EN300328 rules for adaptive devices)
>
> 2)use a longer CCA for minimal to leave a better chance for 
> deterministic traffic
>
> What do you think ?
>
> Pascal
>
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Kris Pister
> *Sent:* mercredi 4 juin 2014 09:33
> *To:* Qin Wang; [email-masked]
>     <[email-masked]>
>     <mailto:[email-masked]> wrote:
>
>     Hello,
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Sun, 8 Jun 2014 21:27:46 +0200

Dear all,

after friday discussion it seems that having:

1) variable size slotframes and the size being announced in the EBs
2) 1 active cell (slotted aloha) having linkOption set at RX,TX,SHARED
3) The linkType for that cell can be NORMAL and it is not required to be
ADVERTISMENT despite EBs will also be sent on that cell.

I would like to ask if everybody agrees on that approach and whether not
having a dedicated ADV cell but sending EBs in a NORMAL link is possible.

Another minor issue is the location of the active cell in the schedule,
this can be in a fix position (i.e the first cell in the slotframe) or the
cell can be any in the slotframe and this be advertised by the EB (in both
cases will be advertised but in the second case will not be known in
advance as it is not static).

thanks!
Xavi

2014-06-04 20:11 GMT+02:00 Kris Pister <[email-masked]>:

> we should examine the pluses and minuses of 1 more closely.  If not, then
> it seems
> I suspect that with one slot per slotframe the minimal will have to live
> on a slotframe with a different duration than other coexisting industrial
> processes flows, and that as a result a deterministic timeslots may
> periodically overlap with an minimal one.
>
>
>
> 1)      Enforce CCA including energy above threshold for the minimal slot
> <[email-masked]> <[email-masked]> wrote:
>
>
>
>
>
> Hello,
>
>
>

---

From: Jonathan Simon <[email-masked]>
Date: Mon, 9 Jun 2014 17:41:23 -0700

Xavi,

I believe what you say makes perfect sense.

To summarize your proposal (please correct me if I'm wrong), the EB would contain a single slotframe IE, containing itself a single link. That link would be marked with the <TX|RX|SHARED> flags to obtain slotted-Aloha behavior. Note that ADVERTISING flag is strictly speaking part of the macLinkType, not of macLinkOptions, as you can read in Table 52d:

This means that the "ADVERTISING" flags is NOT carried in the EB. Per p.91:

The Link Options field indicates whether this link is a TX link, an RX link, or a SHARED TX link, and
whether the device to which it is being linked is to be used for clock synchronization. The field corresponds
to the Link Options field in the link table for the receiving device. SHARED TX links are used for a joining
device to send an Association Request command or other higher layer message. RX links are used for a
joining device to receive an Association Response command or other higher layer message from an
advertising device (i.e., a device sending Enhanced Beacons with TSCH information). RX links shall have
the Timekeeping linkOptions bit set. It is possible for one link to be used as both SHARED_TX and RX
link.

So, for this to work, you need to add some text in the I-D which indicates that the device, upon receiving the EB, configures the TSCH schedule with the link, and marks it as ADV.

To answer your question, IEEE802.15.4e-2012 specified (see table above) that "ADVERTISING [...] indicates the link may be used to send an enhanced beacon". It does not preclude that other types of packets are sent on that link, so I believe it should be OK.

One final comment about the Timekeeping flag. It is my understanding that 6TiSCH recommends to use the RPL DAG as the synchronization structure. Since all the nodes are sending EBs, the link in all EBs cannot be marked with the Timekeeping flag, or you end up with synchronization chaos (i.e. synchronization loops). What I would recommend is to NOT set the Timekeeping flag, and add some text which explains that the Timekeeping flag is set according to the RPL DAG structure.

I hope this helps,

Jonathan

On Jun 8, 2014, at 12:27 PM, Xavier Vilajosana <[email-masked]> wrote:

> 3) The linkType for that cell can be NORMAL and it is not required to be ADVERTISMENT despite EBs will also be sent on that cell.
> 
> I would like to ask if everybody agrees on that approach and whether not having a dedicated ADV cell but sending EBs in a NORMAL link is possible.
> 
> Another minor issue is the location of the active cell in the schedule, this can be in a fix position (i.e the first cell in the slotframe) or the cell can be any in the slotframe and this be advertised by the EB (in both cases will be advertised but in the second case will not be known in advance as it is not static).
> 
> thanks!
> Xavi
>  
> 
> 
> 
> 
> If item 2 is described in the 15.4 standard and implemented by chip vendors, then
> we should examine the pluses and minuses of 1 more closely.  If not, then it seems
> http://cp.mcafee.com/d/5fHCNEg6jqb5QQTTT1PVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrd7b9EV8c6zBB_HYOMqekkmeLsKCOMZPWrUVMQsYJt6OaaJXKsG7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9CT9OFoCn8lrxrW0GnPtU02rvhsud79I5-Aq83iSVelb4PiWq85pgAHFVEwS21Ew8umH10SOyrPI6vaWI6

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 10 Jun 2014 05:49:36 +0200

Dear Jonathan,

thanks you very much, my worry was about macLinkType field as I had doubts
on how to set it. Now you confirm that the flag MUST be set to ADV as soon
a node receives an EB with information of the link. This also indicates
that all data packets sent by a node will be sent using the only existing
link which will be of macLinkType  ADV.

Thanks for the timekeeping recommendation, I understand the implications
but I have a doubt w,r,t your last sentence

"What I would recommend is to NOT set the *Timekeeping* flag, and add some
text which explains that the *Timekeeping* flag is set according to the RPL
DAG structure."

Assume node A is neighbor of node B ,C  and D and A is time source neighbor
of C  while D is time source neighbor of B, they all share a slotted aloha
slot set as ADV type. Who marks timekeeping in its schedule for that shared
cell? Ideally B would mark timekeeping flag if only it can receive EBs from
D while C would mark timekeeping flag if it can only receive EBs from D. As
this is not the case because everybody can hear everybody, should the
timekeeping flag be set? if so, who sets it? everyone?

I will update the minimal draft with what we have been discussing last
days. Thanks you very much!
X

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

> To summarize your proposal (please correct me if I'm wrong), the EB would
> contain a single slotframe IE, containing itself a single link. That link
> would be marked with the <TX|RX|SHARED> flags to obtain slotted-Aloha
> behavior. Note that ADVERTISING flag is strictly speaking part of the
> *macLinkType*, not of *macLinkOptions*, as you can read in Table 52d:
>
>
>
>> *The Link Options field indicates whether this link is a TX link, an RX
>> link, or a SHARED TX link, andwhether the device to which it is being
>> linked is to be used for clock synchronization. The field correspondsto the
>> Link Options field in the link table for the receiving device. SHARED TX
>> links are used for a joiningdevice to send an Association Request command
>> or other higher layer message. RX links are used for ajoining device to
>> receive an Association Response command or other higher layer message from
>> anadvertising device (i.e., a device sending Enhanced Beacons with TSCH
>> information). RX links shall havethe Timekeeping linkOptions bit set. It is
>> possible for one link to be used as both SHARED_TX and RXlink.*
>
>
> So, for this to work, you need to add some text in the I-D which indicates
> that the device, upon receiving the EB, configures the TSCH schedule with
> the link, and marks it as ADV.
>
> To answer your question, IEEE802.15.4e-2012 specified (see table above)
> that "ADVERTISING [...] indicates the link may be used to send an enhanced
> beacon". It does not preclude that other types of packets are sent on that
> link, so I believe it should be OK.
>
> One final comment about the *Timekeeping* flag. It is my understanding
> that 6TiSCH recommends to use the RPL DAG as the synchronization structure.
> Since all the nodes are sending EBs, the link in all EBs cannot be marked
> with the *Timekeeping* flag, or you end up with synchronization chaos
> (i.e. synchronization loops). What I would recommend is to NOT set the
> *Timekeeping* flag, and add some text which explains that the
> *Timekeeping* flag is set according to the RPL DAG structure.
>
> I hope this helps,
>
> Jonathan
> --
> 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.
>
>> 1)      Enforce CCA including energy above threshold for the minimal
>> slot (respecting EN300328 rules for adaptive devices)
>>
>> https://www.ietf.org/mailman/listinfo/6tisch <http://cp.mcafee.com/d/FZsS91MOrhoKCC--UevdTdEK3CkPqbwVBYSyUed7aar9EVdKfffecnKr4qilH057Ox-NVsSva7X7BPpEVpd791wQsILZvCm3hOyyNRXBQSm7Kvjv7e6zDBHEShhlLtPBgY-F6lK1FJ4SMrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcSVelb4OV2Hsbvg5i-rL00jrWbzNEVdwLQzh0qmT9OFoCqnjh0Ha4Btfd46Mgd413ORo86SkjuSIUTp8O61uj>
>>
>>
>>
>>
>>
>>
>> <http://cp.mcafee.com/d/avndy0Q83hJ5yWqrXXwVYTsSyUepjdEK3CnPqbwUQsEFICzASUYYYUNuVIhF9mI0kva7X7BPpYEvIundCzBAQsA63hOO_R-pod7aab7nKnjpouVZdYsUqeumKzp55mZTel3PWApmU6CQPr1K_8I9LfzAm4PhOrKr9PCJhbcatbVKY01MjlS67OFek7qUVelb4PrAVkIjbAaJMJZ0lbVKY01dLEKf6zAS2_id41FrsDaBypFtd42IEilQYQgr10Qg4fblwwrphdzTvv>
>>
>>
>>
>>
>>
>> <http://cp.mcafee.com/d/1jWVIp4zqb5QQTTT1PVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrd7b9EV8c6zBB_HYOMqekkmeLsKCOMZPWrUVMQsYJt6OaaJXKsG7DR8OJMddICS3t-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9CT9OFoCn8lrxrW0GnPtU02rvhsud79I5-Aq83iSVelb4PiWq85pgAHFVEwS21Ew8umH10SOyrGUi4KAd>
>>
>>
>>
>>
>>
>>
>>
>> <http://cp.mcafee.com/d/k-Kr41Eq6zqb5QQTTT1PVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrd7b9EV8c6zBB_HYOMqekkmeLsKCOMZPWrUVMQsYJt6OaaJXKsG7DR8OJMddI6S3t-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9CT9OFoCn8lrxrW0GnPtU02rvhsud79I5-Aq83iSVelb4PiWq85pgAHFVEwS21Ew8umH10SOyrqA-TEuOBvwxk>
>>
>>

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 9 Jun 2014 22:24:25 -0700

Xavi,

My take on this.

Since any EB can be heard by all the sender's neighbors, setting the ADV
flag in the EB makes little sense, since it would mean that all neighbors
are time source neighbors for all nodes (I hope this sentence makes sense).

Instead, I believe the link announced in the EB should NOT have the
timeKeeping flag set. Instead, "an upper layer" is responsible for marking
the RPL routing parent as also the time source neighbor, so that the timing
structure is the same as the RPL DAG. This is in accordance with the
current minimal draft.

Thomas

On Mon, Jun 9, 2014 at 8:49 PM, Xavier Vilajosana <
[email-masked]> wrote:

> "What I would recommend is to NOT set the *Timekeeping* flag, and add
> some text which explains that the *Timekeeping* flag is set according to
> the RPL DAG structure."
>
> Assume node A is neighbor of node B ,C  and D and A is time source
> neighbor of C  while D is time source neighbor of B, they all share a
> slotted aloha slot set as ADV type. Who marks timekeeping in its schedule
> for that shared cell? Ideally B would mark timekeeping flag if only it can
> receive EBs from D while C would mark timekeeping flag if it can only
> receive EBs from D. As this is not the case because everybody can hear
> everybody, should the timekeeping flag be set? if so, who sets it? everyone?
>
>>> link, or a SHARED TX link, and whether the device to which it is being
>>> links are used for a joining device to send an Association Request command
>>> information). RX links shall have the Timekeeping linkOptions bit set. It
>>> is possible for one link to be used as both SHARED_TX and RXlink.*
>>
>>
>> So, for this to work, you need to add some text in the I-D which
>> indicates that the device, upon receiving the EB, configures the TSCH
>> schedule with the link, and marks it as ADV.
>>
>>> aloha slot in a slotframe? In addition, I guess the only one aloha slot
>>> will not be hard coded, because the device does not know the slotframe size
>>> before it receives EB.
>>>
>>>
>>>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 10 Jun 2014 07:55:00 +0200

Hi Thomas,

see inline

"makes little sense". So you are suggesting to do *not *mark it? Note that
macLinkType is not part of the EB but is a property of a cell in the
schedule. This means that this is not sent, but nodes when receiving the EB
mark the announced cell as either ADV or NORMAL. As for Jonathan email
before, it seems that by marking links as ADV ensures that anything can be
sent on that links (Data and EBs).

I agree with that, so timekeeping flag would never be set.

thanks!
X

2014-06-10 7:24 GMT+02:00 Thomas Watteyne <[email-masked]>:

>> thanks you very much, my worry was about macLinkType field as I had
>> doubts on how to set it. Now you confirm that the flag MUST be set to ADV
>> as soon a node receives an EB with information of the link. This also
>> indicates that all data packets sent by a node will be sent using the only
>> existing link which will be of macLinkType  ADV.
>>
>>> To summarize your proposal (please correct me if I'm wrong), the EB
>>> would contain a single slotframe IE, containing itself a single link. That
>>> link would be marked with the <TX|RX|SHARED> flags to obtain slotted-Aloha
>>>> industrial processes flows, and that as a result a deterministic timeslots
>>>> may periodically overlap with an minimal one.
>>>>
>>>>
>>>>
>>>> *From:* 6tisch [mailto:[email-masked]
>>>> <[email-masked]>] *On Behalf Of *Kris Pister
>>>> *From:* 6tisch [mailto:[email-masked]
>>>> <[email-masked]>] *On Behalf Of *Kris Pister

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 10 Jun 2014 00:17:21 -0700

Xavi,

Oops, that was a typo!! What I mean is:

Since any EB can be heard by all the sender's neighbors, setting the
> *timekeeping* flag in the EB [...]

Thomas

On Mon, Jun 9, 2014 at 10:55 PM, Xavier Vilajosana <
[email-masked]> wrote:

> "makes little sense". So you are suggesting to do *not *mark it? Note
> that macLinkType is not part of the EB but is a property of a cell in the
>>> some text which explains that the *Timekeeping* flag is set according
>>> to the RPL DAG structure."
>>>
>>>>> *The Link Options field indicates whether this link is a TX link, an
>>>>> RX link, or a SHARED TX link, and whether the device to which it is being
>>>> 3) The linkType for that cell can be NORMAL and it is not required to
>>>> be ADVERTISMENT despite EBs will also be sent on that cell.
>>>>
>>>> I would like to ask if everybody agrees on that approach and whether
>>>> not having a dedicated ADV cell but sending EBs in a NORMAL link is
>>>> possible.
>>>>
>>>>> This is also the essence of the control bits I was alluding to. SNA
>>>>> had done that quite well if not a bit chattily with the XID with negotiable
>>>>> and non-negotiable fields.
>>>>>

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 10 Jun 2014 09:20:00 +0200

great, now everything is clear then!
thanks!

2014-06-10 9:17 GMT+02:00 Thomas Watteyne <[email-masked]>:

>>>> Thanks for the timekeeping recommendation, I understand the
>>>> implications but I have a doubt w,r,t your last sentence
>>>>
>>>>> To answer your question, IEEE802.15.4e-2012 specified (see table
>>>>> above) that "ADVERTISING [...] indicates the link may be used to send an
>>>>> enhanced beacon". It does not preclude that other types of packets are sent
>>>>> on that link, so I believe it should be OK.
>>>>>
>>>>> One final comment about the *Timekeeping* flag. It is my
>>>>> understanding that 6TiSCH recommends to use the RPL DAG as the
>>>>> synchronization structure. Since all the nodes are sending EBs, the link in
>>>>> all EBs cannot be marked with the *Timekeeping* flag, or you end up
>>>>> with synchronization chaos (i.e. synchronization loops). What I would
>>>>> recommend is to NOT set the *Timekeeping* flag, and add some text
>>>>> which explains that the *Timekeeping* flag is set according to the
>>>>> RPL DAG structure.
>>>>>
>>>>> I hope this helps,
>>>>>
>>>>> Jonathan
>>>>>   --
>>>>> Jonathan Simon, Ph. D
>>>>> Another minor issue is the location of the active cell in the
>>>>> schedule, this can be in a fix position (i.e the first cell in the
>>>>> slotframe) or the cell can be any in the slotframe and this be advertised
>>>>> by the EB (in both cases will be advertised but in the second case will not
>>>>> be known in advance as it is not static).
>>>>>
>>>>> thanks!
>>>>> Xavi
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 11 Jun 2014 10:39:24 -0700

Xavi,

I'd like to go back to your question about what [slotOffset,channelOffset]
to use for the single cell announced in the EB.

My opinion is that:

   - The single cell MUST be announced using the "Slotframe and link IE" of
   IEEE802.15.4e (Section 5.2.4.14). I see no advantage in defining our own
   formats, or hardcoding what to use.
   - If we agree with the statement above, the "Link Information fields"
   from that IE (Figure 48hh) contains "Timeslot" and "Channel Offset" fields.
   IMO, we could recommend (i.e. MAY) the use of position (0,0) in the
   slotframe. I don't see anything wrong with that, and most likely, most
   implementations will follow this recommendation. For cases which really
   need to use a different location (I'm not sure why at this point), the
   I-D/RFC doesn't prevent one from putting a different location. In this
   case, the "Slotframe and link IE" would contain e.g.
   slotOffset=2|channelOffset=6, and the joining would use that configuration.

What do others think?

Thomas

On Tue, Jun 10, 2014 at 12:20 AM, Xavier Vilajosana <
[email-masked]> wrote:

>>>> ADV flag in the EB makes little sense, since it would mean that all
>>>> neighbors are time source neighbors for all nodes (I hope this sentence
>>>> makes sense).
>>>>
>>>>>>> 1)      Enforce CCA including energy above threshold for the
>>>>>>> minimal slot (respecting EN300328 rules for adaptive devices)
>>>>>>>

---

From: Kris Pister <[email-masked]>
Date: Wed, 11 Jun 2014 11:03:05 -0700

+1

ksjp

On 6/11/2014 10:39 AM, Thomas Watteyne wrote:
> Xavi,
>
> I'd like to go back to your question about what 
> [slotOffset,channelOffset] to use for the single cell announced in the EB.
>
> My opinion is that:
>
>   * The single cell MUST be announced using the "Slotframe and link
>     IE" of IEEE802.15.4e (Section 5.2.4.14). I see no advantage in
>     defining our own formats, or hardcoding what to use.
>   * If we agree with the statement above, the "Link Information
>     fields" from that IE (Figure 48hh) contains "Timeslot" and
>     "Channel Offset" fields. IMO, we could recommend (i.e. MAY) the
>     use of position (0,0) in the slotframe. I don't see anything wrong
>     with that, and most likely, most implementations will follow this
>     recommendation. For cases which really need to use a different
>     location (I'm not sure why at this point), the I-D/RFC doesn't
>     prevent one from putting a different location. In this case,
>     the "Slotframe and link IE" would contain e.g.
> On Tue, Jun 10, 2014 at 12:20 AM, Xavier Vilajosana 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     2014-06-10 9:17 GMT+02:00 Thomas Watteyne
>     <[email-masked] <mailto:[email-masked]>>:
>
>         Xavi,
>
>             Since any EB can be heard by all the sender's neighbors,
>             setting the *_timekeeping_* flag in the EB [...]
>
>
>         Thomas
>
>
>         On Mon, Jun 9, 2014 at 10:55 PM, Xavier Vilajosana
>             Since any EB can be heard by all the sender's neighbors,
>             setting the ADV flag in the EB makes little sense, since
>             it would mean that all neighbors are time source neighbors
>             for all nodes (I hope this sentence makes sense).
>
>             "makes little sense". So you are suggesting to do *not
>             *mark it? Note that macLinkType is not part of the EB but
>             is a property of a cell in the schedule. This means that
>             this is not sent, but nodes when receiving the EB mark the
>             announced cell as either ADV or NORMAL. As for Jonathan
>             email before, it seems that by marking links as ADV
>             ensures that anything can be sent on that links (Data and
>             EBs).
>
>             Instead, I believe the link announced in the EB should NOT
>             have the timeKeeping flag set. Instead, "an upper layer"
>             is responsible for marking the RPL routing parent as also
>             the time source neighbor, so that the timing structure is
>             the same as the RPL DAG. This is in accordance with the
>             current minimal draft.
>
>             2014-06-10 7:24 GMT+02:00 Thomas Watteyne
>             <[email-masked]
>             <mailto:[email-masked]>>:
>
>                 Xavi,
>
>                 My take on this.
>
>                 Since any EB can be heard by all the sender's
>                 neighbors, setting the ADV flag in the EB makes little
>                 sense, since it would mean that all neighbors are time
>                 source neighbors for all nodes (I hope this sentence
>                 makes sense).
>
>                 Instead, I believe the link announced in the EB should
>                 NOT have the timeKeeping flag set. Instead, "an upper
>                 layer" is responsible for marking the RPL routing
>                 parent as also the time source neighbor, so that the
>                 timing structure is the same as the RPL DAG. This is
>                 in accordance with the current minimal draft.
>
>                 Thomas
>
>
>                 On Mon, Jun 9, 2014 at 8:49 PM, Xavier Vilajosana
>                     thanks you very much, my worry was about
>                     macLinkType field as I had doubts on how to set
>                     it. Now you confirm that the flag MUST be set to
>                     ADV as soon a node receives an EB with information
>                     of the link. This also indicates that all data
>                     packets sent by a node will be sent using the only
>                     Thanks for the timekeeping recommendation, I
>                     understand the implications but I have a doubt
>                     w,r,t your last sentence
>
>                     "What I would recommend is to NOT set the
>                     /Timekeeping/ flag, and add some text which
>                     explains that the /Timekeeping/ flag is set
>                     according to the RPL DAG structure."
>
>                     Assume node A is neighbor of node B ,C  and D and
>                     A is time source neighbor of C  while D is time
>                     source neighbor of B, they all share a slotted
>                     aloha slot set as ADV type. Who marks timekeeping
>                     in its schedule for that shared cell? Ideally B
>                     would mark timekeeping flag if only it can receive
>                     EBs from D while C would mark timekeeping flag if
>                     it can only receive EBs from D. As this is not the
>                     case because everybody can hear everybody, should
>                     the timekeeping flag be set? if so, who sets it?
>                     everyone?
>
>                     I will update the minimal draft with what we have
>                     been discussing last days. Thanks you very much!
>                     X
>
>
>
>
>                     2014-06-10 2:41 GMT+02:00 Jonathan Simon
>                     <[email-masked] <mailto:[email-masked]>>:
>
>                         Xavi,
>
>                         To summarize your proposal (please correct me
>                         if I'm wrong), the EB would contain a single
>                         slotframe IE, containing itself a single link.
>                         That link would be marked with the
>                         <TX|RX|SHARED> flags to obtain slotted-Aloha
>                         behavior. Note that ADVERTISING flag is
>                         strictly speaking part of the /macLinkType/,
>                         not of /macLinkOptions/, as you can read in
>                         Table 52d:
>
>
>
>                             /The Link Options field indicates whether
>                             this link is a TX link, an RX link, or a
>                             SHARED TX link, and
>                             whether the device to which it is being
>                             linked is to be used for clock
>                             synchronization. The field corresponds
>                             to the Link Options field in the link
>                             table for the receiving device. SHARED TX
>                             links are used for a joining
>                             device to send an Association Request
>                             command or other higher layer message. RX
>                             links are used for a
>                             joining device to receive an Association
>                             Response command or other higher layer
>                             message from an
>                             advertising device (i.e., a device sending
>                             Enhanced Beacons with TSCH information).
>                             RX links shall have
>                             the Timekeeping linkOptions bit set. It is
>                             possible for one link to be used as both
>                             SHARED_TX and RX
>                             link./
>
>
>                         So, for this to work, you need to add some
>                         text in the I-D which indicates that the
>                         device, upon receiving the EB, configures the
>                         TSCH schedule with the link, and marks it as ADV.
>
>                         To answer your question, IEEE802.15.4e-2012
>                         specified (see table above) that "ADVERTISING
>                         [...] indicates the link may be used to send
>                         an enhanced beacon". It does not preclude that
>                         other types of packets are sent on that link,
>                         so I believe it should be OK.
>
>                         One final comment about the
>                         /Timekeeping/ flag. It is my understanding
>                         that 6TiSCH recommends to use the RPL DAG as
>                         the synchronization structure. Since all the
>                         nodes are sending EBs, the link in all EBs
>                         cannot be marked with the /Timekeeping/ flag,
>                         or you end up with synchronization chaos (i.e.
>                         synchronization loops). What I would recommend
>                         is to NOT set the /Timekeeping/ flag, and add
>                         some text which explains that the
>                         /Timekeeping/ flag is set according to the RPL
>                         DAG structure.
>
>                         I hope this helps,
>
>                         Jonathan
>                         -- 
>                         Jonathan Simon, Ph. D
>                         (510) 400-2936 <tel:%28510%29%20400-2936>
>                         (510) 489-3799 <tel:%28510%29%20489-3799> FAX
>                         [email-masked] <mailto:[email-masked]>
>
>                          This e-mail transmission, and any documents,
>                         files or previous e-mail messages attached to
>                         it may contain confidential information that
>                         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
>                         On Jun 8, 2014, at 12:27 PM, Xavier Vilajosana
>>                         3) The linkType for that cell can be NORMAL
>>                         and it is not required to be ADVERTISMENT
>>                         despite EBs will also be sent on that cell.
>>
>>                         I would like to ask if everybody agrees on
>>                         that approach and whether not having a
>>                         dedicated ADV cell but sending EBs in a
>>                         NORMAL link is possible.
>>
>>                         Another minor issue is the location of the
>>                         active cell in the schedule, this can be in a
>>                         fix position (i.e the first cell in the
>>                         slotframe) or the cell can be any in the
>>                         slotframe and this be advertised by the EB
>>                         (in both cases will be advertised but in the
>>                         second case will not be known in advance as
>>                         it is not static).
>>
>>                         thanks!
>>                         Xavi
>>
>>
>>
>>
>>                         2014-06-04 20:11 GMT+02:00 Kris Pister
>>                         <[email-masked] <mailto:[email-masked]>>:
>>
>>                             If item 2 is described in the 15.4
>>                             standard and implemented by chip vendors,
>>                             then
>>>                             processes flows, and that as a result a
>>>                             deterministic timeslots may periodically
>>>                             overlap with an minimal one.
>>>
>>>                             Taking the assumption of time-aligned
>>>                             slots, it would make sense to be able to:
>>>
>>>                             2)use a longer CCA for minimal to leave
>>>                             a better chance for deterministic traffic
>>>
>>>                             What do you think ?
>>>
>>>                             Pascal
>>>
>>>                             *From:*6tisch
>>>                             [mailto:[email-masked]] *On
>>>                             Behalf Of *Kris Pister
>>>                             <mailto:[email-masked]>
>>>                             If we choose to pick a particular active
>>>                             cell (e.g. slot 0, offset 0), then
>>>                             everything about the
>>>                                 I want to propose a formal
>>>                                 modification to the minimal draft
>>>                                 following what we discussed last week
>>>
>>>                                 I propose:
>>>
>>>                                 4) this active slot  will have a
>>>                                 linkOption bitmap indicating that it
>>>                                 is RX, TX and SHARED (i.e slotted aloha)
>>>
>>>                                     I like the term quack better as
>>>                                     long as there are not too many
>>>                                     of them : )
>>>
>>>                                     *From:*6tisch
>>>                                     [mailto:[email-masked]]
>>>                                     <mailto:[email-masked]>
>>>                                     I think that they are both good
>>>                                     questions. I'm reminded of the
>>>                                     Far Side cartoon
>>>                                     It's important that motes A, B,C
>>>                                     know when to give a blank stare,
>>>                                     but it's also
>>>                                     useful to have an efficient
>>>                                     mechanism to enumerate which
>>>                                     protocols are
>>>                                     supported, much like TLS cipher
>>>                                     suite negotiation. Perhaps
>>>                                     something like

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 11 Jun 2014 21:15:08 +0200

Hi Thomas,

I agree. If everyone agrees I will write that into the draft.

thanks!
X

2014-06-11 20:03 GMT+02:00 Kris Pister <[email-masked]>:

>    - The single cell MUST be announced using the "Slotframe and link IE"
>    of IEEE802.15.4e (Section 5.2.4.14). I see no advantage in defining our own
>>>>>>  "What I would recommend is to NOT set the *Timekeeping* flag, and
>>>>>> add some text which explains that the *Timekeeping* flag is set
>>>>>>  I will update the minimal draft with what we have been discussing
>>>>>> last days. Thanks you very much!
>>>>>>  X
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>  To summarize your proposal (please correct me if I'm wrong), the
>>>>>>> EB would contain a single slotframe IE, containing itself a single link.
>>>>>>> That link would be marked with the <TX|RX|SHARED> flags to obtain
>>>>>>> slotted-Aloha behavior. Note that ADVERTISING flag is strictly speaking
>>>>>>> part of the *macLinkType*, not of *macLinkOptions*, as you can read
>>>>>>> in Table 52d:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> *The Link Options field indicates whether this link is a TX link,
>>>>>>>> an RX link, or a SHARED TX link, and whether the device to which it is
>>>>>>>> being linked is to be used for clock synchronization. The field corresponds
>>>>>>>> to the Link Options field in the link table for the receiving device.
>>>>>>>> SHARED TX links are used for a joining device to send an Association
>>>>>>>> Request command or other higher layer message. RX links are used for a
>>>>>>>> joining device to receive an Association Response command or other higher
>>>>>>>> layer message from an advertising device (i.e., a device sending Enhanced
>>>>>>>> Beacons with TSCH information). RX links shall have the Timekeeping
>>>>>>>> linkOptions bit set. It is possible for one link to be used as both
>>>>>>>> SHARED_TX and RX link.*
>>>>>>>
>>>>>>>
>>>>>>> (510) 400-2936 <%28510%29%20400-2936>
>>>>>>> (510) 489-3799 <%28510%29%20489-3799> FAX
>>>>>>> [email-masked]
>>>>>>>
>>>>>>> 3) The linkType for that cell can be NORMAL and it is not required
>>>>>>> to be ADVERTISMENT despite EBs will also be sent on that cell.
>>>>>>>
>>>>>>>  I would like to ask if everybody agrees on that approach and
>>>>>>> whether not having a dedicated ADV cell but sending EBs in a NORMAL link is
>>>>>>> possible.
>>>>>>>
> 6tisch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch
>
>
>

---

From: Qin Wang <[email-masked]>
Date: Wed, 11 Jun 2014 17:41:48 -0700 (PDT)

I agree.

Qin

On Thursday, June 12, 2014 3:15 AM, Xavier Vilajosana <[email-masked]> wrote:

Hi Thomas, 

thanks!
X

+1
>>I'd like to go back to your question about what [slotOffset,channelOffset] to use for the single cell announced in the EB.
>>
>>
>>My opinion is that:
>>	* The single cell MUST be announced using the "Slotframe and link IE" of IEEE802.15.4e (Section 5.2.4.14). I see no advantage in defining our own formats, or hardcoding what to use.
>>
>>	* If we agree with the statement above, the "Link Information fields" from that IE (Figure 48hh) contains "Timeslot" and "Channel Offset" fields. IMO, we could recommend (i.e. MAY) the use of position (0,0) in the slotframe. I don't see anything wrong with that, and most likely, most implementations will follow this recommendation. For cases which really need to use a different location (I'm not sure why at this point), the I-D/RFC doesn't prevent one from putting a different location. In this case, the "Slotframe and link IE" would contain e.g. slotOffset=2|channelOffset=6, and the joining would use that configuration.
>>What do others think?
>>
>>
>>Thomas
>>
>>
>>
>>On Tue, Jun 10, 2014 at 12:20 AM, Xavier Vilajosana <[email-masked]> wrote:
>>
>>>>Since any EB can be heard by all the sender's neighbors, setting the timekeeping flag in the EB [...]
>>>>
>>>>
>>>>Thomas
>>>>
>>>>
>>>>
>>>>On Mon, Jun 9, 2014 at 10:55 PM, Xavier Vilajosana <[email-masked]> wrote:
>>>>
>>>>Hi Thomas, 
>>>>>
>>>>>
>>>>>see inline
>>>>>
>>>>>
>>>>>Since any EB can be heard by all the sender's neighbors, setting the ADV flag in the EB makes little sense, since it would mean that all neighbors are time source neighbors for all nodes (I hope this sentence makes sense).
>>>>>
>>>>>
>>>>>
>>>>>"makes little sense". So you are suggesting to do not mark it? Note that macLinkType is not part of the EB but is a property of a cell in the schedule. This means that this is not sent, but nodes when receiving the EB mark the announced cell as either ADV or NORMAL. As for Jonathan email before, it seems that by marking links as ADV ensures that anything can be sent on that links (Data and EBs).
>>>>>
>>>>>
>>>>>Instead, I believe the link announced in the EB should NOT have the timeKeeping flag set. Instead, "an upper layer" is responsible for marking the RPL routing parent as also the time source neighbor, so that the timing structure is the same as the RPL DAG. This is in accordance with the current minimal draft.
>>>>>
>>>>>
>>>>>>Since any EB can be heard by all the sender's neighbors, setting the ADV flag in the EB makes little sense, since it would mean that all neighbors are time source neighbors for all nodes (I hope this sentence makes sense).
>>>>>>
>>>>>>
>>>>>>
>>>>>>Instead, I believe the link announced in the EB should NOT have the timeKeeping flag set. Instead, "an upper layer" is responsible for marking the RPL routing parent as also the time source neighbor, so that the timing structure is the same as the RPL DAG. This is in accordance with the current minimal draft.
>>>>>>
>>>>>>
>>>>>>Thomas
>>>>>>
>>>>>>
>>>>>>
>>>>>>On Mon, Jun 9, 2014 at 8:49 PM, Xavier Vilajosana <[email-masked]> wrote:
>>>>>>
>>>>>>Dear Jonathan, 
>>>>>>>
>>>>>>>
>>>>>>>thanks you very much, my worry was about macLinkType field as I had doubts on how to set it. Now you confirm that the flag MUST be set to ADV as soon a node receives an EB with information of the link. This also indicates that all data packets sent by a node will be sent using the only existing link which will be of macLinkType  ADV. 
>>>>>>>
>>>>>>>
>>>>>>>Thanks for the timekeeping recommendation, I understand the implications but I have a doubt w,r,t your last sentence
>>>>>>>
>>>>>>>
>>>>>>>"What I would recommend is to NOT set the Timekeeping flag, and add some text which explains that the Timekeeping flag is set according to the RPL DAG structure."
>>>>>>>
>>>>>>>
>>>>>>>Assume node A is neighbor of node B ,C  and D and A is time source neighbor of C  while D is time source neighbor of B, they all share a slotted aloha slot set as ADV type. Who marks timekeeping in its schedule for that shared cell? Ideally B would mark timekeeping flag if only it can receive EBs from D while C would mark timekeeping flag if it can only receive EBs from D. As this is not the case because everybody can hear everybody, should the timekeeping flag be set? if so, who sets it? everyone?
>>>>>>>
>>>>>>>
>>>>>>>I will update the minimal draft with what we have been discussing last days. Thanks you very much!
>>>>>>>
>>>>>>>X
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>whether the
                                                          device to
                                                          which it is
                                                          being linked
                                                          is to be used
                                                          for clock
                                                          synchronization.
                                                          The field
                                                          corresponds
>>>>>>>>>to the Link
                                                          Options field
                                                          in the link
                                                          table for the
                                                          receiving
                                                          device. SHARED
                                                          TX links are
                                                          used for a
                                                          joining
>>>>>>>>>device to send
                                                          an Association
                                                          Request
                                                          command or
                                                          other higher
                                                          layer message.
                                                          RX links are
                                                          used for a
>>>>>>>>>joining device
                                                          to receive an
                                                          Association
                                                          Response
                                                          command or
                                                          other higher
                                                          layer message
                                                          from an
>>>>>>>>>advertising
                                                          device (i.e.,
                                                          a device
                                                          sending
                                                          Enhanced
                                                          Beacons with
                                                          TSCH
                                                          information).
                                                          RX links shall
                                                          have
>>>>>>>>>the
                                                          Timekeeping
                                                          linkOptions
                                                          bit set. It is
                                                          possible for
                                                          one link to be
                                                          used as both
                                                          SHARED_TX and
                                                          RX
>>>>>>>>One final comment about the Timekeeping flag. It is my understanding that 6TiSCH recommends to use the RPL DAG as the synchronization structure. Since all the nodes are sending EBs, the link…
                                                          Simon, Ph. D
>>>>>>>>Director of
                                                          Systems
                                                          Engineering
>>>>>>>>Linear
                                                          Technology,
                                                          Dust Networks
                                                          product group
>>>>>>>>30695 Huntwood
                                                          Ave
>>>>>>>>Hayward, CA
                                                          94544-7021
>>>>>>>>*****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. 
>>>>>>>>>>If item 2 is
                                                          described in
                                                          the 15.4
                                                          standard and
                                                          implemented by
                                                          chip vendors,
                                                          then
>>>>>>>>>>we should
                                                          examine the
                                                          pluses and
                                                          minuses of 1
                                                          more closely. 
                                                          If not, then
                                                          it seems
>>>>>>>>>>to me that
                                                          item 2 is out.
>>>>>>>>>>>One benefit is
                                                          that active
                                                          slots are
                                                          uniformly
                                                          spread out in
                                                          time
                                                          automatically,
                                                          resolving
>>>>>>>>>>>that
                                                          particular
                                                          email thread.
>>>>>>>>>>>If we choose
                                                          to pick a
                                                          particular
                                                          active cell
                                                          (e.g. slot 0,
                                                          offset 0),
                                                          then
                                                          everything
                                                          about the
>>>>>>>>>>>MAC timing can
                                                          be hard coded
                                                          except the
                                                          slotframe
                                                          length.
>>>>>>>>>>>>>of the
                                                          scientist
                                                          speaking to a
                                                          duck.
>>>>>>>>>>>>>"Sprechen Sie
                                                          Deutsch?"
                                                          <blank
                                                          stare>
>>>>>>>>>>>>>It's important
                                                          that motes A,
                                                          B,C know when
                                                          to give a
                                                          blank stare,
                                                          but it's also
>>>>>>>>>>>>>useful to have
                                                          an efficient
                                                          mechanism to
                                                          enumerate
                                                          which
                                                          protocols are
>>>>>>>>>>>>>supported,
                                                          much like TLS
                                                          cipher suite
                                                          negotiation. 
                                                          Perhaps
                                                          something like
>>>>>>>>>>>>>a "client
                                                          hello"
                                                          message?
>>>>>>>>>>>>6tisch mailing
                                                          list
>>>>>>>>>>>>6tisch mailing
                                                          list
>>>>>>>>>>6tisch mailing
                                                          list
>>>>>>>>>6tisch mailing
                                                          list
>>>>>>>>>http://cp.mcafee.com/d/5fHCNEg6jqb5QQTTT1PVKVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrd7b9EV8c6zBB_HYOMqekkmeLsKCOMZPWrUVMQsYJt6OaaJXKsG7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymok…
6tisch mailing list [email-masked] https://www.ietf.org/mailman/listinfo/6tisch