On Oct 31, 2007, at 3:05 PM, Kris Pister wrote:
Hmm. I guess you're right after all - I am confused. I completely
agree with your statements below, but then I re-read RFC4944 and it
says:
"Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes
should include a byte matching this pattern immediately following
the 802.15.4. header."
And I read the Arch Rock 6LoWPAN tutorial (which is really well
done, by the way), and it says "dispatch: coexistence with other
protocols over the same link". These statements do not appear to
be aligned with what you wrote below.
As I see it, there are only three options:
1) we assume that MAC-layer MICs are always used for 6LoWPAN,
perhaps with a well-known 6LoWPAN key, and then there is never any
question about coexistence. If you're parsing the dispatch byte,
you already know that this is a 6LoWPAN frame.
2) we assume 1, but plan to share MAC-layer crypto with other non-
LoWPAN protocols. This sounds like a bad idea from a crypto
standpoint.
3) we believe that non-6LoWPAN frames may get through to the
network layer, talk about "coexsistence", and cross our fingers
that 15.4 toy designers are all familiar with and abide by the IETF
recommendations. Down this path lies mysteriously failed networks,
broken deployments, and more of the same semi-functionality that
has held WSN commercialization back for the last 5 years.
So which is it? My vote is #1.
I think it's #2.
The idea is that you can design protocols that safely operate
alongside 6lowpan. If you're concerned about people just grabbing
NALP identifiers willy-nilly, well, that's what IANA is for. To give
an example, chances are TinyOS 2.1 will introduce an NALP byte for
its protocols so TinyOS research protocols can coexist on a node also
running 6lowpan.
Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
