Re: [6lowpan] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt

[Carsten Bormann <[e-mail]>]

On May 19, 2011, at 17:28, Mukul Goyal wrote:

> I would be able to do a comparative analysis of two methods as soon as I understand the mechanism described in draft-bormann-6lowpan-ghc. I have already spent a couple of hours trying to understand draft-bormann. At the moment, I cant figure out how the compression mechanism (Section 2) works and how was it applied to the examples listed in the draft. I suspect the draft does not have sufficient level of explanatory text at the moment.

Hi Mukul,

as usual for compression specs, the spec defines the *de*compressor (on one page, because that's all that's needed -- ignore the experimental nibblecode part, as that doesn't seem to be too popular).
The spec does assume some basic familiarity with compression technology (it does not use anything that has not been known since the late 1970s, though), which you may want to look up.
As with most compression technologies, there are many ways to write a compressor, so specifying a compressor would be overspecification; of course, with the rather limited set of elements in the spec, there aren't *that* many ways of doing it.

When approaching such a specification, it is probably best to look at the examples and satisfy yourself that your understanding of the decompressor indeed generates the uncompressed bits.  The annotated example on slide 38 of the Prague 6LoWPAN tutorial slides (http://www.iab.org/about/workshops/smartobjects/tutorial/Bormann.pdf) might help, too. Then go ahead and think about a good way (reasonably efficient, but not complex) to generate the compressed bits.
The compressor I used for generating the examples is a bit simple-minded at about 50 lines of code (the decompressor is 30 lines).  It essentially runs through the uncompressed bytes, finding sequences of zeros and prefix matches in previous uncompressed bytes, and then (if both are the case) deciding somewhat naively which of the two are more compact; if none are the case, it generates a copy element up to the next useful match.

I you have pcaps of the kind of RPL messages that you want to compress with your spec, I could also simply run them through my example code.

Gruesse, Carsten