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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 20 January 2016 07:48 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 69B121A906A; Tue, 19 Jan 2016 23:48:47 -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 XDWQPczbaId1; Tue, 19 Jan 2016 23:48:45 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980FE1A905C; Tue, 19 Jan 2016 23:48:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2781; q=dns/txt; s=iport; t=1453276125; x=1454485725; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dpzn3MpAiFaWbEr2qAYyLW3abc0BMTKaVuVhyvmPX6s=; b=KGSXNcSDuEDzS7XBCPsyvBgq3dgBzad9i5d0cuSqv2h+CtXMN4dZqrjC oiXUKKkkxUit3V4M9c7Hfqgu6s2vcceuWpxEqSGQvNahjXWJCxW3YlCbS fDdo+I7jip4Ces7axKrMSfu4O1eH+yAmyDBGzNkBPJmVK4BYTFFuzlm/O c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgANO59W/4sNJK1egzpSbQaIUbJzA?= =?us-ascii?q?Q2BYyKCPYMwAoFBOBQBAQEBAQEBgQqENAEBAQQ6PwwEAgEIEQEDAQEBHgkHIRE?= =?us-ascii?q?UAwYIAgQBDQUIh34DEg67Yw2DTAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGOoR0g?= =?us-ascii?q?k6BZAEBAYR8BZcaAYVHhh+BcYFlSoxZhn+DbYNvASABAUKECXKFcDqBCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,320,1449532800"; d="scan'208";a="227970855"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2016 07:48:44 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u0K7miGe026833 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 07:48:44 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 01:48: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:48:44 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Simon Duquennoy <simonduq@sics.se>
Thread-Topic: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
Thread-Index: AQHRU1b1SkfOy9CXX0O87LiotLoJRA==
Date: Wed, 20 Jan 2016 07:48:31 +0000
Deferred-Delivery: Wed, 20 Jan 2016 07:47:51 +0000
Message-ID: <dc5adf6337924f7d81bb428267fd5ec1@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>
In-Reply-To: <24959.1453241182@obiwan.sandelman.ca>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/ER4aVw3Ybb9e6J2ahLKvzjkI1MI>
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:48:47 -0000

Well, if there is such interaction, it does not come from the RH3 compression but from the IP in IP compression that allows to elide a well-known root. This means that if the root is not that well-known, like the node participate to multiple DODAGs, then the RPI must be included together with RH3. Which is mandated by RPL for that reason, nothing very new there. 

With the current specs, for a packet with a RH3, the source in the IPv6 header when uncompressed is always the root. When 6LoWPAN decompresses the packet, it has to restore the root address first. 

And the proposal says use that as reference for decompression of the next entries in the RH3, as opposed to the final destination in the (inner) IP header.

The change is a slight improvement, since it addresses the case where the leaf does not belong to the same compression domain as the RPL mesh nodes, and avoids having to dig into the inner IP header.
IOW, with the change, the intermediate routers can process a packet without looking at the inner IP in IP.

In the future, if we allow nodes that are different from the root to write an RH3, then we'll have to decide if we use the source of the packet or the  root as reference. I'd probably still use the root so we can compress the source using the root as reference.

Cheers,

Pascal


> -----Original Message-----
> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
> Sent: mardi 19 janvier 2016 23:06
> To: Simon Duquennoy <simonduq@sics.se>
> 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
> 
> 
> 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/