Re: [Roll] [6tisch] Proposed improvement in RH3-6LoRH : To drop or not to
"S.V.R.Anand" <anand@ece.iisc.ernet.in> Sun, 31 January 2016 04:53 UTC
Return-Path: <anand@ece.iisc.ernet.in>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6473B1B3FBE for <roll@ietfa.amsl.com>; Sat, 30 Jan 2016 20:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.793
X-Spam-Level: *
X-Spam-Status: No, score=1.793 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 96N_cVkpcyOP for <roll@ietfa.amsl.com>; Sat, 30 Jan 2016 20:53:39 -0800 (PST)
Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.70]) by ietfa.amsl.com (Postfix) with SMTP id 3CB381B3FBD for <roll@ietf.org>; Sat, 30 Jan 2016 20:53:37 -0800 (PST)
Received: from ece.iisc.ernet.in (www.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (Postfix) with ESMTP id 886F1AE0278; Sun, 31 Jan 2016 10:15:20 +0530 (IST)
Received: from [10.3.1.249] ([10.3.1.249]) by ece.iisc.ernet.in (8.14.7/8.14.7) with ESMTP id u0V4o1re026865; Sun, 31 Jan 2016 10:20:01 +0530
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6lo@ietf.org" <6lo@ietf.org>
References: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com> <56A33B8B.6040201@ece.iisc.ernet.in> <2dbc5d77897c41b9a947b69907edf9b4@XCH-RCD-001.cisco.com>
From: "S.V.R.Anand" <anand@ece.iisc.ernet.in>
Message-ID: <56AD91F3.8010708@ece.iisc.ernet.in>
Date: Sun, 31 Jan 2016 10:17:47 +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: <2dbc5d77897c41b9a947b69907edf9b4@XCH-RCD-001.cisco.com>
Content-Type: multipart/alternative; boundary="------------010607050504040901060501"
X-IISc-MailScanner-Information: Please contact nethelp@serc.iisc.in for more information
X-IISc-MailScanner-ID: 886F1AE0278.A67F1
X-IISc-MailScanner: Found to be clean
X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.889, required 6.5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, HTML_MESSAGE 0.00, NO_RDNS2 0.01, RP_MATCHES_RCVD -0.00, URIBL_BLOCKED 0.00)
X-IISc-MailScanner-From: anand@ece.iisc.ernet.in
MailScanner-NULL-Check: 1454820324.40189@hAerb/9YAPAehDHj2s+JGw
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/LERnrXMrUNNh7TvoBVdFvRUGT-8>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] [6tisch] Proposed improvement in RH3-6LoRH : To drop or not to
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Jan 2016 04:53:41 -0000
Hi Pascal, Sorry for the long delay in responding your mail! I am opening up a new thread as you suggested since the topic on retaining or dropping addresses is really interesting. Thanks a lot for the detailed response for my innocuous observation on using the reverse address for the sake of using a symmetrical path. Never realized the security implications! Thanks for the reference to P2P RPL. Here is my further take on the topic. Having a symmetric path, in principle, certainly offers advantages when we want the communicating nodes to use a well-defined path that has been set up to meet the QoS requirements of an application. Such a pinned path can be appropriately provisioned with required bandwidth resources along the entire path. I found the P2P RPL very appropriate for the current discussion. What is interesting is that the Bidirectional Route presented here actually enables creating a symmetric path between end nodes by passing on the complete path information in its signaling messages. In this process, routing state is installed along the path. As you noted, keeping signaling separate from data is certainly an elegant way. There can however be contexts when in-band signaling that uses RH3 as per RFC6554 data can be more efficient than using a signaling protocol, assuming the security concerns are addressed as per RFC2460. This in-band approach is attractive when we want to set up a rapid on-the-fly symmetric path along with 6TiSCH OTF making bandwidth reservation along the way for transactional message exchanges. I am hinting at the possible PCE/NME based solution that (i) works with the RPL DODAG, (ii) considers the hop distance between the communicating node to assess energy costs, (iii) optimizes network resource availability, and finally provides right inputs for the nodes. It may well be that dropping the address is the right choice. I think I am doing too much of hand waving going on by leaving out all the essential details. Hope I managed to vaguely convey the point. I tend to feel that distributed, centralized and their combination might co-exist to optimize network resources, and therefore retaining or dropping the address in RH3-6LoRH can be made optional. Am I making sense ? Anand On Saturday 23 January 2016 02:34 PM, Pascal Thubert (pthubert) wrote: > > 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 > > > 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. > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch
- [Roll] Proposed improvement in RH3-6LoRH Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] Proposed improvement in RH3-6… Tengfei Chang
- Re: [Roll] [6tisch] Proposed improvement in RH3-6… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] Proposed improvement in RH3-6… Tengfei Chang
- Re: [Roll] [6lo] [6tisch] Proposed improvement in… Simon Duquennoy
- Re: [Roll] [6lo] [6tisch] Proposed improvement in… Simon Duquennoy
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Michael Richardson
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Simon Duquennoy
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Pascal Thubert (pthubert)
- Re: [Roll] [6lo] [6tisch] Proposed improvement in… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] Proposed improvement in RH3-6… Pascal Thubert (pthubert)
- Re: [Roll] [6lo] [6tisch] Proposed improvement in… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Simon Duquennoy
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Michael Richardson
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Michael Richardson
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Simon Duquennoy
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Michael Richardson
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Simon Duquennoy
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Simon Duquennoy
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] [6lo] Proposed improvement in… Simon Duquennoy
- Re: [Roll] Proposed improvement in RH3-6LoRH Pascal Thubert (pthubert)
- Re: [Roll] [6lo] [6tisch] Proposed improvement in… Ralph Droms
- Re: [Roll] [6lo] [6tisch] Proposed improvement in… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] Proposed improvement in RH3-6… S.V.R.Anand
- Re: [Roll] [6tisch] Proposed improvement in RH3-6… Pascal Thubert (pthubert)
- Re: [Roll] [6tisch] Proposed improvement in RH3-6… S.V.R.Anand