Re: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented??
Pascal Thubert (pthubert) wrote: > Well, as I said earlier the overhearing device can be configured with > the slot set to shared, which is correct after all, so no ack from > him... > Then there's the security; we must use a key that the overhearing device will know... In the overhearing case, yes. It implies in the end that we can't have per-pair keying. In the case where we send two unicast packets, the keying can be done in anyway. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented??
Well, as I said earlier the overhearing device can be configured with the slot set to shared, which is correct after all, so no ack from him... Then there's the security; we must use a key that the overhearing device will know... Regards, Pascal > Le 9 août 2017 à 18:03, Michael Richardson a écrit : > > > Pascal Thubert (pthubert) wrote: >> Unsure what your question is, Michael. > >> The node that is scheduled to overhear can see the cell as shared, to >> it will not ack. There is the problem of the dMAC. In 6TiSCH tracks we > > Yes, all of this assumes the ability to tune some low-level things. > While I concur that a number of softmac will have the flexibility to do this, > I wonder about this *in general*. > >> There is no 'hardware' per se, since unless I miss something, all this >> is upper MAC, classically software. So anyone shuld be able to try it >> on its preferred gear. We used OpenMotes. > > A number of radios can send ACKs automatically in the MAC without waking up > the main CPU. The ideas proposed in this document likely can not be > implemented in those devices, and/or there will be higher main CPU wake > times. Of course, over time hardware will evolve. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented??
Pascal Thubert (pthubert) wrote: > Unsure what your question is, Michael. > The node that is scheduled to overhear can see the cell as shared, to > it will not ack. There is the problem of the dMAC. In 6TiSCH tracks we Yes, all of this assumes the ability to tune some low-level things. While I concur that a number of softmac will have the flexibility to do this, I wonder about this *in general*. > There is no 'hardware' per se, since unless I miss something, all this > is upper MAC, classically software. So anyone shuld be able to try it > on its preferred gear. We used OpenMotes. A number of radios can send ACKs automatically in the MAC without waking up the main CPU. The ideas proposed in this document likely can not be implemented in those devices, and/or there will be higher main CPU wake times. Of course, over time hardware will evolve. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented??
Unsure what your question is, Michael. The node that is scheduled to overhear can see the cell as shared, to it will not ack. There is the problem of the dMAC. In 6TiSCH tracks we set it to broadcast. But this is not really a broadcast since only the intended nodes are scheduled to wake up and listen to that cell. So the GMPLS properties of the cell turn it in a multicast group, the mcast group of nodes selected by routing as being progress towards the destination from the point of view of the sender. Note that ISA100.11a has a concept of Duocast, whereby the MAC layer of the sender expects 2 acks and is happy if one comes. The first ack is aligned to the end of the frame whereas the second if aligned to the end of the time slot. There is no 'hardware' per se, since unless I miss something, all this is upper MAC, classically software. So anyone shuld be able to try it on its preferred gear. We used OpenMotes. Take care, Pascal -Original Message- From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Michael Richardson Sent: mardi 8 août 2017 19:41 To: 6tisch@ietf.org Subject: [6tisch] 6tisch-pre-reqs-00 <- can it be implemented?? <#part sign=pgpmime> I was reading draft-papadopoulos-6tisch-pre-reqs-00, and I came across: Considering that each frame may be transmitted twice in unicast to each parent, then depending the transmission, either DP will acknowledge the frame or AP will. I think the possibilities of this are amazing, but I wonder if this will realistically work with many pieces of hardware. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
