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]
Inactive hide details for Pascal"Pascal Thubert (pthubert)"
<[EMAIL PROTECTED]>
"Pascal Thubert (pthubert)"
<[EMAIL PROTECTED]>
Sent by:
[EMAIL PROTECTED]
17-07-2008 10:13
To
"David Culler"
<[EMAIL PROTECTED]>
<[email protected]>
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: [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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
