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

Tengfei Chang <> Tue, 19 January 2016 08:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 506391B2B8F; Tue, 19 Jan 2016 00:28:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GhxYcD-Cb7Oy; Tue, 19 Jan 2016 00:28:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1565D1B2B90; Tue, 19 Jan 2016 00:28:00 -0800 (PST)
Received: by with SMTP id a85so561861188ykb.1; Tue, 19 Jan 2016 00:28:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sZzFxmrMdIIU8fKje9jmFyvsHSUxDoxk93B/dUZDauk=; b=tsoxyHhCPJm8MSgeKYOAxXSUesYRFbTB1yf3dIoNXMU0rFzMCCmbhAFQGJHS87c4Y8 +Q3qS2KRhpAXRxdab7po6/RhPeopbcxvJqGT02yBgaNMUqtqnmda+OCKaaKInrM6KkBS 4pcSQY4fNunucjA5nChgIagdwTw/nYr1Oc6RZ6t9It2y1Ig3yhG1coNeBRQ5bv59N/x1 tXKCd8EgYoQDVc+kT+4ltf8IStBvZsf+xfJltpdwgros3kkvJpzDYU8MqYc5U1ClTtyW b/TDlBnv9H/kIpwBJ5R3wGwj61EgX1unKuKbcF7Sa9QAl2yyqeVX9HcOd+ooyG80A5kG MCIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sZzFxmrMdIIU8fKje9jmFyvsHSUxDoxk93B/dUZDauk=; b=Koot1QKWFLn3AqJDVq2162KoU74hnjq8JKWbnVjBONl3lb1KKgLwjLKtTPlzanUPke bnyC0wVPBA3gx+qkchrjFWxutgdSGLBz5Xan8vZozdeuiZpftkhubj7TYpzl184kERkd C4ba42h+qo2N/AkiCa+auQoacakpAAUZIm35XQBqWcOZ/zNopwbpP2DkiNdgzA8WocCe 9eqdnwIv7EBAINwGE1taEfeofHn5Ch9cV1WMtCZ16zW02n/CvmcD9fYTf21VnFDL8omD yZPZPQe9v1D/M94M+n3EbZTMGSOFrgOC8f4hHsLBJdR7guyk5cGr0J7JyiN+nFXa6w0N lJnA==
X-Gm-Message-State: ALoCoQnzfPjJwu8o0RgLKqgEKu5pS7QfRaykgu6539bcBoliAt07zksj3ev9DkAiZI6f02rX5Qc7jDxwjXuZz71BtZpVmjaQEA==
MIME-Version: 1.0
X-Received: by with SMTP id d185mr7187716ybd.109.1453192079332; Tue, 19 Jan 2016 00:27:59 -0800 (PST)
Received: by with HTTP; Tue, 19 Jan 2016 00:27:59 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Tue, 19 Jan 2016 09:27:59 +0100
Message-ID: <>
From: Tengfei Chang <>
To: "Pascal Thubert (pthubert)" <>
Content-Type: multipart/related; boundary=001a11428d0eae340c0529aba514
Archived-At: <>
Cc: "" <>, Routing Over Low power and Lossy networks <>, "" <>
Subject: Re: [6tisch] Proposed improvement in RH3-6LoRH
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Jan 2016 08:28:02 -0000

HI Pascal,

Thanks for the figures! I have some comments inline with blue text.

On Mon, Jan 18, 2016 at 6:54 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.

What if the B and C address can be compressed to one byte(RH3-6LoRH type
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)*
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)*

> 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)

> 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?

> 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)

> Any opposition?
> Pascal
Thanks for the proposal!

> _______________________________________________
> 6tisch mailing list