Hi Jonathan
Jonathan Hui wrote:
Hi Dario,
On Feb 22, 2010, at 11:14 AM, Dario Tedeschi wrote:
Jonathan Hui wrote:
• 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."
Would it not be a little clearer to the reader, if the NHC section in
hc-06 stated that reserved fields must be sent inline.
I prefer exclusion text since the common case for IPv6 extension
headers is to carry everything inline. So I can certainly clarify the
text to more explicitly indicate the common case and add in some text
that talks directly to reserved fields that make it extra explicit
that the common case really is to carry everything inline.
Yes, I think that would be good.
• 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).
What if A was an IP header?
Then you wouldn't be using NHC to compress A, but IPHC instead. My
point is that NHC for IPv6 Extension Headers doesn't buy you much
unless you want to elide at most 7 octets of tail padding in a
Hop-by-Hop Options header or a transport-layer header that you'd like
to also encode using NHC. If a header turns out to be longer than 255
bytes, any savings will be relatively small compared to the size of
the datagram.
If you can't compress B using NHC, having A compressed can still buy
you a lot. So for the current NHC in the draft there are two
implementations I see:
• Before encoding the next-header field in the IP header, look
ahead at B to see if its options exceed 255 bytes.
• Or, compress A then attempt to encode B, and if B's options
exceed 255 bytes, insert the next-header field in compressed A's
inline area (requires a memmove).
Either would be logically correct and the choice should be left up to
the implementor.
I understand that; I was just wondering if there was some other way of
handling Ext Headers without having a 255 byte limit. I'm sure it's been
thoroughly investigated. Thanks for the clarification.
--
Dario Tedeschi
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
