IETF Logo Mail Archive

Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

Michael Richardson <mcr@sandelman.ca> Tue, 19 January 2016 21:39 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96741B36A4; Tue, 19 Jan 2016 13:39:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHLErF8heguR; Tue, 19 Jan 2016 13:39:47 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C371B36AE; Tue, 19 Jan 2016 13:39:47 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3C3DE200A5; Tue, 19 Jan 2016 16:47:47 -0500 (EST)
Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9FBA1637A0; Tue, 19 Jan 2016 16:39:46 -0500 (EST)
From: Michael Richardson <mcr@sandelman.ca>
To: Simon Duquennoy <simonduq@sics.se>
In-Reply-To: <CAMxvJtJ5ZR_fMh3KvH_yePwEaWKBDNaD4+SnO-W=vDf97Uru-Q@mail.gmail.com>
References: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com> <CAAdgstQXj80Pu-Syt_QuxD4_8V0PqEZqxVDsnyGdbBA-hGxEKQ@mail.gmail.com> <2c372ed593ad4d12a7ffff81c3ada270@XCH-RCD-001.cisco.com> <CAAdgstSiochR48+XVV3wCScd_XEttO0Us3rWNu=XVsO8_=kw2A@mail.gmail.com> <CAMxvJtLCN_6+NPruYu5J5KHOybbu+PdDeod7V8S+_iZTKhZTCg@mail.gmail.com> <1ebd8224c530495eba190b8b71f633f6@XCH-RCD-001.cisco.com> <CAMxvJtJ0F_SYe023Bv0y6DixTSQi=PTaKd56ECZdrrrXBk3ApA@mail.gmail.com> <2416.1453235644@obiwan.sandelman.ca> <CAMxvJtJ5ZR_fMh3KvH_yePwEaWKBDNaD4+SnO-W=vDf97Uru-Q@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17873.1453239586.1@obiwan.sandelman.ca>
Date: Tue, 19 Jan 2016 16:39:46 -0500
Message-ID: <17875.1453239586@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/9T1T2MSFuqQMAYAjSVlTKtolX0A>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, Tengfei Chang <tengfei.chang@gmail.com>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2016 21:39:52 -0000

Simon Duquennoy <simonduq@sics.se> wrote:
    > Any level of awareness is too much, IMO a RPL implementation should
    > run unmodified yet benefit from 6LoRH.
    > For instance, if RPL produces a RH3 with cmpri of 6 and cmpre of 10,
    > we end up with two RH3-6LoRH, each with its own "size unit", which has
    > to be power of two -- we end up with a compressed possibly larger than
    > the original.

It's just that *RPL* doesn't produce the RH3...
The RPL produces a routing table for the "kernel", and the kernel produces
the RH3, and it's right there that the 6LoRH should be happening.  I'd rather
like the headers for the 6LoRH to be precomputed and attached to the routing
entry, and that's what I'd do on machine with a bit more ram.

    > Generally speaking 6lowpan offers one-to-one mappings between
    > compressed and original headers, I think it is a pity that 6LoRH
    > doesn't.

It's true that not all RH3 headers can be as efficiently compressed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

v2.23.0 | Report a Bug | By Email