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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Sat, 23 January 2016 09:04 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 BF3A81B34FF; Sat, 23 Jan 2016 01:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Yv9UPFyTsSyz; Sat, 23 Jan 2016 01:04:41 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3571B34FE; Sat, 23 Jan 2016 01:04:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19707; q=dns/txt; s=iport; t=1453539880; x=1454749480; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bjg7OuXLMAVAmnihoSZneilq2SrlqyjcHgh8vygTXXw=; b=KiSgwqhRVSiiXIYKVOfjsBL79sNI83arrOZxFx82wKcO2tgLHov1eigc +uTDo4TUC7sNl1cwHfjVYLv73X1pTuFAEcKNOLOfTNC1YMhpKWpoDD8KM q+uMxhRN1IiGHpkb/QOCw8vh4/fltUdzQaKHlOUfh7asFXhwfa42gWJ7Z E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQCDQaNW/4wNJK1egm5MUm0GiFGyBwENgWIYAQmFI0oCgS04FAEBAQEBAQGBCoRBAQEBAwEBAQEkBkELBQsCAQgYJwcnCxQRAQEEAQ0FCIgLCA69cgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGMoQiS4R4CQiDfQWScoQEAY1OgWWNG4psg1IBHgEBQoF+G4FQaoVsJRZ8AQEB
X-IronPort-AV: E=Sophos; i="5.22,336,1449532800"; d="scan'208,217"; a="66374260"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jan 2016 09:04:39 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0N94dEX030628 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 23 Jan 2016 09:04:39 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 23 Jan 2016 03:04:38 -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; Sat, 23 Jan 2016 03:04:38 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "S.V.R.Anand" <anand@ece.iisc.ernet.in>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6tisch] Proposed improvement in RH3-6LoRH
Thread-Index: AdFSGKgSUfjCV02CR1+kaxeIZh+TPAD0sjSAAAxSpMA=
Date: Sat, 23 Jan 2016 09:04:27 +0000
Deferred-Delivery: Sat, 23 Jan 2016 09:03:39 +0000
Message-ID: <2dbc5d77897c41b9a947b69907edf9b4@XCH-RCD-001.cisco.com>
References: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com> <56A33B8B.6040201@ece.iisc.ernet.in>
In-Reply-To: <56A33B8B.6040201@ece.iisc.ernet.in>
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: multipart/alternative; boundary="_000_2dbc5d77897c41b9a947b69907edf9b4XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/qKHIsxaDYtMcAlaQ4Jjo1x6LciM>
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 09:04:44 -0000

Hello Anand:

2 good points , that we need to continue in different threads if we do.

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.


?  Pascal: Yes, Simon made that point yesterday.

?  It is generally not a good idea to reverse a routing header. The RH may have been used to stay away from the shortest path for some reason that is only valid on the way in (segment routing).

?  P2P RPL reverses a path that is learnt reactively, so we have a real protocol for doing that sort of thing as opposed to an echo.

?  Reversing a header is discouraged by RFC 2460 (for RH0) unless it is authenticated (which means AH). We do not authenticate the RH3, there are a number of reasons for that, general deprecation of AH, no use of AH in LLNs etc... Note that AH does not protect the RH on the way, it is just a validation at the receiver for the sole value of reversing it.

?  A RPL domain is usually protected by L2 security and that secures both RPL itself and the RH in packets, at every hop

?  The benefit of saving energy and lowering the chances of loss are seen as overwhelming compared to the value of possibly reversing the header

?  Yet we might define a variation where we do not pop out the first entry as we go. I do not see a consensus on the value of doing it now.



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.


?  It is not really an assumption, but something we leverage as we go. The RPI is very much like a context indicator. If an address shares a lon prefix with a root, adding the RPI of that root is actually a compression technique.


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

Thanks Anand!

Pascal





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<mailto:6tisch@ietf.org>
> https://www.ietf.org/mailman/listinfo/6tisch



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.