Re: [6tisch] Proposed improvement in RH3-6LoRH
Tengfei Chang <tengfei.chang@gmail.com> Tue, 19 January 2016 12:59 UTC
Return-Path: <tengfei.chang@gmail.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 8AB141B2E1B; Tue, 19 Jan 2016 04:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 HTvHozNXO_IA; Tue, 19 Jan 2016 04:59:45 -0800 (PST)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8021B2E18; Tue, 19 Jan 2016 04:59:45 -0800 (PST)
Received: by mail-yk0-x22d.google.com with SMTP id a85so568259684ykb.1; Tue, 19 Jan 2016 04:59:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DONpDRiTLx8DHHnuynuIPzQXl4X9ZmlKi08UOSdQm5E=; b=pbScVnbfoS0ECrebYyjRyfVK3VNjmVdbg8uRDW8Lg+UtCEVA7hvkMrZhBr6kBKGQCZ 4CQMU28ahHoZYujIx57qlnL6HGMlmy7V/+sZPQA1iEqPWZ8TASuQFVJU4FEZw4/LpjdQ Kt7DOLwFJqWAHoc3lEhWvBqF7gyX6C+u69Y8pRoxhhsb76tOX6bX6hcT6mwN9akx1zHx ISL0IPfn5Tv+WsllWNlSdXTaVA/rPiSsE/k8SZN76DkJa97APFODfDKqXv+GC0QuQWYN 4W1gtCzbqowtHl53Uw3Am16LmEduibVrCdHNYnUwHaeOGCQr4rVZd5Iuv2LRJ0L64hDH rb6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DONpDRiTLx8DHHnuynuIPzQXl4X9ZmlKi08UOSdQm5E=; b=m01mi45gurNO7P11XIcUreGhHlnRbq80aenHM3GwRzMPe4HXYe2qs1tbZU2SYriAHd YTvKY0c44HWEz8/XN0XBJ9ukvRzL7WS5NDVPtaCHyUpXO/Ygyu/BP2rBcWfmUAkSyL+x kJscqizk+AzZk1xQcGJ6v9I5EbMKZ57y7bhfSaxS7stjOVWHtys9QDdSuE70cExsmAiE h7Dn2glx4ndWAoEA/M5DXQ5j9Wf4oBaTlX7hfmLeSs/VqB3lKqFfWVKyUc1NqZFXkMzI TmdjmRSIA+8V0mgSrcTXYychDYBNls0Ub0oequFPrgsOUpVeOXh8OsB8pVaE+KmWrDSX 8pTw==
X-Gm-Message-State: ALoCoQnrWhl7nuyn4a3O/lFBPIo9Ny5gaY7aCPrhuAeRrMNdkKY74U5+GuodCmYUIZgZHHMU5ft/TdfPL040GaIGc0Lxm7zHGA==
MIME-Version: 1.0
X-Received: by 10.129.123.134 with SMTP id w128mr17638321ywc.345.1453208384453; Tue, 19 Jan 2016 04:59:44 -0800 (PST)
Received: by 10.37.201.5 with HTTP; Tue, 19 Jan 2016 04:59:44 -0800 (PST)
In-Reply-To: <2c372ed593ad4d12a7ffff81c3ada270@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>
Date: Tue, 19 Jan 2016 13:59:44 +0100
Message-ID: <CAAdgstSiochR48+XVV3wCScd_XEttO0Us3rWNu=XVsO8_=kw2A@mail.gmail.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/related; boundary="001a1144fe528ad7fc0529af7177"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/hpedF_LklmcHKxax1VxoPijcY5M>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, "6lo@ietf.org" <6lo@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: Tue, 19 Jan 2016 12:59:48 -0000
Hello Pascal, Thanks a lot for the detailed answer! I think it solves all my concern. I will vote for it! Tengfei On Tue, Jan 19, 2016 at 11:00 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Tengfei: > > > > Basically the change proposal accounts for the assumption that the last > segment may be different, which comes with the idea of supporting non RPL > leaves. If you look at it the original RH4 (RFC 6554) makes a difference > for the last hop. > > > > Also, the root is the one computing the 6LoRH so it is easier for it to > take its own address as reference. > > > > Finally the text is unclear about which bits from the destination are to > be used. > > > > All in all, using the root as reference makes more sense than using the > final destination as I had initially proposed. So the new proposal is not a > merge but an instead, with clarifying text about the process I showed in > the picture. > > > > More answers inline: > > Dear all > > > > The picture below illustrates how the RH3 6LoRH works with draft 03 in a > case like Root -> A -> B -> C -> leaf > > > > [image: cid:image001.png@01D152A0.1C780E10] > > > > 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. > > > > What if the B and C address can be compressed to one byte(RH3-6LoRH type > 0)? > > When leaving the root the format would like: > > *RH3-6LoRH type 4 IPv6 Prefix (64bits) A's suffix (64bits) > RH3-6LoRH type 0 B's suffix (8bits) C's suffix (8bits)* > > > > Ø Pascal If A’s address is the same as B and C for the first 120 bits > then this format is correct : )> Pascal > > > > > > > > should node A need to extend the address of B address when the packet > leaving A? Like: > > *RH3-6LoRH type 4 IPv6 Prefix (64bits) B's suffix (64bits) > RH3-6LoRH type 0 C's suffix (8bits)* > > > > Ø Pascal: That is correct. Note that there is no separation between > prefix in suffix in the type 4. So the drawing applies for all types if you > consider that the prefix length is 64, 96, 112 or 120 depending on the type > of the next RH. With the proposal, if the root has the same /120 prefix as > A, B and C then we have a single type 0 with A, B and C in it. > > Proposal: we could consider that the 128bits source of the IP header > before the RH3 is the reference to start with. > > I have no comments with the proposal. Just want to mention in the > currently version of draft (version 3) , it says : (in section 5) > > ... > > If some bits of the first address in the RH3-6LoRH header can be > > derived from the final destination in the LoWPAN_IPHC, then that > > address may be compressed; otherwise it is expressed as a full IPv6 > > address of 128 bits. Next addresses only need to express the delta > > from the previous address. > > ... > > How to understand this combining with the proposal? (Or this is the point > we are going to replace by the proposal? Let me know) > > > > Ø Pascal: proposal is to replace. That text was unclear and more complex > to implement. And fails to optimize for leaves that are not configured > like the mesh. > > 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. > > That's great! Could I confirm when the packet is inside a RPL domain where > IP in IP is elided, the source destination in IPHC is the reference? > > Ø Pascal: Yes. The only case where IP in IP is elided is when the source > is the root. The root would still be the reference. The text I proposed > says the Source of the header that is placed before the RH3, and I meant in > the non-compressed form. With RPL as it stands today this is always the > root. > > So this simple proposal saves up to 16 octets (that’s in the case with a > single subnet and all addresses differ only by the last 2 bytes). I’m > willing to add it in the next revision. > > I don't know how to calculate the saved bytes. For this case, will the > format looks like this? > > RH3-6LoRH type 1 A's suffix (16bits) B's suffix (16bits) C's > suffix (16bits) > > Ø Pascal: Yes. In that case you save 14 bytes in A’s address plus the > RH3-6LoRH type 4 which is 2 additional bytes, 16 total. > > Any opposition? > > > > Pascal > > > > Thanks for the proposal! > > > > > > Ø Pascal: Do you vote for it? I’m asking because the plugtest is coming. > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > >
- [6tisch] Proposed improvement in RH3-6LoRH Pascal Thubert (pthubert)
- Re: [6tisch] Proposed improvement in RH3-6LoRH Tengfei Chang
- Re: [6tisch] Proposed improvement in RH3-6LoRH Pascal Thubert (pthubert)
- Re: [6tisch] Proposed improvement in RH3-6LoRH Tengfei Chang
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Pascal Thubert (pthubert)
- Re: [6tisch] Proposed improvement in RH3-6LoRH Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Michael Richardson
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Michael Richardson
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Michael Richardson
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Michael Richardson
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Simon Duquennoy
- Re: [6tisch] Proposed improvement in RH3-6LoRH Pascal Thubert (pthubert)
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Ralph Droms
- Re: [6tisch] [6lo] Proposed improvement in RH3-6L… Pascal Thubert (pthubert)
- Re: [6tisch] Proposed improvement in RH3-6LoRH S.V.R.Anand
- Re: [6tisch] Proposed improvement in RH3-6LoRH Pascal Thubert (pthubert)
- Re: [6tisch] Proposed improvement in RH3-6LoRH : … S.V.R.Anand