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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jan 2016 09:52:42 +0000

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-masked]] On Behalf Of Tengfei Chang
Sent: mercredi 20 janvier 2016 09:20
To: [email-masked]
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

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 20 Jan 2016 14:22:10 +0100

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-masked]> wrote:

> 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.
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Tengfei
> Chang
> *Sent:* mercredi 20 janvier 2016 09:20
> *To:* [email-masked]
> *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?)
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 20 Jan 2016 20:45:15 +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.

Works?

Cheers,

Pascal

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

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-masked]<mailto:[email-masked]>> wrote:
This is correct Tengfei, and quite classical.

Pascal

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

Dear all,

Thanks
Tengfei

---

From: Tengfei Chang <[email-masked]>
Date: Thu, 21 Jan 2016 16:29:32 +0100

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-masked]> 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-masked]]
> *Sent:* mercredi 20 janvier 2016 14:22
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [6tisch] The "BEFORE" and "AFTER"
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2016 10:32:19 -0500

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

So, in the case of traffic that flows from one leaf to another leaf, would
either end actually know the IP of the root?  I think that the RPL daemon
would have to program them.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Jan 2016 16:58:30 +0000

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

Sent: jeudi 21 janvier 2016 16:30

Dear Pascal,

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-masked]<mailto:[email-masked]>> wrote:
OK, let us see.

Works?

Cheers,

Pascal

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

Tengfei

Pascal

Dear all,

Thanks
Tengfei

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Jan 2016 17:26:41 +0000

Hello Michael:

The non RPL source leaf sends a packet IPHC source = self dest = other leaf.

The 6LR adds the RPI but the IPHC and whatever comes after it stay untouched and the packet flies to the root.

The root adds IP in IP 6LoRH, the updated RPI and the RH3 6LoRH(s) but still  the IPHC and whatever comes after it stay untouched.

Packet goes down, RPI is updated, RH3-LoRH get popped out.

The last router is the one that removes the last RH3-6LoRH and ideally all of the 6LoRH is the leaf is not a RPL node.

So the leaves would not need to know the root. But as you know the support of non RPL leaves has to be fully defined.

I maintain the txt based on our discussion here: https://bitbucket.org/6lo/rpi/src/master/draft-ietf-6lo-routing-dispatch-04.txt

It has grown considerably though the meaning is hopefully unchanged from 03 apart from taking the source (that’s the root, normally) as reference for RH3 compression by default and indicating more clearly that the RPI is useful even if there is a RH3.

Early review would be appreciated and if you think that your question above is insufficiently answered please let me know ( and provide text suggestions if possible ☺)

Thanks in advance!

5.  The Routing Header Type 3 (RH3) 6LoRH Header

   ## Encoding {#RH3-6LoRH-encoding}

   The Routing Header type 3 (RH3) 6LoRH (RH3-6LoRH) header is a

   Critical 6LoWPAN Routing Header that provides a compressed form for

   the RH3, as defined in [RFC6554] for use by RPL routers.  Routers

   that need to forward a packet with a RH3-6LoRH are expected to be RPL

   routers and are expected to support this specification.  If a non-RPL

   router receives a packet with a RH3-6LoRH, this means that there was

   a routing error and the packet should be dropped so the Type cannot

   be ignored.

      0                   1

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+

      |1|0|0|  Size   |6LoRH Type 0..4| Hop1 | Hop2 |     | HopN |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-    -+-    -+ ... +-    -+

            Size indicates the number of compressed addresses

                         Figure 5: The RH3-6LoRH.

   The 6LoRH Type indicates the compression level used in a given

   RH3-6LoRH header.

   One or more 6LoRH header(s) MAY be placed in a 6LoWPAN packet.

   It results that all addresses in a given RH3-6LoRH header MUST be

   compressed in an identical fashion, down to using the identical

   number of bytes per address.  In order to get different degrees of

   compression, multiple consecutive RH3-6LoRH headers MUST be used.

   Type 0 means that the address is compressed down to one byte, whereas

   Type 4 means that the address is provided in full in the RH3-6LoRH

   with no compression.  The complete list of Types of RH3-6LoRH and the

   corresponding compression level are provided in Figure 6:

     +-----------+----------------------+

     |   6LoRH   | Length of compressed |

     |   Type    | IPv6 address (bytes) |

     +-----------+----------------------+

     |    0      |       1              |

     |    1      |       2              |

     |    2      |       4              |

     |    3      |       8              |

     |    4      |      16              |

     +-----------+----------------------+

                      Figure 6: The RH3-6LoRH Types.

   In the case of a RH3-6LoRH header, the TSE field is used as a Size,

   which encodes the number of hops minus 1; so a Size of 0 means one

   hop, and the maximum that can be encoded is 32 hops.  (If more than

   32 hops need to be expressed, a sequence of RH3-6LoRH elements can be

   employed.)  It results that the Length in bytes of a RH3-6LoRH header

   is:

   2 + Length_of_compressed_IPv6_address * (Size + 1)

5.1.  RH3-6LoRH General Operation

   In the non-compressed form, when the root generates or forwards a

   packet in non-Storing Mode, it needs to include a Routing Header type

   3 (RH3) [RFC6554] to signal a strict source-route path to a final

   destination down the DODAG.  All the hops along the path, but the

   first one, are encoded in order in the RH3.  The last entry in the

   RH3 is the final destination and the destination in the IPv6 header

   is the first hop along the source-route path.  The intermediate hops

   perform a swap and the Segment-Left field indicates the active entry

   in the Routing Header [RFC2460].  The current destination of the

   packet, which is the termination of the current segment, is indicated

   at all times by the destination address of the IPv6 header.

   The handling of the RH3-6LoRH is different: there is no swap, and a

   forwarding router that corresponds to the first entry in the first

   RH3-6LoRH upon reception of a packet effectively consumes that entry

   when forwarding.  This means that the size of a compressed source-

   routed packet decreases as the packet progresses along its path and

   that the routing information is lost along the way.  This also means

   that an RH3 encoded with 6LoRH is not recoverable and cannot be

   protected.

   When compressed with this specification, all the remaining hops MUST

   be encoded in order in one or more consecutive RH3-6LoRH headers.

   Whether or not there is a RH3-6LoRH header present, the address of

   the final destination is indicated in the LoWPAN_IPHC at all times

  along the path.  Examples of this are provided in Appendix A.

   The current destination (termination of the current segment) for a

   compressed source-routed packet is indicated in the first entry of

   the first RH3-6LoRH.  In strict source-routing, that entry MUST match

   an address of the router that receives the packet.

   The last entry in the last RH3-6LoRH is the last router on the way to

   the final destination in the LLN.  It is typically a RPL parent of

   the final destination, but it can also be a router acting at 6LR

   [RFC6775] for the destination host.

5.2.  Compression Reference

   In order to optimize the compression of IP addresses present in the

   RH3 headers, this specification requires that the 6LoWPAN layer

   identifies an address that is used as reference for the compression.

   With this specification, the Compression Reference for addresses

   found in an RH3 header is the source of the IPv6 packet.

   With RPL [RFC6550], an RH3 header may only be present in Non-Storing

   mode, and it may only be placed in the packet by the root of the

   DODAG, which must be the source of the resulting IPv6 packet

   [RFC2460].  In this case, the address used as Compression Reference

   is that the address of the root, and it can be implicit when the

   address of the root is.

   The Compression Reference MUST be determined as follows:

   The reference address may be obtained by configuration.  The

   configuration may indicate either the address in full, or the

   identifier of a 6LoWPAN Context that carries the address [RFC6775],

   for instance one of the 16 Context Identifiers used in LOWPAN-IPHC

   [RFC6282].

   Else, and if there is no IP-in-IP encapsulation, the source address

   in the IPv6 header that is compressed with LOWPAN-IPHC is the

   reference for the compression.

   Else, and if the IP-in-IP compression specified in this document is

   used and the Encapsulator Address is provided, then the Encapsulator

   Address is the reference.

5.3.  Coalescence

   An IPv6 compressed address is coalesced with a reference address by

   overriding the N rightmost bytes of the reference address with the

   compressed address, where N is the length of the compressed address,

   as indicated by the Type of the RH3-6LoRH header in Figure 6.

   The reference address MAY be a compressed address as well, in which

   case it MUST be compressed in a form that is of an equal or greater

   length than the address that is being coalesced.

   A compressed address is expanded by coalescing it with a reference

   address.  In the particular case of a Type 4 RH3-6LoRH, the address

   is expressed in full and the coalescence is a complete override as

   illustrated in Figure 7.

   RRRRRRRRRRRRRRRRRRRR reference address, may be compressed or not

                CCCCCCC compressed address, shorter or same as reference

   RRRRRRRRRRRRRCCCCCCC Coalesced address, same compression as reference

                      Figure 7: Coalescing addresses.

5.4.  Popping Headers

   Upon reception, the router checks whether the address in the first

   entry of the first RH3-6LoRH one of its own addresses.  In that case,

   router MUST consume that entry before forwarding, which is an action

   of popping from a stack, where the stack is effectively the sequence

   of entries in consecutive RH3-6LoRH headers.

   Popping an entry of an RH3-6LoRH header is a recursive action

   performed as follows:

   If the Size of the RH3-6LoRH header is 1 or more, indicating that

   there are at least 2 entries in the header, the router removes the

   first entry and decrements the Size (by 1).

   Else (meaning that this is the last entry in the RH3-6LoRH header),

   and if there is no next RH3-6LoRH header after this then the

   RH3-6LoRH is removed.

   Else, if there is a next RH3-6LoRH of a Type with a larger or equal

   value, meaning a same or lesser compression yielding same or larger

   compressed forms, then the RH3-6LoRH is removed.

   Else, the first entry of the next RH3-6LoRH is popped from the next

   RH3-6LoRH and coalesced with the first entry of this RH3-6LoRH.

   At the end of the process, if there is no more RH3-6LoRH in the

   packet, then the processing node is the last router along the source

   route path.

5.5.  Forwarding

   When receiving a packet with a RH3-6LoRH, a router determines the

   IPv6 address of the current segment endpoint.

   If strict source routing is enforced and thus router is not the

   segment endpoint for the packet then this router MUST drop the

   packet.

   If this router is the current segment endpoint, then the router pops

   its address as described in Section 5.4 and continues processing the

   packet.

   If there is still a RH3-6LoRH, then the router determines the new

   segment endpoint and routes the packet towards that endpoint.

   Otherwise the router uses the destination in the inner IP header to

   forward or accept the packet.

   The segment endpoint of a packet MUST be determined as follows:

   The router first determines the Compression Reference as discussed in

   Section 5.3.

   The router then coalesces the Compression Reference with the first

   entry of the first RH3-6LoRH header as discussed in Section 5.2.  If

   the type of the RH3-6LoRH header is type 4 then the coalescence is a

   full override.

   Since the Compression Reference is an uncompressed address, the

   coalesced IPv6 address is also expressed in the full 128bits.

   Packet as received by node A

   ----------------------------

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA

     Type 1 RH3-6LoRH Size = 0                  BBBB

     Type 2 RH3-6LoRH Size = 1             CCCC CCCC

                                           DDDD DDDD

    Step 1 popping BBBB the first entry of the next RH3-6LoRH

    Step 2 next is if larger value (2 vs. 1) the RH3-6LoRH is removed

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA

     Type 2 RH3-6LoRH Size = 1             CCCC CCCC

                                           DDDD DDDD

    Step 3: recursion ended, coalescing BBBB with the first entry

    Step 4: routing based on next segment endpoint to B

   Packet as received by node B

   ----------------------------

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB

     Type 2 RH3-6LoRH Size = 1             CCCC CCCC

                                           DDDD DDDD

    Step 1 popping CCCC CCCC, the first entry of the next RH3-6LoRH

    Step 2 removing the first entry and decrementing the Size (by 1)

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB

     Type 2 RH3-6LoRH Size = 0             DDDD DDDD

    Step 3: recursion ended, coalescing CCCC CCCC with the first entry

    Step 4: routing based on next segment endpoint to C

   Packet as received by node C

   ----------------------------

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC

     Type 2 RH3-6LoRH Size = 0             DDDD DDDD

    Step 1 popping DDDD DDDD, the first entry of the next RH3-6LoRH

    Step 2 the RH3-6LoRH is removed

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC

    Step 3: recursion ended, coalescing DDDD DDDDD with the first entry

    Step 4: routing based on next segment endpoint to D

   Packet as received by node D

   ----------------------------

     Type 3 RH3-6LoRH Size = 0   AAAA AAAA DDDD DDDD

    Step 1 the RH3-6LoRH is removed.

    Step 2 no more header, routing based on inner IP header.

               Figure 8: Forwarding packets with RH3-6LoRH.

Cheers,

Pascal

> -----Original Message-----

> From: 6lo [mailto:[email-masked]] On Behalf Of Michael Richardson

> Sent: jeudi 21 janvier 2016 16:32

> To: [email-masked]; [email-masked]

> Subject: Re: [6lo] [6tisch] The "BEFORE" and "AFTER"

> Ideally

>     > address in the RH3. This is a change from the original text where I

> expected

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2016 15:06:37 -0500

> and the packet flies to the root.

I think that we went through this in useofrpi....

I read the above sentence to say that the packet format is supposed to be:
    IP2 RPI IP1 ULP

which means that the the IP2 must say "6LR" to "Root", which implies that the
6LR knows what the root is.   That's an unavoidable interaction between RPL
and the IPv6 forwarding stack, and this is where I claim it's now about
6lowpan, but rather about mesh-over.

I think that for a locally generated packet, a
smart stack doesn't build those headers, but rather speaks directly to the
6LoRH part of the 6lowpan stack, and says:
      IPsrc=ME, IPdst=THEM, RPLroot=him

    > The root adds IP in IP 6LoRH, the updated RPI and the RH3 6LoRH(s) but still
    > the IPHC and whatever comes after it stay untouched.

The root removes the IP/RPI, and adds IP3/RH3. (We agreed that the RPI is
perhaps unnecessary).  IP3 = RPL hop before "THEM", which root knows.

I will read the rest of the text.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Jan 2016 08:25:30 +0000

Hello Michael

Please see inline

> 6lowpan, but rather about mesh-over.

It is. The 6LR will have to decide which topology is used for that packet and encaps to the right root with the right RPI. This is no surprise. 

> I think that for a locally generated packet, a smart stack doesn't build those
> headers, but rather speaks directly to the 6LoRH part of the 6lowpan stack,
> and says:

Yes

> I will read the rest of the text.

The RPI is necessary to decide what the root is when the root is elided (at least if there is a possible confusion) I hope  that you'll find that the new text is clear on that.

About stack interaction, I see the compression of the root as a new instance of stateful compression:

With RFC6282, the state is provided to the stack by NDP, and NDP exchanges it through 6LoWPAN Context Option in RAs. In the compressed packet, the context is indexed by a Context Identifier Extension. 

With 6LoRH,  the state is provided to the stack by RPL, and NDP exchanges it through DODAGID in  DIO. In the compressed packet, the context is indexed by InstanceID in RPI. 

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Jan 2016 08:39:30 +0000

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-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [6tisch] The "BEFORE" and "AFTER"

Hello Tengfei:

Pascal

Dear Pascal,

For example, the packet:

Tengfei

Works?

Cheers,

Pascal

Tengfei

Pascal

Dear all,

Thanks
Tengfei