Dear Fellows,
After having taken a look at draft-ietf-6tisch-minimal-11, we would like to share some points/conclusions with you. There are some aspects which were decided just before the Plugtest event in order to guarantee the interop. between the different participants. One of these decisions was related to the addressing fields, which were fixed with the following format (point 4 - draft-ietf-6tisch-minimal-11): - Sequence Number: Present. - Destination PanId: Present. - Destination Address: Present (Extended format). - Source PanId: Not Present. - Source Address: Present (Extended format). - PANID Compress: set to 0b00. We think, taking into account the current standard, that the minimal may provide a “minimum/reduced” solution in order to start a TSCH network, but keeping the compliance with the standard. Therefore, the transmission frame addressing format could be fixed but not in reception. For instance: the standard allows the omission of the destination addressing fields when the frame goes to the PANCoordinator. Thus, having the following implementation: - PANCoordinator with current minimal implementation (draft-ietf-6tisch-minimal-11). - Associated Mote and using the destination addressing fields omission as described above. The PANCoordinator has to accept the frame sent by the Mote, although that frame would not be compliance with the draft-ietf-6tisch-minimal-11 addressing format. Another important aspect to have into account is the acknowledgment frame format. The ack depends on the received frame format; therefore, the minimal establishes the same addressing format for the ack as it has into account the all the received frame follow the same exactly format; but as commented above, it could be given a frame with a standard compliance format (sequence number suppressed) and the ack response would not be possible following the draft-ietf-6tisch-minimal-11 ack configuration. The minimal could be oriented to fix the format of the data frames transmitted, but the reception should not be fixed or restricted in order to keep the interop. with standard compliance frames. Thus, the ack format has to be based on the received frame and not fixed to only one case. The last topic has to do with the periodic beacon addressing format. Following the standard ieee802.15.4e-2012, point 5.1.6.2 “Reception and rejection”: “…If a destination PAN identifier is included in the frame, it shall match *macPANId *or shall be the broadcast PAN identifier…” Having a not associated mote, which does not have macPanId yet, would not be able to filter correctly the periodic beacon transmitted by a (PAN)Coordinator, which follows draft-ietf-6tisch-minimal-11. We propose the use of the next combination for a periodic beacon in a TSCH network (following table 2a in [IEEE802154-2012]): - Sequence Number: Not Present (not necessary). - Destination PANID: Not Present. - Destination Address: Not Present. - Source PANID: Present. - Source Address: Present (Short mode). Best Regards, Kirale Tech.
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
