XV>>Hola Jose, XV>>see my answers inline please
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. XV>> If I understand correctly "allows" says that it is possible but not mandatory right? Note that minimal is not restricting the behaviour of the network but saying that when you run in "minimal" mode, this is for example in a fallback case or for interop purposes you will need to sent the packets using that explicit header compression options. Does this become a huge implementation problem? Does this restrict any aspect of the protocol out of this mode of operation? 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. XV>>Same as before. Note that this is only a case for minimal, we define how PANID and addressing fields are compressed when the node runs minimal explicitly, i.e in a fallback or interop case. Do you see any implementation problem by keeping things like this? XV>>Of course this is something we should discuss and see if we want minimal to be so restrictive or instead bound the PANID compression fields according to the received packet. What others think? 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). XV>> That is a good point. I will consider that. Best Regards, Kirale Tech. Cheers! Xavi 2015-08-14 14:38 GMT+02:00 José Ángel Miranda <[email protected]>: > 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 > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
