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

Simon Duquennoy <simonduq@sics.se> Wed, 20 January 2016 13:33 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 0E45A1A88BA; Wed, 20 Jan 2016 05:33:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 OyhAOBxfXJqM; Wed, 20 Jan 2016 05:33:32 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 590A11A88B2; Wed, 20 Jan 2016 05:33:32 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id n5so29557221wmn.0; Wed, 20 Jan 2016 05:33:32 -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; bh=EfA4s12PwY92r8SIkEshp+mTKRkuaGERRmxLD551R7s=; b=wOzIYstPyKst+NjK4I4SVONz4Chg26Y6eAtErRsOvxPBhebuI+OMetM01v3x04jC4m whNgJ0YYkH/+bvEasSJsSGVUbNnbSaZF7T2yrYnjEBzbi+3t3JZ+nhj2GY1sC3eD4ATR BeDCLlhRuqpTPiaofoEhl1WlM45fxayZ5f2h4i7jE5Mk5ppSwNUyRLQWZ5Mxv5IqQRmn TDAw9EhF60YlVTxGTiU92bc+ZwklW8/0jd2WALgLhIFlWCJBlf9lCAz6MSL1Uyoay9vx gZeFHS+BddYfNL5PEAGYUBjZ+zseGsUbxZeqU2ItrUb1GnDb7DSd3zg+hNjamSIZZLgG Mc+g==
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; bh=EfA4s12PwY92r8SIkEshp+mTKRkuaGERRmxLD551R7s=; b=iTgCiBec9goePVmZAIVhLQ1vKp533qgmw10OUBuXCCIez7CimGLMs1gZWTAcHaxD5l ya0JKAyajQjc0zPDGeaGXa/cp28t+k8D/Mzt5iw4IK2y9EG58AP3JwIBqNXhWfZ8Gi4s jz0+0pSyqzBRT8RGra6fFxaU9gPe09eIxM2akQNpDXieVTSbt2C55Yc4nSYhekdc9YCH mXov4ee3j+/e35jKzGr0efZn9aa+W5RAjwv8z/JRZcGUgH3C+mnGGo6QfDEFhVvCoZa9 9Z2/chokQdKE6MRs7EqtwWpYQc2d0LmqJm9E+HoXpOAQJB+LWhebt2rlRIPKCMXj9bvF D94w==
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; bh=EfA4s12PwY92r8SIkEshp+mTKRkuaGERRmxLD551R7s=; b=WK0ex+G+R2vD1sAp909+N4lIeJPJH+xJODjahgFuoEvav0nzzhSjPI/inzj+9k4iB4 7qmg1fSOiM7OkmhLkHtH5PHCzBJAA5p/fDSWLRMkGlfGB8vsnu0O3FrBMiOvm8jGbvhj kMQWaSqFoBD/1U2Zkk3x52w3tJAuBdRScN0avKlVusMgD+BIwVtriRhEvhUcxIBcHlyl U1PN+sVcVUuKyHLPqX6UsIkwjGEqiWoHmWWFWiceSE5URWIxP4/3cUqOVuIk2/O/WIAr KW99vAsOnASPCqwpYv+DnUAs2c0Gxi/62BUvxqK15VSkCel71b+nrElqwGs5KoCAi0eJ Q/xg==
X-Gm-Message-State: ALoCoQlckS/eN1xvXVCFa36kBrZFPwkHZ4e8gbQ4c05qsMU10JOSKTd+enC5l8+9talxSFdRSvNOVDLz75ZKhzVamk09TZZUHQ==
MIME-Version: 1.0
X-Received: by 10.194.2.243 with SMTP id 19mr42501866wjx.154.1453296810926; Wed, 20 Jan 2016 05:33:30 -0800 (PST)
Sender: simon.duquennoy@gmail.com
Received: by 10.194.79.97 with HTTP; Wed, 20 Jan 2016 05:33:30 -0800 (PST)
Received: by 10.194.79.97 with HTTP; Wed, 20 Jan 2016 05:33:30 -0800 (PST)
In-Reply-To: <8EB5E8E3-FF9D-4693-9850-9404B9CE1A71@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> <CAMxvJtJSMze8KbR_kzPi+EHww3qr03SAUnb-wzE1GaZ5XexdZg@mail.gmail.com> <8EB5E8E3-FF9D-4693-9850-9404B9CE1A71@cisco.com>
Date: Wed, 20 Jan 2016 14:33:30 +0100
X-Google-Sender-Auth: rPMBhvI_GWUUNvlPesX8PCvS70A
Message-ID: <CAMxvJt+j=gV+Lc7poBd5EigYn3Cwd=T8rmrc1G4Qd=ME5BgY9w@mail.gmail.com>
From: Simon Duquennoy <simonduq@sics.se>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b3a86bc2b286d0529c408dc
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/6ZkOz0pFco7zM-jkmG8fgatzBN8>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "Tengfei Chang \(tengfei.chang@gmail.com\)" <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: Wed, 20 Jan 2016 13:33:36 -0000

Will do, talk to you on Friday!
Thanks,
Simon
Le 20 janv. 2016 09:14, "Pascal Thubert (pthubert)" <pthubert@cisco.com> a
écrit :

> Cool
>
> Let us update the agenda to make more room then.
>
> Could you please prepare a slide or 2 illustrating what the problem is?
>
> Also I'd like to provide examples at the call. If you have some that
> illustrate your issues please send them on the lists so I can provide the
> 6lorh form to compare.
>
> Thanks a bunch Simon!
>
> Pascal
>
> > Le 20 janv. 2016 à 09:08, Simon Duquennoy <simonduq@sics.se> a écrit :
> >
> > 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/
> >>>>
>