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

[Michael Richardson <[e-mail]>]

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 <[e-mail]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/