Re: [6tisch] The "BEFORE" and "AFTER"

"Pascal Thubert (pthubert)" <> Wed, 20 January 2016 20:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 768281ACE2A; Wed, 20 Jan 2016 12:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mRG7vui87X1O; Wed, 20 Jan 2016 12:45:30 -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 20D511ACE20; Wed, 20 Jan 2016 12:45:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=20818; q=dns/txt; s=iport; t=1453322730; x=1454532330; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AF/6UbIysGS4rpxlR1jx+sUHaby0nHPkyBaQBmGPz8U=; b=OQ4cuw8dlcipYb6EZhlH+TNc/LjJe/pn+uzNGleJg4aZCTWJVxRKM2hb WvX3ByUun3+wa9i8wok8UOwXSsskc0K0gYTvZMalYXtVOtepm//QZyEyp rJln3pFGhHT0rzCqETaXRaw2FrQb3bHbRDkdVzWZR4tSj5ZlaAr57BzKK M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.22,322,1449532800"; d="scan'208,217"; a="65581567"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2016 20:45:25 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u0KKjOE4008194 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 20:45:24 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 14:45:23 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Wed, 20 Jan 2016 14:45:24 -0600
From: "Pascal Thubert (pthubert)" <>
To: Tengfei Chang <>
Thread-Topic: [6tisch] The "BEFORE" and "AFTER"
Thread-Index: AQHRU1tqtnDmos6Mek2lEt0tEDasGp8EKL4QgACgQgD//7v5UA==
Date: Wed, 20 Jan 2016 20:45:15 +0000
Deferred-Delivery: Wed, 20 Jan 2016 15:27:38 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_f8d1f9064dcb4765b14d492038c1bb44XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [6tisch] The "BEFORE" and "AFTER"
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: Wed, 20 Jan 2016 20:45:32 -0000

OK, let us see.

With the new text I just proposed, the source (normally that’s the root) address of the packet with a RH3 is the reference for compression. So Ideally we’d parse that before we parse the RH3 so we can decompress the first address in the RH3. This is a change from the original text where I expected the first address in the RH3 to be mostly in the full. So in 6LoRH form,  IP in IP would come before the RH3.

With the next text, the root address may be elided but that means placing an RPI to identify it if the network has more than one instance. To decompress the IP in IP where the root is elided, one really needs the RPI. So the RPI should be next to the IP in IP. I would probably have preferred to place the RPI before the IP in IP but to look more like the uncompressed format we might place the RPI right after the IP in IP.

This would give (IP in IP then  RPI then  6LoRH *) *. With this we’d support multiple encapsulations though I cannot see where we’d need it for now.




From: Tengfei Chang []
Sent: mercredi 20 janvier 2016 14:22
To: Pascal Thubert (pthubert) <>
Subject: Re: [6tisch] The "BEFORE" and "AFTER"

Thanks pascal for explaining!

Yes, I vote to impose an order for the headers in the packet. It helps to understand the format of packet generally. Thanks a lot!


On Wed, Jan 20, 2016 at 10:52 AM, Pascal Thubert (pthubert) <<>> wrote:
This is correct Tengfei, and quite classical.

Headers are like a stack placed in front of the packet. One builds an LOWPAN-IPHC – compressed packet that does not have any RPL artifact in it. Then the RPL artifacts are added as 6LoRH headers. We have not imposed an order yet but it makes sense to place the RPI first if any, then the RH3 if any, then the 6LoRH.

Would you wish that we impose an order to simplify the parsing?


From: 6tisch [<>] On Behalf Of Tengfei Chang
Sent: mercredi 20 janvier 2016 09:20
Subject: [6tisch] The "BEFORE" and "AFTER"

Dear all,

As recently more discussion in the ML about the format of packet, sometimes we say some header after/before the IPv6 header. I would like to clarify this.

1. For me, I say with the way that mac header is the first header in the packet and then, several Routing Headers are AFTER mac header (no mesh header/fragmenet header in between).  IPHC header is AFTER those Routing Headers.

2. However, with the view of constructing a packet, IPHC is first added into packet, then RHs are placed AFTER IPHC, MAC header is constructed at the end. (I feel pascal is using this way to describe the order of header, right?)

What's the way when we describe something like this?