Hello, Unfortunately I won't be at Beijing. However I wanted to voice my support for this draft in place of my specific ICMPv6 compression algorithm I had proposed.
I think it's become obvious that we may be (a) running a lot of different protocols and (b) the protocols we are currently designing are still under flux. Having a generic method means you never need to update it, which would become a nightmare in ensuring both sides are compatible, which to me alone is worth the trade-off in less efficient compression. Regards, -Colin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Carsten Bormann Sent: October 23, 2010 10:49 PM To: 6lowpan Subject: [6lowpan] Generic HC draft (Re: Size of NS+ARO+SLLAO in nd-10) Before IETF78, we had a discussion about the size of certain packets such as the 6lowpan-ND Router Advertisements. At the time, I pointed to a pre-draft that contained a basic design for a header compression scheme addressing this and other oversized packets in the 6lowpan operational protocols. On Jul 12, 2010, at 17:48, I wrote: > The actual spec in there is a single page (but doesn't define how it is integrated with hc-07 NHC yet; that will be another paragraph and might use up the reserved code). It will probably need another page of "Here's a nice way to use it" for general ICMP, ND, DHCP and RPL, each. That spec is now complete (and still a single page for the compression, plus another page for how it works together with the finished 6lowpan-HC). (Actually, the spec already is a -01, simplified from -00 *and* getting slightly better compression.) There are also six pages of examples showing the compression of actual packets from the 6lowpan packets repository; the compression factors are not as good as they could be with a specially-made compression scheme for each format, but they seem surprisingly good for a 1-page spec. Enjoy at: http://tools.ietf.org/html/draft-bormann-6lowpan-ghc Before/in Beijing, we maybe can discuss whether we want to have something like this in 6lowpan, and, if yes, which parts of the design we want to use. (Then I'll fix the Security Considerations section and add the missing text about fragment boundaries.) Gruesse, Carsten PS.: If someone can provide a pcap file for one of the RPL formats not yet shown in the Examples section, I would be grateful. Of course, any other real-world captures, including DHCPv6, also would help. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
