Re: [6lowpan] HC

["Stephen Dawson-Haggerty" <[e-mail]>]

I'd like to weigh in with a few notes that people on this list might
be interested in.  First, I've released the Berkeley 6lowpan
implementation for TinyOS into tinyos-2.x-contrib/berkeley/b6lowpan
under a BSD license.  It is still very much a work in progress, but it
should be useful to anyone wanting to experiment with 6lowpan.  It
uses HC for header compression and IPv6 stateless autoconf for prefix
assignment.  It provides UDP as the transport, and supports multi-hop
routing.  Standard tools like ping6, nc6, and tracert6 all work with
the stack.  More information is available on the project wiki
(http://smote.cs.berkeley.edu:8000/tracenv/wiki/b6loWPAN).

Second, it might be useful to (re)start the conversation about HC.
Overall, it's relatively clean and easy to implement; many of the
implementation choices surrounding a 6lowpan stack aren't really that
affected by how headers are compressed.  There are a couple of things
neither the draft nor 4944 directly address, though:

 - support route-over combined with no hop-by-hop reassembly
 - support source routing

As older discussions on the list have gone over, the first is
currently possible by unpacking the IP headers in the first fragment
and caching the routing information for successive fragments.  I think
it's probably not necessary to do anything other then declare that the
compressed IP headers must fit into the first fragment, but there
could be other ideas for how to best allow this.

The second belongs in any standard, because it interacts with address
compression: the source route can be used to infer the source and
destination IP address for intra-pan routing.  What I would suggest
here is the addition of an LOWPAN_HCNH encoding for source routing.
This also brings up the issue it should be possible to follow this
header (NHSR?) with a NH_UDP encoding block so as to have compressed
source routing as well as UDP headers.  Whatever header format is
decided on should also support a record route option in the dispatch
byte.  If people agree that this is important, I can write up a
proposal on how to do this.

What else do people see as needing work in HC?

Steve

On Thu, Jul 17, 2008 at 7:54 AM, Geoff Mulligan <[e-mail]> wrote:
> I also agree.  Now is the right time before we have to carry this design
> baggage forward.
>
> As Pascal pointed out - we then need to get HC done sooner.
>
>        geoff
>
> On Thu, 2008-07-17 at 10:56 +0200, Anthony Schoofs wrote:
>> I am also in favor of that approach.
>> We have had issues with routing packets from 6lowpan nodes to IP
>> hosts, and we definitively need the HC compression to make things
>> cleaner and optimized.
>>
>> Anthony
>> --
>> Anthony Schoofs
>> Research Scientist
>> Philips Research
>> High Tech Campus 34 , 5656 AE Eindhoven, The Netherlands
>> Email: [e-mail]
>>
>> Inactive hide details for Pascal"Pascal Thubert (pthubert)"
>> <[e-mail]>
>>
>>
>>         "Pascal Thubert (pthubert)"
>>         <[e-mail]>
>>
>>         Sent by:
>>         [e-mail]
>>
>>         17-07-2008 10:13
>>
>>
>>                To
>>
>> "David Culler"
>> <[e-mail]>
>> <[e-mail]>
>>
>>                cc
>>
>>
>>
>>           Subject
>>
>> Re: [6lowpan] HC
>>
>>    Classification
>>
>>
>>
>>
>>
>> Hi David:
>>
>> I do support that approach. I'd note that it would impose some
>> pressure to release HC rather quickly.
>> Is there a way to get a feedback on existing deployments that use
>> 6LoWPAN HC1?
>>
>> Pascal
>>
>>
>> ______________________________________________________________________
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of David Culler
>> Sent: mercredi 16 juillet 2008 18:25
>> To: [e-mail]
>> Subject: [6lowpan] HC
>>
>> It appears that the 6LoWPAN WG is poised to take up serious discussion
>> of HC (http://www3.tools.ietf.org/html/draft-hui-6lowpan-hc-00) and I
>> would like to encourage us to make a bold move forward while the
>> number of "dusty deck 6LoWPAN implementations" are few - eliminate
>> HC1/HC2 in the process.
>>
>> As a bit of background, the original format document defined HC1 for
>> compression of link local IPv6 addresses and HC2 for compression of
>> UDP and ICMP headers. Both were part of a rather awkward encoding.
>> Most other parts of the encoding got cleaned up with the switch to the
>> stacked header format that went to RFC. Aside from its awkwardness,
>> HC1 was never sufficient, because it provided no compression of
>> routable addresses, nor for the most useful multicast addresses - both
>> rather essential to IPv6. HC1g was proposed to provide a similar
>> (somewhat more effective) stateless compression of common addresses of
>> global scope. This meant two similar compression schemes, HC1 for
>> link-local, HC1G for global. Both are implementable with much less
>> than a thousand lines of code. No ambiguity about when to use which.
>>
>> HC provides a much cleaner approach which subsumes both HC1 and HC1g,
>> better supports multicast, and is much more usable with IPv6 stacked
>> headers because the order of the subheaders is respected. (HC2 comes
>> in between the dispatch and the address subheader, rather than as a
>> portion of the transport subheader).
>>
>> The decision to take on HC, clean up the rough edges, and build
>> consensus around it is the easy part. The bolder step that I would
>> like to suggest is that we deprecate HC1 and get it removed soon.
>>
>> It is always easier to maintain backward compatibility than to make a
>> clean break. But, ultimately that is burdening all the many future
>> implementations in order to avoid a burden on the few current
>> implementations.
>>
>> The reason to avoid this burden is not that either is a huge amount of
>> code. Implementing any of these HCs is only several hundred LOC. The
>> issue is testing and interoperability. The interoperability draft
>> sheds some light on this. There are so many different compression
>> forms and since each is an optimization on the uncompressed version,
>> there are many different ways to represent the same thing. All with
>> different sizes and offsets. At least they are all in the same suite.
>> To multiply that with all the combinations of HC1 and HC will be
>> really unpleasant. Moreover, the only thing anyone will ever use after
>> a short while is HC, since it is so much cleaner and more effective.
>> That means all the HC1 mess and all the testing and interoperability
>> investment will be for nothing other than that - just to pass the
>> test. But it will generate latent bugs, increase the footprint, and
>> frustrate interoperabilty.
>>
>> So, as we imagine a future of billions of 6LoWPAN IP devices embedded
>> in important hard to reach places, lets take the step now to simplify
>> their implementation and testing, rather worry too much about saving a
>> few hours of coding for the half dozen existing implementations. If
>> that is not reason enough, those same implementors will save many
>> times that amount in reduced testing and interoperability validation.
>> _______________________________________________
>> 6lowpan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>>
>> _______________________________________________
>> 6lowpan mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>
> _______________________________________________
> 6lowpan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan