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

Simon Duquennoy <> Wed, 20 January 2016 07:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ACC6B1A802D; Tue, 19 Jan 2016 23:43:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zK_JCLhB14Ny; Tue, 19 Jan 2016 23:43:42 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA1151A8A84; Tue, 19 Jan 2016 23:43:41 -0800 (PST)
Received: by with SMTP id u188so173097875wmu.1; Tue, 19 Jan 2016 23:43:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MFPIqUxp2y2qBFOlDOODfdobPeN01gSr7/8z0o/d2iE=; b=qWE7MMoXd+rRid0ODFdkk2BBXCySumtaB1ueVgEtegHPw9yBafbQeNTDiJHGbLh0uE pplv9wPk5BqxWRFpowiKQ+CXNCSMUxDRtQ2qn04x3bkdaCV8lpyHFM1ZKpBQLXf4PnIy sh7l5n5x065kEDg5MQJYGdF0Ywd8Bh5MgEG5kixDFLIzWXY1YuT83boPaqxzbksyxRUt lMvciVjsxb9i2n4KBV0YA93jvg2MJxjJ4gmxwN9A8DSYHHUZWsW4RxkVmyvgZQqSGkZZ iizGoM/Lt5ZclAGINTa69RyI38f4qqEcecGqDXEALM9X4e0nzSwoc2B06XFNCTdkmPFZ uvLw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MFPIqUxp2y2qBFOlDOODfdobPeN01gSr7/8z0o/d2iE=; b=dvpK3AzpfYvtXZvV7P9YUgCJNjcgKy6qFsOjm2wuZNE6kQhq7MZ/PxQa+ILWfMXX5D p+qTsiZFCWsCeHRj9M2CDSysT3DePOe9p4C5nYNuI1/xUkGqvm7X92cQ8wxFttEXNIcy UqHfyAc+kW+dVgZ0+YQnG5iRD7n2l1WnWf4am6dakb66JbGzDwnki+6MCulmQ+y9Pcqt RscBRzmhzTSkV/NpXRjWR9WpHzCVVkeUdDGtJ9bQvS0CYw0WseL5eF3ZF3EHn0leJDJH aVNbt/t0FYQpB7Hi6J1KEPDXqa+6I6BRoZ6FL3xBFJdTx32WsUH1tOYZfclb3iG4dLmu I18w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MFPIqUxp2y2qBFOlDOODfdobPeN01gSr7/8z0o/d2iE=; b=CuwP4/PKsZrC3/yHBbqwHpetN5atqJwC1RTPfUTuTt5QdGTfZ0FuBMFGhiopDgjaCn 1NQaPdfC0xYq3OLMQrLe7JUo50O2dy3K0oVpkUfRGmmJlcRQ8au7bOCbGBqDIm63+vYB 7HEDquDkg3FXaqWw+SzlOgL3Q0DmSdKO7YimROXY6TiOmxCDLs6YAfTdbuR2/Lpu7YAI VJEovknP2s0fOw04cARpZ4XEhnjkanle8DFwFPJXClzYAfIEsA8nAC+/G7Cii8WvgCc+ 2yxU1HawwiFOlDjcdf509DXD8G9zHxUaiJG1+FMptWGuxrQBQ/fQcf+zvTYRHN6MrHMp qp/A==
X-Gm-Message-State: AG10YOQfdeEDhn3Fi275hTCFg0GWybgLrRwf438wY1n0w5OgaG2yhjLgGRsOPpkQoLhfHSK8IVU4Ra1szuhtZA==
MIME-Version: 1.0
X-Received: by with SMTP id 5mr2331162wmx.82.1453275820303; Tue, 19 Jan 2016 23:43:40 -0800 (PST)
Received: by with HTTP; Tue, 19 Jan 2016 23:43:40 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 20 Jan 2016 08:43:40 +0100
X-Google-Sender-Auth: yiJpYDbwyRkPB6IfD9kCvRRxrS8
Message-ID: <>
From: Simon Duquennoy <>
To: Michael Richardson <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "Pascal Thubert \(pthubert\)" <>, Routing Over Low power and Lossy networks <>, "" <>, "" <>, Tengfei Chang <>
Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jan 2016 07:43:43 -0000

Right, I'm using the wrong wording, I counted RFC6554 as RPL, sorry
for the confusion.

What I don't like:
- IPv6 stack interacting with the adaptation layer
- No one-to-one mapping between a RH3-6LoRH and a RH3

If I'm not mistaken, everything else in 6lowpan offers this one-to-one
mapping, and that allows the IPv6 stack to work independently of
6lowpan (i.e. the same stack runs both in 6lowpan environment or not).
I also find this property nice, conceptually, as one can produce any
IPv6 packet and easily derive its compressed form, and back. One
header maps to one compressed header with all its fields compressed,

If I'm the only one to think this is an issue, I'm ready to close the issue.


On Tue, Jan 19, 2016 at 11:06 PM, Michael Richardson
<> wrote:
> Simon Duquennoy <> wrote:
>     > Not really. It was rather my view of the architecture that differs a
>     > bit from what you describe in your previous mail.
> okay.
>     > For me RPL produces the RH3 and then passes the packet down the stack
>     > for compression. Or for incoming packets, first there is
>     > decompression, then the IPv6 packet with its headers and extension
>     > headers are passed up to RPL etc. If find it odd to force upper layers
>     > to work on 6lowpan compressed formats.
> RPL is the thing in RFC6550, a routing protocol, that runs over ICMP ND messages.
> I think the thing you are describing is the IPv6 stack, and you don't like
> that the IPv6 stack has to interact with the link adaptation layer.
> --
> Michael Richardson <>ca>, Sandelman Software Works
> IETF ROLL WG co-chair.