Re: [6tisch] removing the 'e'

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello René

Removing the 'e' *today* is effectively transparent with regards 802.15.4e and 802.15.4-2011 because today that's what a reference to 802.15.4 means. How is that imprudent?

And no I do not see that what I'm saying in not precisely tangential. Can you explain yourself?

>From my standpoint, I have re-centered the discussion to my original question, and added clarifying questions/suggestions.

Original question:
- can we remove the 'e' in the charter
clarifying questions:
- suggestion to place in a note for the reference to address the questions raised about compatibility with future versions, asking wording.
- on best practice in IEEE references (this is being resolved at this very moment with the IEEE coordination and the RFC editor)
- and to the IEEE 6TiSCH interest group and whoever has access to the IEEE draft version: whether and how the current text impacts the 6TiSCH work as it stands.

What is tangential and digressive is references to MAC layer changes that do not affect L3 (or 6top). What goal is that serving?

And certainly, we will be interested in changes that would impact the 6top interface so we can add the required stuff to the data model.
If issues are identified, we can probably hold 6top interface till the IEEE document is ratified and published.

Cheers,

Pascal

From: Rene Struik [mailto:[e-mail]]
Sent: mercredi 1 avril 2015 16:35
To: Pascal Thubert (pthubert); Jonathan Simon
Cc: [e-mail]
Subject: Re: [6tisch] removing the 'e'

Hi Pascal:

My assessment was (and is) that it is imprudent to remove the "e" at this point in time. I never suggested that, *after* doing proper due diligence we could still move along that route.

Your message below seems more a branding exercise, which should be completely tangential to the question you asked to the 6TiSCH community on the mailing list.

All the goodies and rosy things on the horizon you sketched below may still materialize. The only point right now is that the "scrapping the e act" is premature.

BTW - MAC compatibility problems may very well impact IETF, in protocols whose design may make assumptions on MAC properties and on, e.g., 6top interfaces. If 6TiSCH would be indeed be completely independent of the underlying MAC ("MAC compatibility problems are an IEEE problem, not an IETF problem"), then why have all the 6TiSCH documents that have MAC language in them?

Best regards, Rene

On 4/1/2015 5:22 AM, Pascal Thubert (pthubert) wrote:
Hi Jonathan, René and all:

But the point is, we are not working in silos like industrial protocols, defining the whole stack from PHY to APP. We are defining an IETF stack, which happens to be designed to apply above the TSCH mode of in 802.15.4 that was introduced by 802.15.4e.

Because we work on layers as opposed to silos, the 6TiSCH logo guarantees interop at the IP layer, not at the MAC or PHY layers.
E.g. IP (as defined over Ethernet) works on all Wi-Fi versions. But I can hardly connect my old 802.11a card to any network these days. Sad it is, but that is not an IETF problem.
In the hypothetical case that IEEE802.15.4:2015 is not compatible with  "802.15.4-2011 as amended by 802.15.4e-2012", and that 6TiSCH, as specified, works on both without a change, then we should still refer to IEEE802.15.4.

MAC compatibility problems are an IEEE problem, not an IETF problem; there has also been a concern in this thread that the changes on MAC/PHY require too much new work. All this is certainly unfortunate, but it has to be resolved at the IEEE, not on this list.  We have an Interest Group and may leverage it, but still this list is not the right forum and the discussion is taking us way beyond the question I asked to the group.

And because silos are still needed to guarantee interoperability, products that support 6TiSCH will have to bear some logo that indicate what MAC/PHY they use, as well as which security models they support; there will be multiple such logos that bind all that together and guarantee some interoperability and functionality. IOW, it is up to an adopting standard (a ZigbeeIP, an ISA, an IEC, a Thread or an HCF of this world) to be more specific of the whole stack they build upon, and the IETF does not need to have a say in that.

René's suggestion, "802.15.4-2011 as amended by 802.15.4e-2012", would for instance fail to include 802.15.4g. There are shipping products that do TSCH over the sub-Gig in AMI/AMR and SmartGrid use cases, and barring them from moving to 6TiSCH makes no sense. 6TiSCH is probably a great solution for WiNAN. So I am strongly opposed to that limiting wording. From the IEEE perspective, "IEEE802.15.4" *today* means "802.15.4-2011 as amended by 802.15.4e-2012, 802.15.4f-2012,  802.15.4g, 802.15.4j, 802.15.4k, 802.15.4m, and 802.15.4p". For all I know that is *exactly* what we want.

There has also been concerns that 6TiSCH RFCs may fail to work as expected over some future version of 802.15.4. This may become true, and this may be plain FUD. But yes, that is our problem. I'll be asking around if there is a best practice between IEEE and IETF for such thing, above and beyond our particular case. My current research indicates that we have been widely inconsistent so far. One suggestion could be to place a note in the reference, as discussed in RFC4897 though for other purposes. This note could indicate that "this RFC applies to the version of 802.15.4 that is current at the time of publication of this RFC, and that it is expected but not guaranteed that this RFC applies to 802.15.4 versions published after the publication of this RFC".

So the updated action plan that I'm proposing to the group is as follows:
- still, remove the 'e' in the charter; additionally:
- work on a note for the reference to address the questions raised about compatibility with future versions.
- lookup for a best practice in that area (I'm taking that action item but help is welcome)
- task the IEEE 6TiSCH interest group to check whether the current text impacts the 6TiSCH works as it stands (including drafts discussed for re-chartering such as 6top and OTF)

Does this make sense?

Pascal

From: 6tisch [mailto:[e-mail]] On Behalf Of Jonathan Simon
Sent: mardi 31 mars 2015 19:02
To: Rene Struik; Kris Pister
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [6tisch] removing the 'e'

Chiming in...

I agree with Rene, "802.15.4-2011 as amended by 802.15.4e-2012" is a perfectly valid specification, and one that has formed the basis of a number of products, including my company's.

I believe that Pat is trying to faithfully represent upcoming changes, and that the primary goal of 802.15.4-2015 effort is to correct mistakes and remove ambiguities that might result in different implementations.  Yet there have been a few incompatible changes introduced, perhaps for valid reasons - I would argue the short address doesn't leak info if only authenticating, and doesn't prevent the combination of EUI + ASN + Key from being replayed, so that more moderate informative language could be used to solve this particular problem.  I also think that policing IE's is naive - the IEEE doesn't own the band, and a robust design uses security to ensure that frame content is correct.

So I guess it comes down to two things:

1) are the incompatible changes adding something that is needed for 6TiSCH - if not, we are free in 6TiSCH to override behavior we don't like, e.g. "x is as described in spec y, except for the limitation of clause z, which is taken from spec p, clause q"
2) do we need to see 802.15.4-2015 before adopting it as a normative reference?  Paranoid me says yes, but if people agree to 1) then its not really a problem.

--
Jonathan

Thanks Kris;

Let's review your points:

- IE IDs:  When 15.4e was introduced, we allowed vendors to freely use 25 non-standardized IDs with the explicit warning that another vendor could be using that ID creating a conflict, destroying coexistence. Since that time we have seen a significant number of requests for IE IDs, so given the limited number of IDs and the fact that there really is no vendor coexistence with the original scheme, we changed to one specific vendor ID where the vendor's OUI is required to make the IE unique.

- macTsRxOffset: the basic intent of macTsRxOffset is to center the transmission start within the range of 2200 µs (macTSRxWait). So the transmitter's macTsTxOffset (2120µs) should be 1100µs (macTsRxWait/2) greater than macTxRxOffset(1020µs).  However, 15.4e mistakenly used the term "frame" when it actually meant "PPDU". The start of the frame occurs 192 µs after the start of the PPDU or packet. 15.4e's value of 1120µs was an extra 100µs to compensate for the PHY components (which are really 192 µs). In summary, we could either continue to use the term frame with macTxRxOffset=1020µs, or use PPDU and add 192 µs.

- use of short addresses in nonce generation: 15.4e changed the nonce requirement of 15.4-2011, from requiring the use of the 8-octet extended address to allowing the usage of the short address (btw - all operations modes not just TSCH). It is generally understood that using the short address in the nonce generation is very problematic. Even if the short address is unique inside the PAN, there could be multiple PANs sharing the same keying material and using same short address for multiple devices. Using only the short address and not a combination of PANId and macShortAddress since it also puts another requirement, that short address needs to be unique over all PANs which use same key, not only unique inside the current PAN.

- TLV vs. LTV: The revision retains the IE formatting from 15.4e, it remains backward compatible.  The statement "the fact that such a change, with little to no practical value, would require continuous debate over many meetings is a sign that backward compatibility is not top of mind for a good part of the WG" is totally incorrect.  All standards organizations require that all individuals and organizations be heard, and they were in a thoughtful manner.

In summary, the changes done in the revision were to correct issues and problems.  The standardized TSCH IE IDs were not changed, rather a method was added to eliminate vendor conflicts in non-standardized IDs and the extra IDs were put back into reserve.  The macTxRxOffset was changed to be consistent with the correct terminology. While using the short address for nonce generation is not compliant to the revision, the group consensus was that it's not appropriate to knowingly degrade security, hence reverting back to the 802.15.4-2011 method.

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[e-mail]<mailto:[e-mail]>




--

email: [e-mail]<mailto:[e-mail]> | Skype: rstruik

cell: [phone] | US: [phone]