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
