Re: [6tisch] comments on 15.4 frame format in minimal

[Xavier Vilajosana <[e-mail]>]

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 <[e-mail]>:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>