Re: [6lowpan] WGLC for 6lowpan HC draft

[Dario Tedeschi]

Thanks Jonathan A few comments below... 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.     • 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? 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). -- Regards Dario Tedeschi

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan