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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 20 January 2016 08:14 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 D7E591ACF54; Wed, 20 Jan 2016 00:14:56 -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 FzL_aRpR22nw; Wed, 20 Jan 2016 00:14:55 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2AB1AC3B8; Wed, 20 Jan 2016 00:14:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4118; q=dns/txt; s=iport; t=1453277694; x=1454487294; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CK3qBiS1ZLxhbLr5gx6G2PsEjZZzoyeO++E6p3nnIsE=; b=P3RkBZr2bg4nZy4JaySpL9lO0JH1uqPDfVWdcCYuigy1SlEFsh8Wy8Tz qOCB9OGBpOf9SSDqdkzzZgHvU1GpVLj/l8izXL4ae46e1bUX79l/Qiv9n rLh/pJZgIk1QXXzmCSS2xr5J77ON3hE2AGL1DxWExBWAb2BIPpshd1KjD 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgDHQZ9W/49dJa1egzpSbYhXsnABD?= =?us-ascii?q?YFjIoI9gzACgUE4FAEBAQEBAQGBCoQ0AQEBAwF5BQcEAgEIEQEDAQEBJwchERQ?= =?us-ascii?q?DBggCBA4FiAYDCggOu2YNg0wBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhjqCBgiCZ?= =?us-ascii?q?oJOgVMQAgEBGoNHgRsFjXyFF4QHAYVHhh+BeIFeSoN6gyuFNIVvgRCDbYNvASA?= =?us-ascii?q?BAUKECXKHMgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,320,1449532800"; d="scan'208";a="68079481"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jan 2016 08:14:53 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0K8Erme032120 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 08:14:53 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 02:14:53 -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 02:14:53 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Simon Duquennoy <simonduq@sics.se>
Thread-Topic: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
Thread-Index: AQHRU1m1SQ+tC4vTpkOrAc0uFeSGZJ8EDpTO
Date: Wed, 20 Jan 2016 08:14:53 +0000
Message-ID: <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>
In-Reply-To: <CAMxvJtJSMze8KbR_kzPi+EHww3qr03SAUnb-wzE1GaZ5XexdZg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/3ThKBxMrJa0lHH2uUh03RmBtQEk>
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:14:57 -0000

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