Hello Xavi:
I like this text since it makes the normative text mostly independent on IEEE
specs and their evolution.
There seems to be an agreement in Prague that the best direction to sort the
issues with -2011 would be to align to the next revision so that everybody is
ready for 802.15.4-2015. I’ve been wondering how and where to reflect that,
like a few words in the annex with the IE examples. Any suggestion?
Some quick notes:
The packet formats are specific for the [IEEE802154-2012]
revision and MAY vary in future releases of the IEEE standard.
I’d suggest to lowercase that MAY, this text is not normative. On the side, I’d
also lowercase the text in the introduction, in particular the MUST.
I had second thoughts about the
Number of available frequencies | 16
Shouldn’t we allow a given configuration to blacklist / whitelist some ?
Looking at section 4, I’d rather indicate what the goal is as opposed to how it
is encoded and then indicate how it is encoded in the current IEEE specs. e.g:
the PAN ID Compression bit MUST be set to 0b0. According to the
Table 2a in [IEEE802154-2012], this translates into the
Destination PAN ID field being "Present" and the Source PAN ID
field being "Not Present".
This text has an expectation on encoding that may change. Suggestion is to
change to:
the PAN ID Compression MUST indicate that the
Destination PAN ID field is "Present" and the Source PAN ID
field is "Not Present". With [IEEE802154-2012] and according to
Table 2a, this is accomplished by setting the PAN ID Compression
bit to 0b0.
Unicast frames sent to a unicast MAC destination address request an
acknowledgment.
Somehow this sentence was truncated?
One RECOMMENDED way to achieve this in an
interoperable fashion is to set Sp to 2*ETX.
Just a reminder that we discussed in Prague that we should use (3*ETX -2) so
that an ETX of A would result in MINIMUM_STEP_OF_RANK of 1
All the best,
Pascal
From: 6tisch [mailto:[email protected]] On Behalf Of Xavier Vilajosana
Sent: lundi 7 septembre 2015 05:30
To: [email protected]
Cc: Robert Cragie <[email protected]>; José Ángel Miranda
<[email protected]>; Jonathan Simon <[email protected]>; Pat Kinney
<[email protected]>
Subject: Re: [6tisch] comments on 15.4 header fields in minimal
Dear all,
after the last WG webex meeting on Friday we decided to finalize this
discussion and come out with a proposal on the IEEE802.15.4 specific header
fields and what minimal should say about that.
the threads where this is being discussed are:
https://mailarchive.ietf.org/arch/msg/6tisch/2pXzQH7n_6EjvVo05QlOXnzSG3c
and
https://mailarchive.ietf.org/arch/msg/6tisch/9GslRkNZYLECdIWwwU0QqD-XlEI
My proposal is to find a text for minimal that does not restrict the
implementation to any version of 15.4 but instead indicates that the (PANID
Compression bit) is used according to the underlying 15.4 version implemented.
here a proposal:
"The IEEE802.15.4 header of all frames MUST include the Sequence Number field,
the Source Address field and the Destination Address field and only the
Destination PANID. Frame Version field MUST be set to 0b10 (Frame Version 2).
When using DATA, ACKNOWLEDGEMENT, MAC COMMAND frame types the source and
destination address fields MUST be filled with an extended address (64 bit) and
this be indicated in the corresponding Frame Control field. The Destination
PANID MUST be present, the Source PANID MUST be elided and the PANID
Compression bit MUST be set or clear according to the specific IEEE802.15.4
implementation. "
As per Jose (Kirale) email there are several cases where this implementation
would require a special handling of packets when running in minimal compliant
mode. Although this might work, maybe is time to also make things simple and
not force another set of IF cases to support that mode.
Finally, note that this is for minimal, which is a fallback mode of operation
or used for initial interop testing. This means that this mode of operation is
not the one that will be running in most of the networks all the time but
instead will be switched on when something fails or the network initializes.
regards,
Xavi
2015-07-27 11:00 GMT+02:00 Robert Cragie
<[email protected]<mailto:[email protected]>>:
For some reason, it was deemed necessary to change PAN ID compression in
802.15.4-2012 for frame version 2 but there is an issue with the case where:
* both addresses are present
* either or both is a short address
* PAN ID compression is set to 1
In this case the inferred PAN ID is 0xffff but it is not possible to
distinguish an identical short address which may be allocated in different
PANs. So I believe the decision was to keep the original format for PAN ID
compression where either or both are short addresses but to change the
behaviour if both addresses are extended addresses. I have already pointed out
that this is a significant change from frame version 0/1 and changes the
meaning for PAN ID compression. See the analysis document I sent out earlier.
I don't actually see how 802.15.4e-2012 Table 2a can actually be used as it is
erroneous as described above. I would be interested to know if anyone is doing
it this way, especially using PAN ID compression set to 1.
Robert
On 27 July 2015 at 05:52, Xavier Vilajosana
<[email protected]<mailto:[email protected]>> wrote:
Hi,
we discussed this concern at the IETF meeting. In minimal we wanted to support
what is already standardized (15.4e-2012) but it seems that if we make things
align to 2012 then we won't be compatible with 2015. If we try to make the text
less specific aiming to have people use the table they want we loose some how
the sense of minimal as different people implementing it will have different
configurations (specially PIDC bits set).
So, what do we do?
2015-07-26 2:50 GMT+02:00 Jonathan Simon
<[email protected]<mailto:[email protected]>>:
I noticed I said 15.4-2012 in my previous email. I meant 15.4e-21012 in case
it wasn't clear.
On Sat, Jul 25, 2015 at 11:39 AM, Robert Cragie
<[email protected]<mailto:[email protected]>> wrote:
I too have some concerns with the way the PAN ID compression is used for frame
version 2. Please see attached analysis regarding PAN ID compression.
Robert
On 24 July 2015 at 21:00, Jonathan Simon
<[email protected]<mailto:[email protected]>> wrote:
Pat - I’m noticing some differences between the proposed table and the one in
15.4-2012.
In 15.4-2012, the last 2 rows of table 2a are
SRC addr DST addr SRC PAN DST PAN PIDC
Present Present Not Present Present 0 (row 12)
Present Present Not Present Not Present 1 (row 13)
In the proposed table, rows 12-14 correspond to the 2012 row 12 case
SRC addr DST addr SRC PAN DST PAN PIDC
Extended Short Not Present Present 1
Short Extended Not Present Present 1
Short Short Not Present Present 1
So the PIDC bit is inverted from the previous version for some address sizes,
but for both extended addresses (new table row 7), you keep the original sense:
SRC addr DST addr SRC PAN DST PAN PIDC
Extended Extended Not Present Present 1
This breaks backward compatibility for older applications that weren’t
considering address size.
There is no row in the new table that corresponds to 2012 row 13 for mixed or
short addresses. This breaks our existing IP product implementation.
--
Jonathan
On Jul 21, 2015, at 11:26 PM, Pat Kinney
<[email protected]<mailto:[email protected]>>
wrote:
As per our 6tisch meeting yesterday concerning the PAN ID compression bit
table, I have attached an IEEE 802.15 document showing the changes to the
latest revision draft. This document will act as guidance to the Technical
Editor to modify the revision draft. In summary, it was agreed that frames of
version numbers “0” or “1" should revert to the instructions stated in IEEE
802.15.4-2011. For frame version “2", new text will be inserted into the
revision declaring the rules in a non-ambiguous fashion.
I would ask those interested in setting the header bits to read this document
and respond with critiques or questions.
Thanks, Pat
Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715<tel:%2B1.847.960.3715>
[email protected]<mailto:[email protected]>
<15-15-0561-03-0mag-yet-another-document-explaining-pan-id-compression (1).docx>
On 21, Jul2015, at 12:46, Xavier Vilajosana
<[email protected]<mailto:[email protected]>> wrote:
Hi,
From the discussion today, the section mandating the use of certain 2012
specific configuration needs to be changed so we can be independent to the
evolution of the 15.4 spec.
The current text is:
The IEEE802.15.4 header of all frames MUST include the Sequence Number field,
the Source Address field and the Destination Address field.
In the Frame Control Field, this translates to:
the Frame Version field MUST be set to 0b10 (Frame Version 2)
the Sequence Number Suppression bit MUST be set to 0b0
the Source Addressing Mode MUST set to 0b11 (long address)
the Destination Addressing Mode MUST set to 0b11 (long address) except for the
broadcast address for which Destination Addressing Mode SHOULD set to 0b10
(short address). The use of long addresses is a REQUIRED as no association
procedure is defined in this document.
the PAN ID Compression bit MUST be set to 0b0. According to the Table 2a in
IEEE802154-2012 this translates into the Destination PAN ID field being
"Present" and the Source PAN ID field being "Not Present".
I propose the following text which I think is aligned with what has been
commented during the discussion.
The IEEE802.15.4 header of all frames MUST include the Sequence Number field,
the Source Address field and the Destination Address field and only the
Destination PANID. Source and destination address fields MUST be filled with an
extended address (64 bit) and this be indicated in the corresponding Frame
Control field. In case of a destination broadcast address, the address field
MUST be filled by a short addresses (16bit). The Destination PANID MUST be
present and the Source PANID MUST be elided.
Would that work?
regards,
Xavi
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
