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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 20 January 2016 07:54 UTC

Return-Path: <pthubert@cisco.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 A30081A9102; Tue, 19 Jan 2016 23:54:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 rsC2zykQ5bYL; Tue, 19 Jan 2016 23:54:46 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4A01A8720; Tue, 19 Jan 2016 23:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4422; q=dns/txt; s=iport; t=1453276485; x=1454486085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MLoe2ArsdPdvuT5q0j1PUQ14Zi7ma33lNiybMHmuBMo=; b=afaxGa+7GwMewBZGpRUZ7JNx1ZHrDTQR9nkpcx2XPEYHgXMFwr32Rh8e O0TIlr/m5z10AVSSm0Sef0pKG7jnvlZ8b3KbbdCpc2qRVW2WJM4sIUEhu ZLZBkoXUcZjv0mTCGUhviRue5yIQBYzmp0jpZqO5Pg+KmiGQz7G/ByWYu A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgDxPJ9W/4YNJK1egzpSbQaIUbJzA?= =?us-ascii?q?Q2BYyKCPYMwAhyBJTgUAQEBAQEBAYEKhDQBAQEEIxFFDAQCAQgRAQMBAQECAiM?= =?us-ascii?q?DAgICHxEUAQIGCAIEAQ0FCId+AxIOr32LaA2DTAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARV7hT+EdIJOgVMQAgEBgzOBSQWXGgGFR4YfgXGBZUqDeoMrhTSGf4Ntg28?= =?us-ascii?q?BIAEBQoQJcoYqgQgBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,320,1449532800"; d="scan'208";a="229332878"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2016 07:54:44 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u0K7siHa024137 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 07:54:44 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 01:54:44 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 01:54:44 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Simon Duquennoy <simonduq@sics.se>, Michael Richardson <mcr+ietf@sandelman.ca>
Thread-Topic: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
Thread-Index: AQHRU1ZHSQ+tC4vTpkOrAc0uFeSGZJ8EBvmg
Date: Wed, 20 Jan 2016 07:54:31 +0000
Deferred-Delivery: Wed, 20 Jan 2016 07:54:28 +0000
Message-ID: <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>
In-Reply-To: <CAMxvJt+5F4KMRcRDtaP_BdNQq2F2ip2j_s2Ts4HXCMpAS4-zVA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.22.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/3LJLsiL0KASvKXBWtcO53A6C8iI>
Cc: "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 07:54:48 -0000

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