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: [EMAIL PROTECTED]
To
"David Culler"
<[EMAIL PROTECTED]>
"Pascal Thubert <[email protected]>
(pthubert)" cc
<[EMAIL PROTECTED]>
Subject
Sent by: Re: [6lowpan] HC
[EMAIL PROTECTED] Classification
.org
17-07-2008 10:13
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of David Culler
Sent: mercredi 16 juillet 2008 18:25
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
<<inline: graycol.gif>>
<<inline: pic00556.gif>>
<<inline: ecblank.gif>>
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
