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

Carsten Bormann <> Thu, 19 May 2011 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3DC5E06D5; Thu, 19 May 2011 09:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zdPaYcHSbGtC; Thu, 19 May 2011 09:06:26 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id F3CE3E06B8; Thu, 19 May 2011 09:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p4JG6DuH013468; Thu, 19 May 2011 18:06:13 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 82D49E19; Thu, 19 May 2011 18:06:12 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Carsten Bormann <>
In-Reply-To: <>
Date: Thu, 19 May 2011 18:06:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Mukul Goyal <>
X-Mailer: Apple Mail (2.1084)
Cc: roll <>, 6lowpan <>
Subject: Re: [6lowpan] Fwd: New Version Notification for draft-goyal-6lowpan-rpl-compression-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 May 2011 16:06:27 -0000

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 ( 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