Colin,
It was brought up at the last Zigbee IP test event. Within Zigbee,
several vendors are already using a 64 bit context, 16 bit MAC and
filling in the gap with FF:fe00. I think it would be good to document
this case explicitly in the HC-08 specification. It is more efficient
than using a 112 bit context because only 64 bits of context need to be
sent in the 6LowPAN-ND message.
Daniel.
Colin O'Flynn wrote:
Hello,
I could have sworn the following was brought up by someone else, but I
couldn't find it now, so wanted to make sure it was mentioned:
When using stateful compression for 16-bit inline, the description of how to
generate the address is:
The address is derived using context information
and the 16 bits carried in-line.
If the context is shorter than 112 bits, how do you fill in the remaining?
It can either be specified as filling with zeros, filling with :ff:fe00:, or
simply out of scope for this document.
I would vote for either filling with :ff:fe00: (unline with stateless
compression), since it results in the most efficient usage when forwarding
IPv6 packets, or leaving as out of scope.
Regards,
-Colin
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Carsten Bormann
Sent: August 19, 2010 10:59 AM
To: 6lowpan 6lowpan
Subject: Re: [6lowpan] Working-Group Last Call for draft-ietf-6lowpan-hc-08
I have reviewed HC-08. The review comments are attached.
(Everything not indented by 8 spaces is my comment.)
As the review comments mix a few detailed editorial with very few
substantive technical comments, let me quickly identify the more important
latter ones in my message:
-- Elision of Padding in IPv6 option headers needs to be specified in such a
way as to make sure that the immutability required of IPv6 padding options
is preserved. In essence, this means that only well-formed trailing padding
can be elided, because only that padding can be reconstructed reliably.
This is not much of a technical change in practice, as well-formed padding
should be the norm, but it is important to call out.
-- I think the NH=0 for EID=7 should be a MUST. There is no value in
leaving this open.
-- We need IANA considerations for the NHC byte.
Also, the editorial comments I have made should clarify the issues raised in
Reddy's comments.
(They are editorial for me, but may be technical if someone had a different
understanding.)
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
Regards,
Daniel.
--
__________________________________________________
Daniel Gavelle, Software Team Leader
Low Power RF Solutions (formerly Jennic Ltd.)
NXP Semiconductors
Furnival Street, Sheffield, S1 4QT, UK
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Comp Reg No: 3191371 - Registered In England
http://www.nxp.com http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
