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

"Pascal Thubert (pthubert)" <> Tue, 19 January 2016 10:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8E3A31AD065; Tue, 19 Jan 2016 02:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Status: No, score=-14.499 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, HTML_IMAGE_RATIO_08=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I9Nxr_k0q8Rz; Tue, 19 Jan 2016 02:00:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D2FF1AD0B8; Tue, 19 Jan 2016 02:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=201799; q=dns/txt; s=iport; t=1453197629; x=1454407229; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PFdewh5V7ztOJCOE5oJEoWGl88pbHf7+dAcsgvAdOLg=; b=OwwaPRfU308OuAvPx3nSV/9HBLhhPckZVRY30APPUOCWWgOU2g9LbyT9 hS77uVBDP9A8SZX6OnOc/Ek43hcdQ0/rqlEsVs7jkriXY7/C40ySNzZJ7 pLBQ/MdMJtzlwl6juuSwxyoTYcbnOEv4e9Qh6gkw+KH7IAH0caWJhSA6c 0=;
X-Files: image002.png : 123762
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.22,316,1449532800"; d="png'150?scan'150,208,217,150";a="229152546"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2016 10:00:28 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u0JA0R1X029190 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jan 2016 10:00:27 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 19 Jan 2016 04:00:26 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Tue, 19 Jan 2016 04:00:26 -0600
From: "Pascal Thubert (pthubert)" <>
To: Tengfei Chang <>
Thread-Topic: [6tisch] Proposed improvement in RH3-6LoRH
Thread-Index: AdFSGKgSUfjCV02CR1+kaxeIZh+TPAArPBeAAAuVU6A=
Date: Tue, 19 Jan 2016 10:00:11 +0000
Deferred-Delivery: Tue, 19 Jan 2016 09:59:12 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_2c372ed593ad4d12a7ffff81c3ada270XCHRCD001ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
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 10:00:32 -0000

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


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?


Thanks for the proposal!

Ø  Pascal: Do you vote for it? I’m asking because the plugtest is coming.

6tisch mailing list<>