Subject: [6lo] #12 (routing-dispatch): relative Order of 6LoRH headers

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 11:29:38 -0000

#12: relative Order of 6LoRH headers

 From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert
 (pthubert)
 Sent: vendredi 22 janvier 2016 09:40
 To: Tengfei Chang <[email-masked]>
 Cc: [email-masked]; [email-masked]
 Subject: Re: [6tisch] The "BEFORE" and "AFTER"

 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:

 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-masked]]
 Sent: jeudi 21 janvier 2016 16:30
 To: Pascal Thubert (pthubert) <[email-masked]>
 Cc: [email-masked]; [email-masked]
 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-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"

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

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-6lo-routing-
  [email-masked]     |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  routing-     |    Version:
  dispatch               |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/12>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 11:30:22 -0000

#12: Relative Order of 6LoRH headers

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect              |      Status:  new
 Priority:  major               |   Milestone:
Component:  routing-dispatch    |     Version:
 Severity:  -                   |  Resolution:
 Keywords:                      |
--------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/12#comment:1>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 11:31:23 -0000

Comment (by [email-masked]):

 Added following text

 3.2.2.  Relative To other 6LoRH Headers

    IPv6 [RFC2460] defines chains of headers that are introduced by an
    IPv6 header and terminated by either another IPv6 header (IP-in-IP)
    or an Upper Layer Protocol ULP) header.  When an outer header is
    stripped from the packet, the whole chain goes with it.  When one or
    more header(s) are inserted by an intermediate router, that router
    normally chains the headers and encapsulates the result in IP-in-IP.

    With this specification, the chains of headers MUST be compressed in
    the same order as they appear in the uncompressed form of the packet.
    This means that if there is more than one nested IP-in-IP
    encapsulations, the first IP-in-IP encapsulation, with all its chain
    of headers, is encoded first in the compressed form.

    In the compressed form of a packet that has RH3 or HbH headers after
    the inner IPv6 header (e.g. if there is no IP-in-IP encapsulation),
    these headers are placed in the 6LoRH form before the 6LOWPAN-IPHC
    that represents the IPv6 header Section 3.2.1.  If this packet gets
    encapsulated and some other RH3 or HbH headers are added as part of
    the encapsulation, placing the 6LoRH headers next to one another may
    present an ambiguity on which header belong to which chain in the
    uncompressed form.

    In order to disambiguate the headers that follow the inner IPv6
    header in the uncompressed form from the headers that follow the

    outer IP-in-IP header, it is REQUIRED that the compressed IP-in-IP
    header is placed last in the encoded chain.  This means that the
    6LoRH headers that are found after the last compressed IP-in-IP
    header are to be inserted after the IPv6 header that is encoded with
    the 6LOWPAN-IPHC when decompressing the packet.

    With regards to the relative placement of the RH3 and the RPI in the
    compressed form, it is a design point for this specification that the
    RH3 entries are consumed as the packet progresses down the LLN
    Section 5.2.  In order to make this operation simpler in the
    compressed form, it is REQUIRED that the in the compressed form, the
    addresses along the source route path are encoded in the order of the
    path, and that the compressed RH3 are placed before the compressed
    RPI.

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/12#comment:2>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 11:31:37 -0000

* status:  new => closed
 * resolution:   => fixed

-- 
--------------------------------+---------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect              |      Status:  closed
 Priority:  major               |   Milestone:
Component:  routing-dispatch    |     Version:
 Severity:  -                   |  Resolution:  fixed
 Keywords:                      |
--------------------------------+---------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/12#comment:3>
6lo <https://tools.ietf.org/6lo/>

---

From: "6lo issue tracker" <[email-masked]>
Date: Sat, 23 Jan 2016 16:03:06 -0000

published with version 04

Ticket URL: <https://trac.tools.ietf.org/wg/6lo/trac/ticket/12#comment:4>
6lo <https://tools.ietf.org/6lo/>