Phil,
If the TinyOS research protocol would be possibly using 6lowpan
designated other headers, such as HC1 or HC1g or the Frag header, then I
would think that rather than using NALP, they could request a non-NALP
dispatch value.
I would like to see devices that not attempting to utilize any IP and
6lowpan headers/functions assign the first 2 bits after the 15.4 header
to Zero. What they do with the other 6 bits then are up to them. I
would recommend that IANA stay out of that fray.
geoff
On Wed, 2007-10-31 at 15:18 -0700, Philip Levis wrote:
> 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
>
>
> _______________________________________________
> RSN mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
