I’m taking that back Tengfei;
I think that the original proposal
MAC RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH IPHC blah
Works better
Reason:
1) When there is no IP in IP , then the encoding is for instance
MAC RPI-6LoRH IPHC blah
Or
MAC RH3-6LoRH* IPHC blah
Which hints that we write headers in the reverse order so the IP header
terminates an encaps
2) One needs to differentiate a case that in uncompressed for is
IP-in-IP RPI RH3 IP blah
From
IP-in-IP IP RPI RH3 blah
With a format like
MAC IP-in-IP-LoRH RH3-6LoRH* RPI-6LoRH IPHC blah
You cannot tell
3) We modify the RH3-6LoRH on the way, popping the first address as we go.
It is easier to do if it is the first header of the compressed packet so we
always play with the very beginning of the packet
4) With this format we can do IP in IP in IP like
MAC RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH RH3-6LoRH* RPI-6LoRH IP-in-IP-LoRH
IPHC blah
The separation of which header is in which encaps is clearly
delineation with the IP header that terminates the encapsulated 6LoRH-headers.
Does that work?
Cheers,
Pascal
From: Pascal Thubert (pthubert)
Sent: jeudi 21 janvier 2016 17:57
To: 'Tengfei Chang' <[email protected]>
Cc: [email protected]; [email protected]
Subject: RE: [6tisch] The "BEFORE" and "AFTER"
Hello Tengfei:
I think we agreed from the start. In the packet you find
Mac then IP-in-IP-6LoRH then RPI-6LoRH then X* RH3-6LoRH then IPHC etc ….
There may be several times the sequence ip-in-up to RH3 if we have ip in ip in
ip though I have no idea today who would use that.
Are we all Ok that I add text to enforce that order?
Pascal
From: Tengfei Chang [mailto:[email protected]]
Sent: jeudi 21 janvier 2016 16:30
To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
Subject: Re: [6tisch] The "BEFORE" and "AFTER"
Dear Pascal,
I am confused again on the order of headers in the packets.
For example, the packet:
MAC header + (......) + ICMPv6,
The words "IP in IP then RPI then 6LoRH" equals to "MAC header + (6LoRH
IPinIP, 6LoRH-RPI, 6LoRH RH3, IPHC) + ICMPv6",
which we says RPI is RIGHT AFTER IPinIP is the first way I mentioned in the
beginning of this email, no?
Tengfei
On Wed, Jan 20, 2016 at 9:45 PM, Pascal Thubert (pthubert)
<[email protected]<mailto:[email protected]>> wrote:
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.
Works?
Cheers,
Pascal
From: Tengfei Chang
[mailto:[email protected]<mailto:[email protected]>]
Sent: mercredi 20 janvier 2016 14:22
To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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!
Tengfei
On Wed, Jan 20, 2016 at 10:52 AM, Pascal Thubert (pthubert)
<[email protected]<mailto:[email protected]>> 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?
Pascal
From: 6tisch [mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Tengfei Chang
Sent: mercredi 20 janvier 2016 09:20
To: [email protected]<mailto:[email protected]>
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?
Thanks
Tengfei
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
