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

Simon Duquennoy <simonduq@sics.se> Wed, 20 January 2016 08:08 UTC

Return-Path: <simon.duquennoy@gmail.com>
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 672381A1A75; Wed, 20 Jan 2016 00:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IYwJ-9Bp2aE; Wed, 20 Jan 2016 00:08:18 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B332E1A92E5; Wed, 20 Jan 2016 00:08:17 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id b14so15586190wmb.1; Wed, 20 Jan 2016 00:08:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Jvd5JCMg2oii4v+RtcZZ9dh9E2MJgBlqzI2Nj1pXKFU=; b=rdINqI+oqr0Z/FGhkEC2/FwakGXErndR6foGKiNpA576vHs5Vvw9y5tKINv+q2+aFu PukCY+bpu/P68fq/kIxYFoeuRCXZEbp17Qb3GHgOJEfqw7T9b3GVTTZFYN7f3aX3RUQv owPwvMfwHyTv/uPDUeEjyiRocYdXsTFdWLm+xFnvKs8j92M46MWQm8OlVwCbgxMcdZ26 /UQiyxskoPRIyHLWuAX+CmXBENfXrXjSLUifz3ufOJdD3P5vUchMqBAJmz+1+g+HeoOJ Wa26Rr9bnPhaPXVM2Ad8FXEi+IVYg6+8hEjeVZlOHBqvZBGCyFOGBiljTjPBedCKrNLn X4Ag==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Jvd5JCMg2oii4v+RtcZZ9dh9E2MJgBlqzI2Nj1pXKFU=; b=UG3Yfj/rgu8GLpvboZ9rcVXI5pL9k27F64N1LDBIrNWdt7FtMNW1El67cI/mWPX7CU LNqrj6QEz9m3coBUGMOxzJcaPgkJplIZuNgCX7KooNsQctJZLTOZ0T7yKqra0IDbfz3p 9qQtMSgJyErJxEogYVcSK3zUan1NmW30cL3gC9sTVKUetnbI7ICDbZc8UbxkkBoO9Oi2 jASqeYRIcADrqLMM/licsBqFWfjy12l7CSsskUfUSZkWpGbXB1RDo5pclo6mnLRvOWaM j8EHRGZWZlrToshm50Lw+aeBeSoV9AiSYY7iit7YJcwkGi4m3Xl1K2iNtz/HURi4Y4gC 8mjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Jvd5JCMg2oii4v+RtcZZ9dh9E2MJgBlqzI2Nj1pXKFU=; b=RymjmeRCff6vFuIYRgEbkk9iC95fM2fakbQjsPrDjN4UJLaivsphpnFdny2r5vl1ZI bMGxEUCIf8YGyIvQbBKOApoCV6s+AqPMGyAodDAqdZjaA2L0+ijSMbUQyikbKbSFX8wH J5LLXLmsH7Odg2WlidqiVUtU7lxYa9avSPkxRGQhWpxGLvbs+h3Gf/7Q06ilO+aDjMk4 BsBjHII9FLgV0/Tv8d3Y4W1ueR1kSLvTNqIWbg8wwVO5qLCPXbMBTCixkIwkh9s3jwRC py3XfcTkLhUPqxx/ZxmTdyOKcL7JxYu/PITVQwAnHtpdzoeFjJAQFy4R3sAo9pN4+Dq9 MlEA==
X-Gm-Message-State: ALoCoQkXDhw3sQo0kY4SQJQwvi+Y7KeIkQcAVqtYCnEtCwoY585q+fjKDLWf/w0QwKkiMvbUoF6lLb+jmp8x9dpVKlIfd/tF/A==
MIME-Version: 1.0
X-Received: by 10.194.63.40 with SMTP id d8mr34332978wjs.127.1453277293354; Wed, 20 Jan 2016 00:08:13 -0800 (PST)
Sender: simon.duquennoy@gmail.com
Received: by 10.194.79.97 with HTTP; Wed, 20 Jan 2016 00:08:13 -0800 (PST)
In-Reply-To: <1242695b45434c228707c20daf89173e@XCH-RCD-001.cisco.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> <ca1efcb2f850414d9ee9728bd310f18e@XCH-RCD-001.cisco.com> <18432.1453239740@obiwan.sandelman.ca> <CAMxvJtLGzD82VS2r+DLQG0kbuoyk8eA8LCJ2qErxMcffJGm0nQ@mail.gmail.com> <24959.1453241182@obiwan.sandelman.ca> <CAMxvJt+5F4KMRcRDtaP_BdNQq2F2ip2j_s2Ts4HXCMpAS4-zVA@mail.gmail.com> <1242695b45434c228707c20daf89173e@XCH-RCD-001.cisco.com>
Date: Wed, 20 Jan 2016 09:08:13 +0100
X-Google-Sender-Auth: jMVBYrRmkDphy8-RfSsm7yN67UU
Message-ID: <CAMxvJtJSMze8KbR_kzPi+EHww3qr03SAUnb-wzE1GaZ5XexdZg@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/S_G2t5wTBD2n9cLu9y777FgcqFE>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, Tengfei Chang <tengfei.chang@gmail.com>
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: Wed, 20 Jan 2016 08:08:19 -0000

Yes let me participate to the next 6TiSCH interim. I'll be also at the plugtest.
Will be much easier over voice ;)
Thanks,
Simon


On Wed, Jan 20, 2016 at 8:54 AM, Pascal Thubert (pthubert)
<pthubert@cisco.com> wrote:
> Our messages crossed, Simon.
>
>> - IPv6 stack interacting with the adaptation layer
>
> I'm not sure I agree with that (see my other mail), but if you're correct I really what to dig that and fix it.  Please read the other email I just sent and if you still see that the mapping is not there then please refine what the issue is exactly.
>
>
>> - No one-to-one mapping between a RH3-6LoRH and a RH3
>
> We can reconstruct an RH0 form from RH3 and from RH3-6LoRH, and recompress an RH0 into both as well. I fail to see what the problem is though I do hope that implementations never need to play that game. When the packet goes up the stack, the RH3-6LoRH should be gone, removed by the last router (which may be collocated).
>
> Would you be willing to participate to the next 6TiSCH interim? We'll discuss that topic since it impacts the plugtest.
>
> Cheers,
>
> Pascal
>
>
>> -----Original Message-----
>> From: simon.duquennoy@gmail.com [mailto:simon.duquennoy@gmail.com]
>> On Behalf Of Simon Duquennoy
>> Sent: mercredi 20 janvier 2016 08:44
>> To: Michael Richardson <mcr+ietf@sandelman.ca>
>> Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; 6tisch@ietf.org;
>> Routing Over Low power and Lossy networks <roll@ietf.org>rg>; Tengfei Chang
>> <tengfei.chang@gmail.com>om>; 6lo@ietf.org
>> Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
>>
>> 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, etc.
>>
>> If I'm the only one to think this is an issue, I'm ready to close the issue.
>>
>> Thanks,
>> Simon
>>
>>
>> On Tue, Jan 19, 2016 at 11:06 PM, Michael Richardson
>> <mcr+ietf@sandelman.ca> wrote:
>> >
>> > Simon Duquennoy <simonduq@sics.se> 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software
>> Works
>> > IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
>> >