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]> 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]>: > >> 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]> 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]> 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]> 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 >>>> [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]> 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] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
