You're right Phil. IANA is probably responsible for those 6 bits also,
but my thought was, since there are only 64 values, that it is really
probably too small a name space for all of the companies doing
proprietary stuff and if they just set their first two bits to 00 then
at least they can be determined not to be a 6lowpan packet.
Yes it would be a free for all, but after the 64 values are used up,
there is no choice for other companies to but to either not use 00 or to
overlap with an already used value. I'd prefer to say that those bit
are not defined and application specific rather than try to put some
other structure and naming.
I thought also by allowing them to be application defined, these NALP
protocols would overlap their proprietary protocol and therefore not
need to burn an entire byte for the NALP dispatch and we might get more
companies to accept using just 2 bits to help deal with packet
differentiation.
geoff
On Wed, 2007-10-31 at 20:44 -0700, Philip Levis wrote:
> On Oct 31, 2007, at 7:11 PM, Geoff Mulligan wrote:
>
> > 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.
>
> I don't understand; NALP is the set of all dispatch bytes whose first
> two bits are zero. If IANA isn't responsible for the NALP values,
> then I assume no-one is and it's a free-for-all of collision?
>
> Phil
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
