Hi David, I support your approach, too. The test for interoperability is increased by complicating specifications. Implementers never want that, I think.
Yuichi "Pascal Thubert (pthubert)" <[EMAIL PROTECTED]> wrote: > 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. > > > -- Hitachi, Ltd., Systems Development Laboratory IGARASHI Yuichi Mail： [EMAIL PROTECTED] Tel ： +81-(0)45-860-3080 FAX ： +81-(0)45-860-1674 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
