Subject: Re: [Roll] [6lo] RPL artifact compression discussion

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 16:40:18 -0400

There are three important parts of this problem.
1) what headers ("artifacts") are actually required.  This is subject to a
   not-yet created ROLL document that the virtual interim meeting revealed
   was missing.  The summary is we need RPI (RFC6553) on the way up and down,
   in order to find loops, and carry the RPL InstanceID.  The InstanceID is
   an extra input to the routing process, and distinguishes one DAG from
   another.
   We need to have the RH3 on downward traffic in the non-storing case, as
   this header provides the source routes.
   As the RPI and RH3 are inserted, in order to do this an IPIP header is
   required. 

2) there are various proposals as to the method to compress the artifacts
   themselves, and this part is subject to various discussion.

3) the 6lo part is that we need a way to signal that the compression in part
   (2) is actually being used.
   
There are three options on how to introduce new compression mechanisms into
the 6lowPAN/ROLL data plane.

1) draft-thubert-6lo-rpl-nhc
   originally proposal to add a new 6282 Next Header Compression for just 6553.
   from that document:
      (Discuss: Is this really an update of RFC 6282 or a straightforward
       addition to it?)
   the answer is that RFC6282 has an IANA registry, and the allocation policy
   is IETF Review.

   In this document, I would suggest that the Greedy approach probably is
   more a simple allocation (it's an update!), as it uses so much.
   
   The conservative approach is a simple registration, it takes a single
   value from the 11111000 to 11111110 range for the 6554.
   (Note 6lo-rpl-nhc-02 says "Section 4.2 of [RFC6553] defines LOWPAN_NHC
   encodings", but actually it's defined in 6282)

   The efficient approach, I guess, optimizes some common cases at the cost
   of one or more bytes extra for the non-common cases.

   1b) NHC++ as noted below, there is no method defined to compress the IPv6
       inner header, and no method to compress the RH3 (RFC6554) header
       was defined.  The NHC++ proposal suggests to expand this proposal to
       do this.  It can perhaps be done in the greedy approach with
       some thought, but it seems unlikely to fit, and the conservative
       approach would be required.
       
       Note that there aren't enough EIDs to encode each of IPIP, RH3 and
       RPI, but as the IPIP is not seen unless there is also an RH3 and/or
       RPI, the IPIP pieces that would follow could perhaps be implied 

2) draft-thubert-6lo-routingdispatch

   The NHC method above adds additional nexthops, but does not change
   anything about the outer IPv6 header.  It would continue to be compressed
   with 6282's LOWPAN_IPHC, and unfortunately, as there is no Next
   Header=LOWPAN_IPHC,  the second (inner from the wild, likely more random),
   header can not be compressed.
   
   This method instead replaces the LOWPAN_IPHC with a new compression of
   the IPv6 header, plus 6553, plus 6554, plus inner IPv6.
   This occurs at the "dispatch" level, which also is where the 6LowPAN
   fragmentation occurs, which means that in theory with this method, one
   could route 6lo fragments individually, across the LLN rather than having
   to reassemble them hop-by-hop.

   To do this optimally, it takes the 10xxxxx encodings
   which are defined in rfc4944 Figure 2, and re-defines them.
   It does this with the knowledge from above that mesh-under and route-over
   networks will never occur on the same PANID.  Whether or not this is
   acceptable is THE significant question for the 6lo WG.

   Note that this is not entirely necessary: we can instead use the
   011 111111 "ESC" header, which lets us have another byte for dispatch
   headers.

Summary:
   1) NHC++ method using conservative approach costs the 1 or 2 code points
      from the NHC EID space (there are only 2 left).  Using 1 code point
      means adding adjusting the format to switch on next header
      being RPI, RH3 or (compressed) IPIP [LOWPAN_IPHC].  There are three
      reserved bits show in 6low-nhc-02, section 4.3.2.

   2) routingdispatch section is much more flexible, and at the cost of
      the additional byte, there is no conflict with existing users.
      But this is in some sense a forklift upgrade on RFC6282.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Mar 2015 16:01:25 -0500

>       (Discuss: Is this really an update of RFC 6282 or a straightforward

No need to discuss, it is just an extension.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Mon, 23 Mar 2015 21:51:48 +0000

Hi Michael,

Comments inline.

Robert

>       (Discuss: Is this really an update of RFC 6282 or a straightforward

<RCC>It's an extension as Carsten says.</RCC>

>    1b) NHC++ as noted below, there is no method defined to compress the
       inner header,

<RCC>There is - it's IPHC. You can use IPHC twice as we discussed in the
recent call.</RCC>

and no method to compress the RH3 (RFC6554) header
>        was defined.

<RCC>Yes - this is missing.</RCC>

> The NHC++ proposal suggests to expand this proposal to

<RCC>It is possible the efficient approach can be used as well as that
would be aimed mainly at RPI. Perhaps there is scope for applying the same
method to RH3.</RCC>

>    header can not be compressed.

<RCC>It can, as shown in the recent call</RCC>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2015 18:48:48 -0400

Robert Cragie <[email-masked]> wrote:
    > <RCC>There is - it's IPHC. You can use IPHC twice as we discussed in
    > the recent call.</RCC> 

Thank you for your reply, and reminding me that I didn't followup with you on
this question.   So, I'm not really sure how you signal this.

This is what I see at this time:

15.4 header stuff.
Dispatch    = LOWPAN_IPHC (0b1110 111N).      (rfc6282. section 4/5)
            here we want to put another compress header, so N=1.
            base format, with "NH=1"
                 NHC_1=0b1110 EID NH      EID=5,NH=1
            = here we would have RPI
                 NHC_2=???

Now if NHC_2 = 7, then an IPIP header follows.
If the NHC_1's NH=0, then an entire byte follows for something that
doesn't fit into the EID (e.g. IPsec ESP).

I don't know I signal that what follows the RPI isn't an IPv6 header
(uncompressed), but rather another LOWPAN_IPHC.

Maybe you have a better way of presenting this detail.

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

---

From: Robert Cragie <[email-masked]>
Date: Tue, 24 Mar 2015 00:03:05 +0000

The best way I can think of is to show what Wireshark shows:

6LoWPAN
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version,
traffic class, and flow label compressed (0x0003)
        .... .1.. .... .... = Next header: Compressed
        .... ..00 .... .... = Hop limit: Inline (0x0000)
        .... .... 0... .... = Context identifier extension: False
        .... .... .0.. .... = Source address compression: Stateless
        .... .... ..11 .... = Source address mode: Compressed (0x0003)
        .... .... .... 0... = Multicast address compression: False
        .... .... .... .0.. = Destination address compression: Stateless
        .... .... .... ..11 = Destination address mode: Compressed (0x0003)
        [Source context: fe80:: (fe80::)]
        [Destination context: fe80:: (fe80::)]
    Hop limit: 255
    Source: fe80::ff:fe00:3344 (fe80::ff:fe00:3344)
    Destination: fe80::ff:fe00:1122 (fe80::ff:fe00:1122)
    IPv6 extension header
        1110 .... = Pattern: IPv6 extension header (0x0e)
        .... 000. = Header ID: IPv6 hop-by-hop options (0x00)
        .... ...1 = Next header: Compressed
        Header length: 6
        Data (6 bytes)

0000  63 04 00 01 00 02                                 c.....
    IPv6 extension header
        1110 .... = Pattern: IPv6 extension header (0x0e)
        .... 111. = Header ID: IPv6 header (0x07)
        .... ...0 = Next header: Inline
    IPHC Header
        011. .... = Pattern: IP header compression (0x03)
        ...1 1... .... .... = Traffic class and flow label: Version,
traffic class, and flow label compressed (0x0003)
        .... .0.. .... .... = Next header: Inline
        .... ..00 .... .... = Hop limit: Inline (0x0000)
        .... .... 0... .... = Context identifier extension: False
        .... .... .1.. .... = Source address compression: Stateful
        .... .... ..10 .... = Source address mode: 16-bits inline (0x0002)
        .... .... .... 0... = Multicast address compression: False
        .... .... .... .1.. = Destination address compression: Stateful
        .... .... .... ..10 = Destination address mode: 16-bits inline
(0x0002)
        [Source context: 2002:db8:: (2002:db8::)]
        [Origin: 144]
        [Destination context: 2002:db8:: (2002:db8::)]
        [Origin: 144]
    Next header: ICMPv6 (0x3a)
    Hop limit: 63
    Source: 2002:db8::ff:fe00:5566 (2002:db8::ff:fe00:5566)
    Destination: 2002:db8::ff:fe00:1122 (2002:db8::ff:fe00:1122)
Internet Protocol Version 6, Src: fe80::ff:fe00:3344 (fe80::ff:fe00:3344),
Dst: fe80::ff:fe00:1122 (fe80::ff:fe00:1122)
Internet Protocol Version 6, Src: 2002:db8::ff:fe00:5566
(2002:db8::ff:fe00:5566), Dst: 2002:db8::ff:fe00:1122
(2002:db8::ff:fe00:1122)

Not sure if that helps but at least you should be able to work through it.
In essence, in this particular case (ZigBee IP going up the DODAG), it
looks like:

| IPHC outer, NHC = RPI | RPI, NHC = IPV6 | IPHC inner, NH inline | ICMPv6
| Payload |

There is the following text at the end of section 4.2 in RFC6282:

"When the identified next header is an IPv6 Header (EID=7), the NH bit of
the LOWPAN_NHC encoding is unused and MUST be set to zero.  The following
bytes MUST be encoded using LOWPAN_IPHC as defined in Section 3."

This allows IP-in-IP using IPHC compression.

Robert

On 23 March 2015 at 22:48, Michael Richardson <[email-masked]> wrote:

> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Mar 2015 10:26:38 -0400

> .... ...0 = Next header: Inline

What I see here is that when EID=7, that the thing following
is a compressed IPHC.  Is it even possible to have a non-compressed IPv6
header?  Maybe one can do NH=1, and then have an explicit NH=41 byte?

    > This allows IP-in-IP using IPHC compression.

So, in the NHC+ case, we could just define a way to compress RH3, which would
consume the remaining EID value (along with using EID=5 for RPI).  That would
result in a chain of four seperately compressed artifacts.
In my view, the ideal NHC++ proposal (not yet described), might compress all
of the artifacts in a single pass, potentially saving many more bytes.