Subject: [6lo] I-D.thubert-6lo-routing-dispatch

From: James Woodyatt <[email-masked]>
Date: Thu, 8 Jan 2015 13:28:57 -0800

Everyone—

I have some comments to make about this draft as a participating individual.

I'm not convinced that repurposing the RFC 4944 Mesh Header is necessary,
and the draft offers no explanation for choosing that direction. It seems
to me that using LOWPAN_NHC for compressing both the RPI option and the RH3
option, and LOWPAN_IPHC for compressing IP-in-IP headers, would have been
the intuitively obvious approach to take, and I don't understand why
stepping on the Mesh Header instead was the approach taken here.

Yes, usage of the MESH codes is not well specified in any standards track
documents, but I contend that deprecating their definition in RFC 4944
should not be done in the same action as defining their new standard
purpose. That's a procedural argument, but I have technical concerns too.

My first observation is that this draft lifts some hop-by-hop and routing
header extensions out of the IPv6 datagram in which they are encapsulated.
So, that means if I'm looking at a RFC 6282 packet today, and I want to
find the IPv6 header, thenI can look at the dispatch type and if it's IPv6,
then I've got the uncompressed packet right there, and if it's LOWPAN_IPHC,
then I've got the start of the compressed version. Full stop. With this
draft, though, I don't actually find the LOWPAN_IPHC until I've first
traversed the preceding chain of 6LoRH headers, all of which I have to
remember because they will be necessary in the decompression of the
encapsulated IPv6 packet. That's complicated and eats CPU resources.

My second observation is that it's a simple process today to define a
general IPv6 extension, then to define a 6LoWPAN compression scheme in
another separable step. New extension headers go inside LOWPAN_NHC and all
you need to do is define how to compress them when NH=1. This draft
complicates all that by adding a new scheme to the existing mix, where all
manner of extension headers might be compressed in 6LoRH headers with new
type codes to be defined in the future. Each new extension header needs a
new 6LoRH header type defined for it in addition to the new compression
scheme, and the 6LoRH header type is a small number space, so it will be
subject to additional conservative pressure.  This means defining a new
IPv6 extension really isn't complete until you've said something about how
6LoRH headers are used with it. To be honest, I think that 6MAN should be
consulted for their considerations about that.

Lastly, I observe that offline analysis of 6LoWPAN packets will be
complicated by the fact that it's not possible to identify from the bits in
the packet whether it was encoded according to RFC 4944 and the MESH header
was used, or if it was encoded according to this draft and the 6LoRH header
was used. What is Wireshark supposed to do when it dissects a 6LoWPAN
encoded octet stream and it sees what is currently marked as a MESH header
dispatch? Assume it knows better than the encoder what it used? Ask the
Wireshark user to decide with a modal pop-up? Please. Whatever it does will
bring unnecessary headaches.

Shorter james: I think this draft is an overly complicated solution to the
problem it proposes to solve, and I see little benefit in trading that
complication for whatever it is I'm supposed to get in trade for it. Which
is what, again?

I get that it would be nice if IETF had defined those MESH codes in the
dispatch header better, but I think it makes more sense to reclaim those
codes in a two-phase procedure: phase one, deprecate the Mesh Header; then
phase two, assign new semantics only when existing reserved code space has
been fully consumed. That action should be separated from the action to
solve the problems that RPL is facing today.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: James Woodyatt <[email-masked]>
Date: Thu, 8 Jan 2015 16:47:58 -0800

Everyone—

After discussing my concerns with a colleague (who was busy while I was
drafting my previous message on this topic), I now realize that I
misinterpreted the text of RFC 6282 in a way that explains why what seemed
to me like the intuitively obvious approach isn't workable.

It comes down to the fact that LOWPAN_NHC doesn't actually allow you to
define compression formats for any of the IPv6 Extension Headers. RFC 6282
*does* define a compression format for some UDP headers, but a strict
interpretation of the text doesn't leave any room for compressing the RPI
or RH3 options when preceded by a LOWPAN_NHC octet even when NH=1. (Why
not? I can imagine some reasons.)

But that's not a big problem. The slightly less intuitively obvious
approach would now seem to be to define a new LOWPAN_NHC EID code
(proposed: 5) as a Compressed IPv6 Extension Header, which would entail
that the following octet encode an identification of the compression method
with the Next Header field and the uncompressed Length field, and the
octets following that encode the rest of the compressed IPv6 Extension
Header (citing RFC 6564 informationally to drive home the point that this
eliminates the possibility of expansion).

It would then be reasonable to use the 6LO_RPI and 6LO_RH3 compressions in
the draft under construction after the LOWPAN_NHC octet instead of the
dispatch bit.  What's wrong with this?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jan 2015 07:32:24 +0000

Hello James:

It comes down to the fact that LOWPAN_NHC doesn't actually allow you to define compression formats for any of the IPv6 Extension Headers. RFC 6282 *does* define a compression format for some UDP headers, but a strict interpretation of the text doesn't leave any room for compressing the RPI or RH3 options when preceded by a LOWPAN_NHC octet even when NH=1. (Why not? I can imagine some reasons.)

I cannot remember the authors or the group making the conscious decision to bar that. What I remember is that as soon as we have a non-compressed header then the rest of the packet is uncompressed. This is what we had in mind with text like

“

   A necessary property of encoding headers using LOWPAN_NHC is that the
   immediately preceding header must be encoded using either LOWPAN_IPHC
   or LOWPAN_NHC.
”

If the text can be interpreted beyond that, it may be an escape in the writing/reviewing process, to be determined. Could you be more specific?

It seems that the text may be interpreted too extremely and it would be beneficial for the community to post an update draft to trigger a reflection on that particular matter. Either there was a good reason for the text that lead to your conclusion and it should be clarified, or we will end up improving the spec in a backward compatible way, which looks like a good idea.

Cheers,

Pascal

Everyone—

After discussing my concerns with a colleague (who was busy while I was drafting my previous message on this topic), I now realize that I misinterpreted the text of RFC 6282 in a way that explains why what seemed to me like the intuitively obvious approach isn't workable.

It comes down to the fact that LOWPAN_NHC doesn't actually allow you to define compression formats for any of the IPv6 Extension Headers. RFC 6282 *does* define a compression format for some UDP headers, but a strict interpretation of the text doesn't leave any room for compressing the RPI or RH3 options when preceded by a LOWPAN_NHC octet even when NH=1. (Why not? I can imagine some reasons.)

But that's not a big problem. The slightly less intuitively obvious approach would now seem to be to define a new LOWPAN_NHC EID code (proposed: 5) as a Compressed IPv6 Extension Header, which would entail that the following octet encode an identification of the compression method with the Next Header field and the uncompressed Length field, and the octets following that encode the rest of the compressed IPv6 Extension Header (citing RFC 6564 informationally to drive home the point that this eliminates the possibility of expansion).

It would then be reasonable to use the 6LO_RPI and 6LO_RH3 compressions in the draft under construction after the LOWPAN_NHC octet instead of the dispatch bit.  What's wrong with this?

On Thu, Jan 8, 2015 at 1:28 PM, James Woodyatt <[email-masked]<mailto:[email-masked]>> wrote:
Everyone—

I'm not convinced that repurposing the RFC 4944 Mesh Header is necessary, and the draft offers no explanation for choosing that direction. It seems to me that using LOWPAN_NHC for compressing both the RPI option and the RH3 option, and LOWPAN_IPHC for compressing IP-in-IP headers, would have been the intuitively obvious approach to take, and I don't understand why stepping on the Mesh Header instead was the approach taken here.

Yes, usage of the MESH codes is not well specified in any standards track documents, but I contend that deprecating their definition in RFC 4944 should not be done in the same action as defining their new standard purpose. That's a procedural argument, but I have technical concerns too.

My first observation is that this draft lifts some hop-by-hop and routing header extensions out of the IPv6 datagram in which they are encapsulated. So, that means if I'm looking at a RFC 6282 packet today, and I want to find the IPv6 header, thenI can look at the dispatch type and if it's IPv6, then I've got the uncompressed packet right there, and if it's LOWPAN_IPHC, then I've got the start of the compressed version. Full stop. With this draft, though, I don't actually find the LOWPAN_IPHC until I've first traversed the preceding chain of 6LoRH headers, all of which I have to remember because they will be necessary in the decompression of the encapsulated IPv6 packet. That's complicated and eats CPU resources.

My second observation is that it's a simple process today to define a general IPv6 extension, then to define a 6LoWPAN compression scheme in another separable step. New extension headers go inside LOWPAN_NHC and all you need to do is define how to compress them when NH=1. This draft complicates all that by adding a new scheme to the existing mix, where all manner of extension headers might be compressed in 6LoRH headers with new type codes to be defined in the future. Each new extension header needs a new 6LoRH header type defined for it in addition to the new compression scheme, and the 6LoRH header type is a small number space, so it will be subject to additional conservative pressure.  This means defining a new IPv6 extension really isn't complete until you've said something about how 6LoRH headers are used with it. To be honest, I think that 6MAN should be consulted for their considerations about that.

Lastly, I observe that offline analysis of 6LoWPAN packets will be complicated by the fact that it's not possible to identify from the bits in the packet whether it was encoded according to RFC 4944 and the MESH header was used, or if it was encoded according to this draft and the 6LoRH header was used. What is Wireshark supposed to do when it dissects a 6LoWPAN encoded octet stream and it sees what is currently marked as a MESH header dispatch? Assume it knows better than the encoder what it used? Ask the Wireshark user to decide with a modal pop-up? Please. Whatever it does will bring unnecessary headaches.

Shorter james: I think this draft is an overly complicated solution to the problem it proposes to solve, and I see little benefit in trading that complication for whatever it is I'm supposed to get in trade for it. Which is what, again?

I get that it would be nice if IETF had defined those MESH codes in the dispatch header better, but I think it makes more sense to reclaim those codes in a two-phase procedure: phase one, deprecate the Mesh Header; then phase two, assign new semantics only when existing reserved code space has been fully consumed. That action should be separated from the action to solve the problems that RPL is facing today.

--
james woodyatt <[email-masked]<mailto:[email-masked]>>
Nest Labs, Communications Engineering

--
james woodyatt <[email-masked]<mailto:[email-masked]>>
Nest Labs, Communications Engineering

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 09 Jan 2015 08:43:43 +0100

On 2015-01-09 08:32, Pascal Thubert (pthubert) wrote:
> If the text can be interpreted beyond that,

That provision is necessary because there is no way in an *uncompressed* 
header to indicate the presence of further compressed headers.

(But maybe I don't understand the question.)

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 09 Jan 2015 08:51:53 +0100

On 2015-01-09 01:47, James Woodyatt wrote:
> define compression formats for any of the IPv6 Extension Headers.

I'm not sure why you say this.

    A compliant implementation of [RFC4944] as updated by this document
    MUST be able to properly process a packet received that makes use of
    the provisions of this document.  A compliant implementation MAY
    implement additional LOWPAN_NHC types (Section 4) that may be
    registered (Section 5) in the future.  It is out of scope of this
    document how a compressor learns that a decompressor has additional
    capabilities.

If we register the thing, it is there.

> RFC
> 6282 *does* define a compression format for some UDP headers, but a
> strict interpretation of the text doesn't leave any room for compressing
> the RPI or RH3 options when preceded by a LOWPAN_NHC octet even when
> NH=1. (Why not? I can imagine some reasons.)

Indeed, what strict interpretation is that?

(Indeed, we cannot compress *options*, just entire headers.  But that is 
a mostly trivial limitation.)

Grüße, Carsten

---

From: James Woodyatt <[email-masked]>
Date: Fri, 9 Jan 2015 15:58:44 -0800

Carsten—

The relevant excerpt from RFC 6282 section 4.2 is near the bottom of page
15.

   NH: Next Header:

      0: Full 8 bits for Next Header are carried in-line.

      1: The Next Header field is elided and the next header is encoded
         using LOWPAN_NHC, which is discussed in Section 4.1
<http://tools.ietf.org/html/rfc6282#section-4.1>.

   For the most part, the IPv6 Extension Header is carried unmodified in
   the bytes immediately following the LOWPAN_NHC octet, with two
   important exceptions: Length field and Next Header field.

This "carried unmodified in the bytes immediately following phrase" pretty
clearly requires that IPv6 Extension Headers appear in either one of two
currently defined types: A) the entire uncompressed extension header
[including the Next Header field in the first octet, which is redundant
because it's implied by the EID code], and B) the entire uncompressed
extension header less the Next Header field in the first octet [which is
inferred from the EID code].  The "for the most part" qualifier is
dangling, but it's easy to see how it could be referring to the UDP type
which defines compression and not to the IPv6 Extension Header type, which
does not. (Though, see p4 below.)

Some observations spring to mind.

p1. Section 4.1, which is referenced in the NH=1 case, just says that there
are two currently defined types of LOWPAN_NHC, i.e. a) IPv6 Extension
Header and b) UDP. It doesn't actually say how either of them are encoded.

p2. The NH bit is just used for signaling the end of the LOWPAN_NHC chain.
However, as a colleague snarked this morning to me, there isn't really any
need for a chain of LOWPAN_NHC headers— they don't compress anything until
you get to the LOWPAN_NHC UDP header— you could have just as easily defined
the IPv6 Extension Header variant with a few bits to signal the count of
the number of extension headers to parse before finding the upper-layer
transport protocol header.

p3. There is nothing in RFC 6282 to help decide what to do when processing
LOWPAN_NHC IPv6 Extension Headers with NH=0 and the Next Header field in
the succeeding uncompressed header does not match what is implied by the
EID code. If it were my code, then I'd silently ignore the EID and use the
value from the uncompressed header, but it seems like the specification
could be more clear.

p4. The phrase "with two important exceptions: Length field and Next Header
field" is troubling to me. The following paragraph seems like it's trying
to contradict the previous statement that "the IPv6 Extension Header is
carried unmodified in the bytes immediately following" excerpt.

   The Length field contained in a compressed IPv6 Extension Header
   indicates the number of octets that pertain to the (compressed)
   extension header following the Length field.  Note that this changes
   the Length field definition in [RFC2460
<http://tools.ietf.org/html/rfc2460>] from indicating the header
   size in 8-octet units, not including the first 8 octets.  Changing
   the Length field to be in units of octets removes wasteful internal
   fragmentation.

This seems to be the only language I can find in RFC 6282 that admits the
possibility of IPv6 Extension Headers appearing with their contents
modified by any compression method. Alas, there isn't language explaining
how any of the extension headers in RFC 2460 are to be compressed, so the
only reasonable assumption is a null compression method that allows for
alignment padding to be removed. However, what is to be done if the
Compressed Length (in octets) does not match any valid Uncompressed Length
(in 8-octet units)? Given the more clear language in the previous excerpt,
I would have to interpret that as an error and break off processing of the
packet, but I can't point to any text in the RFC to say that's what should
be done.

It's all very unclear. Nevertheless, my overarching point stands: there
ought to be a way to compress the RPI and RH3 headers and the IP-in-IP
header with only an update to RFC 6282 and not requiring an update to RFC
4494 to step on the MESH codes in the dispatch header.

On Thu, Jan 8, 2015 at 11:51 PM, Carsten Bormann <[email-masked]> wrote:

> (Indeed, we cannot compress *options*, just entire headers.  But that is a
> mostly trivial limitation.)
>
>
> Grüße, Carsten
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: "Jonathan Hui (johui)" <[email-masked]>
Date: Sat, 10 Jan 2015 08:32:03 +0000

James,

Jumping to your last point below, I agree that the most straight-forward approach to compressing RPL extension headers is with an update to RFC 6282.  I think you are being too strict in following what’s written in RFC 6282.  I would expect an update to RFC 6282 to make the necessary changes.

Some clarifications below.

On Jan 9, 2015, at 3:58 PM, James Woodyatt <[email-masked]<mailto:[email-masked]>> wrote:

The relevant excerpt from RFC 6282 section 4.2 is near the bottom of page 15.

   NH: Next Header:

      1: The Next Header field is elided and the next header is encoded
         using LOWPAN_NHC, which is discussed in Section 4.1<http://tools.ietf.org/html/rfc6282#section-4.1>.

This "carried unmodified in the bytes immediately following phrase" pretty clearly requires that IPv6 Extension Headers appear in either one of two currently defined types: A) the entire uncompressed extension header [including the Next Header field in the first octet, which is redundant because it's implied by the EID code], and B) the entire uncompressed extension header less the Next Header field in the first octet [which is inferred from the EID code].  The "for the most part" qualifier is dangling, but it's easy to see how it could be referring to the UDP type which defines compression and not to the IPv6 Extension Header type, which does not. (Though, see p4 below.)

In (A), the EID and Next Header field are not redundant.  The EID serves as the Next Header field of the *previous* compressed header.  If the NH bit in the previous header is set, then the Next Header field is elided.

In (B), Pad1 and PadN Options may be elided in certain situations.  Furthermore, the Length field specifies octets rather than multiples of 8 octets.  So the compressed form modifies the Next Header and Hdr Ext Len encoding.  If there are Pad1 and PadN options, the compressed form may also elide the trailing bytes of an IPv6 Extension Header.

p1. Section 4.1, which is referenced in the NH=1 case, just says that there are two currently defined types of LOWPAN_NHC, i.e. a) IPv6 Extension Header and b) UDP. It doesn't actually say how either of them are encoded.

Section 4.1 describes the use of a var-len NHC ID, which is the entry point to LOWPAN_NHC and UDP.  Future var-len NHC IDs may be defined in an updates draft.

p2. The NH bit is just used for signaling the end of the LOWPAN_NHC chain. However, as a colleague snarked this morning to me, there isn't really any need for a chain of LOWPAN_NHC headers— they don't compress anything until you get to the LOWPAN_NHC UDP header— you could have just as easily defined the IPv6 Extension Header variant with a few bits to signal the count of the number of extension headers to parse before finding the upper-layer transport protocol header.

I admit the existing definitions do not compress much in some cases, but they do allow the removal of Pad1 and PadN options and the 8 octet alignment requirement - which may result in up to 7 bytes savings per extension header.

p3. There is nothing in RFC 6282 to help decide what to do when processing LOWPAN_NHC IPv6 Extension Headers with NH=0 and the Next Header field in the succeeding uncompressed header does not match what is implied by the EID code. If it were my code, then I'd silently ignore the EID and use the value from the uncompressed header, but it seems like the specification could be more clear.

As mentioned above, there is no redundancy between the EID and Next Header field.

p4. The phrase "with two important exceptions: Length field and Next Header field" is troubling to me. The following paragraph seems like it's trying to contradict the previous statement that "the IPv6 Extension Header is carried unmodified in the bytes immediately following" excerpt.

   the Length field definition in [RFC2460<http://tools.ietf.org/html/rfc2460>] from indicating the header

This seems to be the only language I can find in RFC 6282 that admits the possibility of IPv6 Extension Headers appearing with their contents modified by any compression method. Alas, there isn't language explaining how any of the extension headers in RFC 2460 are to be compressed, so the only reasonable assumption is a null compression method that allows for alignment padding to be removed. However, what is to be done if the Compressed Length (in octets) does not match any valid Uncompressed Length (in 8-octet units)? Given the more clear language in the previous excerpt, I would have to interpret that as an error and break off processing of the packet, but I can't point to any text in the RFC to say that's what should be done.

RFC 6282 does not directly deal with contents being modified by alternative compression methods.  It merely provides some entry points for future encodings.  I would expect an Updates draft to handle the questions you pose above.

It's all very unclear. Nevertheless, my overarching point stands: there ought to be a way to compress the RPI and RH3 headers and the IP-in-IP header with only an update to RFC 6282 and not requiring an update to RFC 4494 to step on the MESH codes in the dispatch header.

As mentioned above, I agree with you.

—
Jonathan Hui

On Thu, Jan 8, 2015 at 11:51 PM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:
On 2015-01-09 01:47, James Woodyatt wrote:
It comes down to the fact that LOWPAN_NHC doesn't actually allow you to
define compression formats for any of the IPv6 Extension Headers.

RFC

(Indeed, we cannot compress *options*, just entire headers.  But that is a mostly trivial limitation.)

Grüße, Carsten

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

[email-masked]<mailto:[email-masked]>

---

From: James Woodyatt <[email-masked]>
Date: Mon, 12 Jan 2015 11:14:24 -0800

On Sat, Jan 10, 2015 at 12:32 AM, Jonathan Hui (johui) <[email-masked]>
wrote:

>
> In (A), the EID and Next Header field are not redundant.  The EID serves
> as the Next Header field of the *previous* compressed header.  If the NH
> bit in the previous header is set, then the Next Header field is elided.
>
[...]
> As mentioned above, there is no redundancy between the EID and Next Header

Right. I temporarily lost my mind there. It happens. Thank you for the
correction.

---

From: James Woodyatt <[email-masked]>
Date: Mon, 12 Jan 2015 11:24:02 -0800

On Sat, Jan 10, 2015 at 12:32 AM, Jonathan Hui (johui) <[email-masked]>
wrote:

>  [...]
> In (B), Pad1 and PadN Options may be elided in certain situations.
> Furthermore, the Length field specifies octets rather than multiples of 8
> octets.  So the compressed form modifies the Next Header and Hdr Ext Len
> encoding.  If there are Pad1 and PadN options, the compressed form may also
> elide the trailing bytes of an IPv6 Extension Header.
> [...]
>
Section 4.1 describes the use of a var-len NHC ID, which is the entry point
> to LOWPAN_NHC and UDP.  Future var-len NHC IDs may be defined in an updates
> draft.
> [...]
> I admit the existing definitions do not compress much in some cases, but
> they do allow the removal of Pad1 and PadN options and the 8 octet
> alignment requirement - which may result in up to 7 bytes savings per
> extension header.
>
[...]
RFC 6282 does not directly deal with contents being modified by alternative
> compression methods.  It merely provides some entry points for future
> encodings.  I would expect an Updates draft to handle the questions you
> pose above.
>

So then why didn't I-D.thubert-6lo-routing-dispatch use them? Can we see a
draft that uses these entry points instead of eating the whole range of
MESH codes out of the dispatch header?

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Jan 2015 20:41:49 +0100

On 2015-01-12 20:24, James Woodyatt wrote:
> So then why didn't I-D.thubert-6lo-routing-dispatch use them?

Because that's not the NHC draft (which does exactly that), but a quite 
different one.

Here, the idea is to use the adaptation layer to encode information that 
doesn't necessarily live in exactly that form in an IP option or 
extension.  So this isn't compression like NHC, it is something that can 
be operated on before the IP layer processing, like the old mesh header 
was intended to be.  (This is similar to how the flow label hack works 
in practice -- this one also is applied *below* the IP header that 
carries it.  The NHC approach needs an explicit IP-in-IP, which is only 
bearable because we can compress it so well; the actual processing in an 
implementation is more like the routing dispatch, though.)

BTW, I still haven't heard a cogent argument why we can't fix the mesh 
header.  (I'm not talking about the theoretical fact that we did assign 
these dispatch codes in 2007, I'm talking about any actual 
interoperability problem that might be the outcome of such a change.)

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Mon, 12 Jan 2015 15:03:00 -0500

On Jan 12, 2015, at 2:41 PM 1/12/15, Carsten Bormann <[email-masked]> wrote:

> Because that's not the NHC draft (which does exactly that), but a quite different one.
> 
> Here, the idea is to use the adaptation layer to encode information that doesn't necessarily live in exactly that form in an IP option or extension.  So this isn't compression like NHC, it is something that can be operated on before the IP layer processing, like the old mesh header was intended to be.  (This is similar to how the flow label hack works in practice -- this one also is applied *below* the IP header that carries it.  The NHC approach needs an explicit IP-in-IP, which is only bearable because we can compress it so well; the actual processing in an implementation is more like the routing dispatch, though.)

This statement seems to me to contradict something Pascal wrote in response to a question I raised on Jan 6:

>>> [RD] But ... in my opinion, moving the LLN artifacts to the header/dispatch in the way
>>> defined in draft-thubert-6lo-routing-dispatch raises, implicitly, an important
>>> architectural issue: is the information in the dispatch header compressed IPv6
>>> headers or headers for an independent, sub-IP protocol?
>> 
>> [PT] That would not be the goal, Ralph. 
>> 
>> The idea is that there is a biunivocal correspondence between the compressed and the uncompressed format.
>> The outter header with the RPL option and the RH3 (whichever are needed) would be placed in the new dispatch. 
>> But the 6LoWPAN expansion would result in the packet as it stands today.

If I understand Pascal's explanation correctly, the mesh header would carry compressed versions of the RPL and RH3 headers, which (in theory but not necessarily in implementation) would be transformed back to the uncompressed header formats (completely reconstructing the original IPv6 headers) before processing by the IPv6 stack.

> 
> BTW, I still haven't heard a cogent argument why we can't fix the mesh header.  (I'm not talking about the theoretical fact that we did assign these dispatch codes in 2007, I'm talking about any actual interoperability problem that might be the outcome of such a change.)

My concern is that carrying information needed for the operation of RPL in a sub-IP encoding that does not correspond directly to IPv6 headers used for RPL starts us down the path of defining a sub-IP protocol.  Such an architecture needs careful cross-IETF review.

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Jan 2015 21:11:20 +0100

> If I understand Pascal's explanation correctly, the mesh header would carry compressed versions of the RPL and RH3 headers, which (in theory but not necessarily in implementation) would be transfor…

Yes.  The question is, do we need to carry around an outer IP-in-IP 
header for that or not.  routing-dispatch would imply that header (it is 
never reified, except when leaving the 6lo domain).

> My concern is that carrying information needed for the operation of RPL in a sub-IP encoding that does not correspond directly to IPv6 headers used for RPL starts us down the path of defining a sub…

I'm fully with you on that point.  The counter-argument I heard so far 
was that we can't use the code points, which is a quite different 
argument, and one I can only follow in theory, not in practice.

Yes, we have to make the architectural implications of a dispatch-based 
architecture very, very clear.

E.g., when compressing RFC 6554, there is *no* need to preserve 
previously executed hops, because a non-storing node cannot make use of 
that information in any sensible way.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Mon, 12 Jan 2015 20:54:33 +0000

Comments inline.

Robert

On 12/01/2015 20:11, Carsten Bormann wrote:
>> This statement seems to me to contradict something Pascal wrote in 
>> response to a question I raised on Jan 6:
>>
>>>> The outter header with the RPL option and the RH3 (whichever are 
>>>> needed) would be placed in the new dispatch.
>> If I understand Pascal's explanation correctly, the mesh header would 
>> carry compressed versions of the RPL and RH3 headers, which (in 
>> theory but not necessarily in implementation) would be transformed 
>> back to the uncompressed header formats (completely reconstructing 
>> the original IPv6 headers) before processing by the IPv6 stack.
>
> header for that or not.  routing-dispatch would imply that header (it 
> is never reified, except when leaving the 6lo domain).
<RCC>If I have read it right, RH3-6LoRH would need an accompanying 
IP-in-IP header, presumably in the form of an IPinIP-6LoRH. But I guess 
it could also be a standard IPHC header. RPI-6LoRH would not necessarily 
need an accompanying IP-in-IP header (either IPinIP-6LoRH or IPHC) but 
would if added by a router on ingress to the mesh</RCC>
>
>>
>>>
>>> BTW, I still haven't heard a cogent argument why we can't fix the 
>>> mesh header.  (I'm not talking about the theoretical fact that we 
>>> did assign these dispatch codes in 2007, I'm talking about any 
>>> actual interoperability problem that might be the outcome of such a 
>>> change.)
>>
>> My concern is that carrying information needed for the operation of 
>> RPL in a sub-IP encoding that does not correspond directly to IPv6 
>> headers used for RPL starts us down the path of defining a sub-IP 
>> protocol.  Such an architecture needs careful cross-IETF review.
>
<RCC>I don't think it counts as a sub-IP encoding. As Pascal has 
explained there is a one-to-one correspondence (he used the (I think) 
equivalent word "biunivocal", which is not a familiar word to me) 
between the compressed address and an IPv6 address.</RCC>
>
> Yes, we have to make the architectural implications of a 
> dispatch-based architecture very, very clear.
<RCC>I think when you boil it all down, it doesn't look that much 
different to what is done in RFC 6282. It is all about placement of the 
encodings, pivoted around the first/only IPHC encoding. However, I agree 
with James that the permutations of placement are starting to look quite 
complex</RCC>
> previously executed hops, because a non-storing node cannot make use 
> of that information in any sensible way.
<RCC>I stlll don't think that makes it sub-IP as the addresses still 
represent IPv6 addresses</RCC>

---

From: James Woodyatt <[email-masked]>
Date: Mon, 12 Jan 2015 13:18:28 -0800

On Mon, Jan 12, 2015 at 12:54 PM, Robert Cragie <[email-masked]

> equivalent word "biunivocal", which is not a familiar word to me) between
> the compressed address and an IPv6 address.</RCC>

I had to look that up too. I think Pascal didn't mean "one-to-one
correspondence" [injective]. The phrase familiar to me is "bijective map"
and I think "biunivocal correspondence" is meant to be synonymous with that.

E.g., when compressing RFC 6554, there is *no* need to preserve previously
>> executed hops, because a non-storing node cannot make use of that
>> information in any sensible way.
>>

I'm reminded of the ancient debate around Realm-specific IP [RFC 3103].

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Jan 2015 08:11:48 +0000

Dear all:

This is a fantastic discussion! Thank you all for this. I agree with most of what was said, and all Robert said in particular.

About IP in IP:

Yes, we have a 6LoRH for that. The trick is that since it is optimized for a case where one of the end points is the  well-known “root” whatever that it is an abstract mesh, and clearly well-known in RPL, and the other end-point may often be the source or the destination of the inner header, in which case it can be elided in the inner header. The rest of the IP header being IP-in-IP we specify what it must be set to so we can elide it all. It results a very, very efficient compression of the outer IP header, but it is still there when we need it (e.g. we do not need it when the packet stays within the LLN), much better than would be available with 6282.

About sub IP:

I think that we really mean that at each router on the way we could restore an IP / RH3 / RPI / IP packet, and from that packet, rebuild the original 6LoRH – based compressed packet. Sorry for the unusual term, that’s my French leaking but yes I meant bijective. That would not be the RH3 that is injected by the root since the RH3 is effectively consumed on the way (the text probably needs improvements and examples but the method is there). But that would be what you’d get in the RH3 per the standard 6554 operation on that router.

Still, as Carsten points out, there is a desire to isolate the routing operation in the “mesh header” like in a “sub-IP” mesh-under protocol. With the draft, only the termination of the RH3 needs to go beyond the 6LoRH chain so whatever fragment header and IPHC after the 6LoRH are not processed by intermediate routers. The other benefit is that the IPHC code can be conserved the way it is. IOW, we would not require a change in RFC 6282 and its implementation, and the 2 codes would be kept separate. If the RH3 end point is the last router before the destination, it can remove the 6LoRH completely and the end point does not need to be upgraded or understand any RPL for that matter.

About NHC:
Yes we could also have proposed that. That would be yet another game of bits and bytes, and taking inspiration from the 6LoRH proposal we can reach something good enough that way as well. If that’s what the consensus yields, then we’ll do it. But think twice – as we did, since we started there too:
- First, working on NHC it was clear that the group is conservative with code points taken from RFC6282, so we cannot expect a lion share for RPL artifacts. The proposal extends a field which is (arguably, unsure if it is still debated) a lion share of the dispatch sub-byte. The mesh header is currently only defined for mesh-under, and more specifically for 802.15.4 and for 16 or 64bits MAC addresses. Considering that we now extend 6LoWPAN on many other MACs and support route-over, blocking all that dispatch space is simply not acceptable. We actually propose an extensible reuse of that field for route-over networks where it is virtually free space. We argue that it is also free space for non 802.15.4 MACs, and if other MACs use the 6LoRH proposal, then they can define their own TLVs for their own mesh header as well within the 6LoRH infrastructure.
- Second, backward compatibility is an identified issue that we discussed again at the last 6TiSCH interim. The 6LoRH proposal does not change RFC 6282, so the code does do not need to check for a version field, which, in fact, does not exist in the protocol.
- Third, the group is very sensitive to allowing non-RPL routing on equal grounds as RPL (see discussion on 6775-update-reqs). The proposal is extensible through TLV to additional routing artifacts that would come from another routing protocol.
- Finally, 6TiSCH wishes to support non-RPL hosts in a RPL network. In that case, it is a good idea to go beyond RFC6554 and allow the penultimate router (the 6LR for the destination) to strip all the RPL artifacts before delivery. The proposal does that by simply removing the 6LoRH, same argument and benefits as the dual IP-in-IP format. IOW, the proposal enables non-RPL leaves in a RPL network, as long as the leaves support whatever comes out of 6775-update-reqs regarding RPL needs.

Cheers,

Pascal (and Charlie)

From: 6lo [mailto:[email-masked]] On Behalf Of James Woodyatt
Sent: lundi 12 janvier 2015 22:18
To: [email-masked] WG
Cc: [email-masked]
Subject: Re: [6lo] I-D.thubert-6lo-routing-dispatch

On Mon, Jan 12, 2015 at 12:54 PM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:

<RCC>I don't think it counts as a sub-IP encoding. As Pascal has explained there is a one-to-one correspondence (he used the (I think) equivalent word "biunivocal", which is not a familiar word to me) between the compressed address and an IPv6 address.</RCC>

I had to look that up too. I think Pascal didn't mean "one-to-one correspondence" [injective]. The phrase familiar to me is "bijective map" and I think "biunivocal correspondence" is meant to be synonymous with that.

E.g., when compressing RFC 6554, there is *no* need to preserve previously executed hops, because a non-storing node cannot make use of that information in any sensible way.
<RCC>I stlll don't think that makes it sub-IP as the addresses still represent IPv6 addresses</RCC>

---

From: James Woodyatt <[email-masked]>
Date: Tue, 13 Jan 2015 10:08:51 -0800

Pascal—

Thank you for the very cogent explanation. I need to think and revise my
thoughts accordingly before responding.

On Tue, Jan 13, 2015 at 12:11 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Dear all:
>
>
>
> This is a fantastic discussion! Thank you all for this. I agree with most
> of what was said, and all Robert said in particular.
>
>
>
> About IP in IP:
>
>
>
> Yes, we have a 6LoRH for that. The trick is that since it is optimized for
> a case where one of the end points is the  well-known “root” whatever that
> it is an abstract mesh, and clearly well-known in RPL, and the other
> end-point may often be the source or the destination of the inner header,
> in which case it can be elided in the inner header. The rest of the IP
> header being IP-in-IP we specify what it must be set to so we can elide it
> all. It results a very, very efficient compression of the outer IP header,
> but it is still there when we need it (e.g. we do not need it when the
> packet stays within the LLN), much better than would be available with 6282.
>
>
>
> About sub IP:
>
>
>
> I think that we really mean that at each router on the way we could
> restore an IP / RH3 / RPI / IP packet, and from that packet, rebuild the
> original 6LoRH – based compressed packet. Sorry for the unusual term,
> that’s my French leaking but yes I meant bijective. That would not be the
> RH3 that is injected by the root since the RH3 is effectively consumed on
> the way (the text probably needs improvements and examples but the method
> is there). But that would be what you’d get in the RH3 per the standard
> 6554 operation on that router.
>
>
>
> Still, as Carsten points out, there is a desire to isolate the routing
> operation in the “mesh header” like in a “sub-IP” mesh-under protocol. With
> the draft, only the termination of the RH3 needs to go beyond the 6LoRH
> chain so whatever fragment header and IPHC after the 6LoRH are not
> processed by intermediate routers. The other benefit is that the IPHC code
> can be conserved the way it is. IOW, we would not require a change in RFC
> 6282 and its implementation, and the 2 codes would be kept separate. If the
> RH3 end point is the last router before the destination, it can remove the
> 6LoRH completely and the end point does not need to be upgraded or
> understand any RPL for that matter.
>
>
>
> About NHC:
>
> Yes we could also have proposed that. That would be yet another game of
> bits and bytes, and taking inspiration from the 6LoRH proposal we can reach
> something good enough that way as well. If that’s what the consensus
> yields, then we’ll do it. But think twice – as we did, since we started
> there too:
>
> - First, working on NHC it was clear that the group is conservative with
> code points taken from RFC6282, so we cannot expect a lion share for RPL
> artifacts. The proposal extends a field which is (arguably, unsure if it is
> still debated) a lion share of the dispatch sub-byte. The mesh header is
> currently only defined for mesh-under, and more specifically for 802.15.4
> and for 16 or 64bits MAC addresses. Considering that we now extend 6LoWPAN
> on many other MACs and support route-over, blocking all that dispatch space
> is simply not acceptable. We actually propose an extensible reuse of that
> field for route-over networks where it is virtually free space. We argue
> that it is also free space for non 802.15.4 MACs, and if other MACs use the
> 6LoRH proposal, then they can define their own TLVs for their own mesh
> header as well within the 6LoRH infrastructure.
>
> - Second, backward compatibility is an identified issue that we discussed
> again at the last 6TiSCH interim. The 6LoRH proposal does not change RFC
> 6282, so the code does do not need to check for a version field, which, in
> fact, does not exist in the protocol.
>
> - Third, the group is very sensitive to allowing non-RPL routing on equal
> grounds as RPL (see discussion on 6775-update-reqs). The proposal is
> extensible through TLV to additional routing artifacts that would come from
> another routing protocol.
>
> - Finally, 6TiSCH wishes to support non-RPL hosts in a RPL network. In
> that case, it is a good idea to go beyond RFC6554 and allow the penultimate
> router (the 6LR for the destination) to strip all the RPL artifacts before
> delivery. The proposal does that by simply removing the 6LoRH, same
> argument and benefits as the dual IP-in-IP format. IOW, the proposal
> enables non-RPL leaves in a RPL network, as long as the leaves support
> whatever comes out of 6775-update-reqs regarding RPL needs.
>
>
>
> Cheers,
>
>
>
> Pascal (and Charlie)
>
>
>
> *From:* 6lo [mailto:[email-masked]] *On Behalf Of *James Woodyatt
> *Sent:* lundi 12 janvier 2015 22:18
> *To:* [email-masked] WG
> *Cc:* [email-masked]
> *Subject:* Re: [6lo] I-D.thubert-6lo-routing-dispatch
>
>
>
> On Mon, Jan 12, 2015 at 12:54 PM, Robert Cragie <
> [email-masked]> wrote:
>
>
>
> <RCC>I don't think it counts as a sub-IP encoding. As Pascal has explained
> there is a one-to-one correspondence (he used the (I think) equivalent word
> "biunivocal", which is not a familiar word to me) between the compressed
> address and an IPv6 address.</RCC>
>
>
>