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

"S.V.R.Anand" <anand@ece.iisc.ernet.in> Sat, 23 January 2016 08:36 UTC

Return-Path: <anand@ece.iisc.ernet.in>
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 01C531B3442; Sat, 23 Jan 2016 00:36:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.493
X-Spam-Level:
X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_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 XA0sVQ9Gbp1U; Sat, 23 Jan 2016 00:36:42 -0800 (PST)
Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 28F541B3441; Sat, 23 Jan 2016 00:36:39 -0800 (PST)
Received: from ece.iisc.ernet.in (www.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (8.14.4/8.14.4) with ESMTP id u0N8aSGE012337; Sat, 23 Jan 2016 14:06:28 +0530
Received: from [10.32.14.64] ([10.32.14.64]) by ece.iisc.ernet.in (8.14.7/8.14.7) with ESMTP id u0N8cbeT025268; Sat, 23 Jan 2016 14:08:38 +0530
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
References: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com>
From: "S.V.R.Anand" <anand@ece.iisc.ernet.in>
Message-ID: <56A33B8B.6040201@ece.iisc.ernet.in>
Date: Sat, 23 Jan 2016 14:06:27 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com>
Content-Type: multipart/alternative; boundary="------------090200090906040907030706"
X-IISc-MailScanner-Information: Please contact the ISP for more information
X-MailScanner-ID: u0N8aSGE012337
X-IISc-MailScanner: Found to be clean
X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.899, required 6.5, autolearn=not spam, BAYES_00 -1.90, HTML_MESSAGE 0.00)
X-IISc-MailScanner-From: anand@ece.iisc.ernet.in
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/FDPDjI85gyK3LtK7CTN4-ZDoKRg>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [6tisch] 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: Sat, 23 Jan 2016 08:36:45 -0000

Hi Pascal,


The source routing optimization done by dropping the addresses on the way
certainly has benefits. However, there could be loss of a natural 
"symmetric"
property that one might want to enforce between communicating end nodes 
in the
routing path. By symmetry I mean using the same path in both the 
directions of
communication. Policy based routing, centralized routing, for instance, 
could
be potential users of this property. May be this does not represent a common
use case. But nevertheless, we have to be aware of this side effect 
which RFC6554
swapping process does not have.

Going further, the DAO projection proposal
(draft-thubert-roll-dao-projection-02.txt) will have several virtual roots
inside the RPL domain. The automatic assumption of a well known root may 
not apply
when nodes within RPL domain communicate with each other. I suppose it will
have a bearing on the RH3-6LoRH performance.

The above observations are not serious, but feels good to ponder over. 
Will be
happy to receive your comments.

Anand





On Monday 18 January 2016 11:24 PM, Pascal Thubert (pthubert) wrote:
>  > Dear all > > > > The picture below illustrates how the RH3 6LoRH 
works with draft 03 in a case like Root -> A -> B -> C -> leaf > > > > > 
 > The first 6LoRH is expected to be a full address (128 bits) to set up 
a reference and the next 6LoRH are expected to be smaller and just 
override the rightmost bits which form the delta from the reference. > > 
 > > Proposal: we could consider that the 128bits source of the IP 
header before the RH3 is the reference to start with. > > > > With that 
even the first hop could be compressed the same way as the other hops. 
With RPL, the root is the encapsulator if IP in IP in used. Good thing, 
in that case the root is totally elided with the IP-in-IP 6LoRH. > > > > 
So this simple proposal saves up to 16 octets (thats in the case with a 
single subnet and all addresses differ only by the last 2 bytes). Im 
willing to add it in the next revision. > > > > Any opposition? > > > > 
Pascal > > > > -- > This message has been scanned for viruses and > 
dangerous content by MailScanner, and is > believed to be clean. > > 
_______________________________________________ > 6tisch mailing list > 
6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.