Subject: [6tisch] PAN ID Compression

From: Keoma <[email-masked]>
Date: Wed, 4 Oct 2017 11:41:01 -0700

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
(+33)180494139
(+33)684015496

---

From: Robert Cragie <[email-masked]>
Date: Thu, 5 Oct 2017 18:36:29 +0100

I recall similar concerns with PAN ID compression a couple of years ago.
See:

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-masked]> wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Keoma <[email-masked]>
Date: Thu, 5 Oct 2017 10:57:41 -0700

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:
> On 4 October 2017 at 19:41, Keoma <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     (+33)180494139 <tel:%28%2B33%29180494139>
>     (+33)684015496 <tel:%28%2B33%29684015496>
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/6tisch>
> 
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 5 Oct 2017 22:10:11 +0100

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

---

From: Keoma <[email-masked]>
Date: Thu, 5 Oct 2017 20:18:59 -0700

Robert,

Thank you very much for you answers, it's clearer now.

Regards,

Keoma

On 05/10/2017 14:10, Robert Cragie wrote:
> 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-masked]
>     <https://mailarchive.ietf.org/arch/msg/6tisch/G24yEB7a48owwlL3nJZgteuSswE>
>     >
>     > On 4 October 2017 at 19:41, Keoma <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     Hi,
>     >
>     <tel:%28%2B33%29180494139>
>     <tel:%28%2B33%29684015496>
>     >
>     >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     <https://www.ietf.org/mailman/listinfo/6tisch
>     <https://www.ietf.org/mailman/listinfo/6tisch>>
>     >
>     >
> 
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 6 Oct 2017 15:16:40 +0200

@Tero, @Pat, any input about this discussion?

-- 
_______________________________________

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
_______________________________________

---

From: [email-masked]
Date: Sun, 8 Oct 2017 15:02:15 -0500

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-masked] <mailto:[email-masked]>

On 6, Oct2017, at 8:16, Thomas Watteyne <[email-masked]> wrote:

On Fri, Oct 6, 2017 at 5:18 AM, Keoma <[email-masked] <mailto:[email-masked]>> wrote:
Robert,

Regards,

Keoma

On 05/10/2017 14:10, Robert Cragie wrote:
> On 5 October 2017 at 18:57, Keoma <[email-masked] <mailto:[email-masked]>
>     > 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>>
>     >
>     > On 4 October 2017 at 19:41, Keoma <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     > <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >
>     >     Hi,
>     >
>     >     https://kbl.netlib.re <https://kbl.netlib.re/>
>     >     (+33)180494139 <tel:%28%2B33%29180494139> <tel:%28%2B33%29180494139>
>     >     (+33)684015496 <tel:%28%2B33%29684015496> <tel:%28%2B33%29684015496>
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>     >     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-masked] <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

Thomas Watteyne, PhD

www.thomaswatteyne.com <http://www.thomaswatteyne.com/>
_______________________________________
_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Jonathan Simon <[email-masked]>
Date: Sun, 8 Oct 2017 16:18:37 -0700

Pat - note that while dropping a frame with a mismatching PAN ID is often the most energy efficient approach, particularly where multiple PANs are deployed, when frame security is used with short addresses the frame can unambiguously tied to the intended PAN even without an explicit PAN ID, assuming unique keys are used.

Jonathan

> On Oct 8, 2017, at 1:02 PM, [email-masked] wrote:
> 
> On 6, Oct2017, at 8:16, Thomas Watteyne <[email-masked] <mailto:[email-masked]>> wrote:
> 
> >     > https://mailarchive.ietf.org/arch/msg/6tisch/G24yEB7a48owwlL3nJZgteuSswE <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_6tisch_G24yEB7a48owwlL3nJZgteuSswE&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=Al8I0YZDmq4gfRfsEfO7tXrjWnBGWgwtCae_0gGI80s&e=>
> >     <https://mailarchive.ietf.org/arch/msg/6tisch/G24yEB7a48owwlL3nJZgteuSswE <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_6tisch_G24yEB7a48owwlL3nJZgteuSswE&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=Al8I0YZDmq4gfRfsEfO7tXrjWnBGWgwtCae_0gGI80s&e=>>
> >     >
> >     >     https://kbl.netlib.re <https://urldefense.proofpoint.com/v2/url?u=https-3A__kbl.netlib.re_&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=QDtON2m0Ct9zosXJOWKlY0PP2aSjwNL17iLi4n-I1Zs&e=>
> >     >     (+33)180494139 <tel:%28%2B33%29180494139> <tel:%28%2B33%29180494139 <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>>
> >     <tel:%28%2B33%29684015496 <tel:%28%2B33%29684015496>>
> >     >
> >     >
> >     >     https://www.ietf.org/mailman/listinfo/6tisch <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6tisch&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=-KZr1kzV1jbXTkiSgDfWzgOYmM7-7EkbyU5JuaW8Ncc&e=>
> >     <https://www.ietf.org/mailman/listinfo/6tisch <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6tisch&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=-KZr1kzV1jbXTkiSgDfWzgOYmM7-7EkbyU5JuaW8Ncc&e=>>
> >     >     <https://www.ietf.org/mailman/listinfo/6tisch <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6tisch&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=-KZr1kzV1jbXTkiSgDfWzgOYmM7-7EkbyU5JuaW8Ncc&e=>
> >     <https://www.ietf.org/mailman/listinfo/6tisch <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6tisch&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=-KZr1kzV1jbXTkiSgDfWzgOYmM7-7EkbyU5JuaW8Ncc&e=>>>
> >     >
> >     >
> >
> >
> 
> 
> https://www.ietf.org/mailman/listinfo/6tisch <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6tisch&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=-KZr1kzV1jbXTkiSgDfWzgOYmM7-7EkbyU5JuaW8Ncc&e=>
> 
> 
> 
> 
> -- 
> www.thomaswatteyne.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.thomaswatteyne.com_&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=-StkdX9rg6YdCK059KoVIfCRfHfrXq7l-jm90ob01Wc&e=>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_6tisch&d=DwICAg&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=oP0Ojoazjy1DDeOg_avtN8xQ3CqwEsuH1BpeeR5w-7w&m=cdq1dU4db9JFZf06XAw3jmpAENWNvjohfzhMvozBOeg&s=-KZr1kzV1jbXTkiSgDfWzgOYmM7-7EkbyU5JuaW8Ncc&e=

Jonathan Simon
Factory Applications, Dust Networks
Office   (510) 400-2936
Websites analog.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.analog.com_&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=Vugrgdbql3Hd40gM0BtUAjsvc2Q7iU-nbmSivf55h30&m=SSam6wpY39DiCKkHH1ITEO3mczM-LhZMK3O0jjJwOz0&s=l0nAV3QH_gi7Sc5mhrc6H4K0y2K1O9eoFOmSSP_HfzY&e=>, linear.com <http://www.linear.com/>, dustcloug.org <https://www.dustcloud.org/>

Linear Technology is now part of Analog Devices.  Learn more <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.analog.com_en_landing-2Dpages_001_adi-2Dlinear-2Dcombine_index.html&d=DwMFaQ&c=qcgNpIcxtcG4ue_U4n7GwDI5EJilZ62n5ZDvqmyyMRo&r=Vugrgdbql3Hd40gM0BtUAjsvc2Q7iU-nbmSivf55h30&m=SSam6wpY39DiCKkHH1ITEO3mczM-LhZMK3O0jjJwOz0&s=rWMTe-aF_bWpCH50N93mZbX5J2xCmvd6PnW6uhd2GaI&e=>.

---

From: [email-masked]
Date: Mon, 9 Oct 2017 08:35:45 -0500

Agreed, the security mechanism provides an implicit PAN ID.  But, as to your first point, putting the PAN ID into the header allows the receiving device to better manage energy.

Thanks, Pat

Pat Kinney
Kinney Consulting LLC

On 8, Oct2017, at 18:18, Jonathan Simon <[email-masked]> wrote:

Jonathan

> On Oct 8, 2017, at 1:02 PM, [email-masked] <mailto:[email-masked]> wrote:
> 

Jonathan Simon

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 9 Oct 2017 17:17:51 +0300

[email-masked] writes:
> Agreed, the security mechanism provides an implicit PAN ID.  But, as to your
> first point, putting the PAN ID into the header allows the receiving device to
> better manage energy.

If security is used, for non-TSCH modes you always need to know the
extended address of the sender, even if it is using short address when
sending the frame. The nonce for non-TSCH mode is generated using
extended address (see section 9.3.2.1 of 802.15.4-2015). This is
mandatory as the nonce needs to be tied to the sender device, as frame
number is tied to the sender device.

For the TSCH mode where ASN is used it is allowed to use short address
to generate the nonce, but to be able to generate the nonce the
recipient needs to know the PAN ID as PAN ID is part of the nonce
generation when using short addresses in nonce (see section 9.3.2.2 of
802.15.4-2015).

So it would be possible to make 802.15.4 lookalike protocol where PAN
ID would be completely omitted, when using TSCH mode, and still use
the short address in the nonce generation, but then the recipient
needs to know somehow which PAN ID was used when sender generated the
frame. I.e., if sender uses PAN ID of 0x1234 when generating the
nonce, but do not transmit it, then recipient either needs to try all
possible PAN IDs and try to decrypt the frame using all of them, or it
must have prior configuration telling the PAN ID.

Because of these issues, the PAN ID cannot be completely omitted in
802.15.4 frames when using short addresses.

When using extended addresses there is no issue with that, as PAN ID
is not used when generating the nonce, thus when using extended
addresses there is a way to completely omit the PAN ID.
-- 
[email-masked]

---

From: [email-masked]
Date: Mon, 9 Oct 2017 09:28:33 -0500

I understand and agree.  Referring to my earlier email when I stated implicit, it was my understanding that the specific PAN ID was stateful, i.e. the receiving device somehow knew as to what PAN ID the transmitting device was associated.  Given that the PAN ID was understood, the receiving device could then also have known what extended address was associated with the short address.

Pat

Pat Kinney
Kinney Consulting LLC

On 9, Oct2017, at 9:17, Tero Kivinen <[email-masked]> wrote: