Subject: [6lowpan] Generic HC draft (Re: Size of NS+ARO+SLLAO in nd-10)

From: Carsten Bormann <[email-masked]>
Date: Sat, 23 Oct 2010 23:49:04 +0200

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.

---

From: "Colin O'Flynn" <[email-masked]>
Date: Sun, 24 Oct 2010 20:06:54 +0100

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-masked] [mailto:[email-masked]] 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:

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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan