I have asked Ben Rolfe about Robert’s earlier comment about the footnote on Table 7-2.
Since it is not necessary to include PAN IDs when extended addressing is exclusively used, the PAN ID compression should be set to 1. As for both destination and origination using short addresses, at least one PAN ID must be present since short addresses are ambiguous (i.e. not unique) without stating the PAN ID from which they were assigned. Pat Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, SC chair ISA100 co-chair, ISA100.20 chair O: +1.847.960.3715 [email protected] <mailto:[email protected]> On 6, Oct2017, at 8:16, Thomas Watteyne <[email protected]> wrote: @Tero, @Pat, any input about this discussion? On Fri, Oct 6, 2017 at 5:18 AM, Keoma <[email protected] <mailto:[email protected]>> wrote: Robert, Thank you very much for you answers, it's clearer now. Regards, Keoma On 05/10/2017 14:10, Robert Cragie wrote: > Hi Keoma, > > As you say, there is no row for two short addresses without a PAN ID > present. My assessment of this was that this is not allowed as it is not > consistent with frame version 0/1 use of PAN ID. However, the table does > have the row: > > Extended Extended Not Present Not Present 1 > > which suggests it is possible to have two extended addresses without a > PAN ID present. However this is inconsistent with frame version 0/1. > > Robert > > > On 5 October 2017 at 18:57, Keoma <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > Hi Robert, > > Thank you for the answer. > > What about the second question ? > "can you confirm that there is no way to omit both Source and > Destination PAN ID while using Source and Destination Short Addresses ?" > I was using the compression bit to omit both PAN-ID in previous 802.15.4 > implementation. > > Thank you, > > Keoma > > On 05/10/2017 10:36, Robert Cragie wrote: > > I recall similar concerns with PAN ID compression a couple of years ago. > > See: > > > > > https://mailarchive.ietf.org/arch/msg/6tisch/G24yEB7a48owwlL3nJZgteuSswE > <https://mailarchive.ietf.org/arch/msg/6tisch/G24yEB7a48owwlL3nJZgteuSswE> > <https://mailarchive.ietf.org/arch/msg/6tisch/G24yEB7a48owwlL3nJZgteuSswE > <https://mailarchive.ietf.org/arch/msg/6tisch/G24yEB7a48owwlL3nJZgteuSswE>> > > > > This was before 802.15.4-2015 came out and the footnote to table 7-2 > > actually seems wrong to me. > > > > To answer your question: Set PAN ID compression to 1. > > > > Robert > > > > On 4 October 2017 at 19:41, Keoma <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>> wrote: > > > > Hi, > > > > After looking at the 802.15.4-2015 standard, I am not 100% of how to > > implement the Frame Control Field, in particular regarding the PAN > ID > > Compression. > > > > - Both my Source and Destination Address fields are Short. > > - My Source PAN ID and Destination PAN ID are identical > > - I don't want the Source PAN ID and Destination PAN ID to appear > twice > > > > According to the Table 7-2 I am tempted to set the PAN ID > Compression to > > 1 and to omit the Source PAN ID field. > > > > Here is the note that confuses me (Table 7-2, p153): > > "If both the destination and source addressing information is > present > > and either is a short address, the MAC sublayer shall compare the > > destination and source PAN IDs and the PAN ID Compression field > shall be > > set to zero if and only if the PAN identifiers are identical." > > > > Should I set the PAN ID Compression to 1 or not ? > > > > Also, can you confirm that there is no way to omit both Source and > > Destination PAN ID while using Source and Destination Short > Addresses ? > > > > Thank you, > > > > -- > > Keoma Brun-Laguna > > Inria - EVA Team > > https://kbl.netlib.re <https://kbl.netlib.re/> > > (+33)180494139 <tel:%28%2B33%29180494139> <tel:%28%2B33%29180494139> > <tel:%28%2B33%29180494139> > > (+33)684015496 <tel:%28%2B33%29684015496> <tel:%28%2B33%29684015496> > <tel:%28%2B33%29684015496> > > > > > > _______________________________________________ > > 6tisch mailing list > > [email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > <https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch>> > > <https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > <https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch>>> > > > > > > _______________________________________________ 6tisch mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch> -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com <http://www.thomaswatteyne.com/> _______________________________________ _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
