Hi Dario,
On Feb 19, 2010, at 3:42 PM, Dario Tedeschi wrote:
I have a few questions regarding Extended Header Compression:
• How does one compress the "type-specific data" field in a IPv6
Routing Header? It's a variable-length field with no predefined
format given in RFC 2460. To compress this field effectively, a
6LoWPAN encoder would need to know the formats of all the currently
used Routing Types.
You don't compress. If you want compact routing information, then
create a new routing header type that utilizes compact information
(e.g. not full IPv6 addresses). It is likely that RPL will go this way.
• Is the reserved field in the Fragment Header elided or sent
inline as 0?
Sent inline as is. See this important text from hc-06:
"For the most part, the IPv6 Extension Header is carried verbatim
in
the bytes immediately following the LOWPAN_NHC octet, with two
important exceptions: Length Field and Next Header Field."
• If Ext Header [B] follows compressed header [A] and the options
in [B] turn out to be longer than 255 bytes during compression, how
would you adjust [A] without having to do a memmove to make space
for the inline next-header field. What I understand is that, if
header [B] itself can't be compressed, the next-header field in
header [A] must be placed in the inline portion for header A and
before other inline fields in [A]. This problem also requires one to
keep a pointer back to where the inline next-header field should be
inserted. One other solution would be to look ahead at the length of
[B] before compressing [A], but I think this can get messy.
If you can't compress B, using NHC encoding for A doesn't buy you
anything (actually hurts). My approach is to first see if it makes
sense to use NHC encoding at all by traversing the headers, then do
the transformation if needed.
The important point here is that NHC support for IPv6 Extension
Headers isn't really intended to compress the IPv6 Extension Headers
themselves all that much (the only real exception is the ability to
elide padding in options headers. The real intended use is to allow
NHC encoding of transport-layer headers (e.g. UDP, TCP, etc.) as we
discussed in Stockholm.
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
