Subject: Re: [6lo] ascertaining RPL compression mechanism way forward

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 20 Apr 2015 11:42:20 +0000

Dear all:

Please note that for the third approach that uses white space in the FRAG area, there is a need to remap types with a TSE that needs more than 4 bits, which means that there will room taken from the type space to fill in.

This is exemplified with the RPI needs 5 bits TSE in the original approach, where I and K can be encoded in the type, which simplifies parsing at the expense of 3 types.

Highlights:

"

   This specification proposes several alternatives for the 6LoRH

   encoding:

      Reuse Mesh Header Space in route over mode

      Same as above, signaled by an initial escape byte

      a more complex encoding using other coding space that is still

      free in the 6lo adaptation layer framework

   The layout of the Elective and Critical forms depends on the encoding

   of the 6LoRH itself.

   With the Mesh Header reuse proposal, the 6LoRH reuses the bit

   patterns that are defined in [RFC4944] for the Mesh Header,

   specifically the Dispatch Value Bit Pattern of 10xxxxxx.

   With the Escaped Mesh Header reuse, the 6LoRH also reuses the bit

   patterns that are defined in [RFC4944] for the Mesh Header, but an

   ESC dispatch, with a value of 01 000000, must be placed before the

   first 6LoRH.  The ESC indicates that the parsing of the pattern of

   10xxxxxx will now be performed following this specification.  There

   is no need to place an ESC before each 6LoRH, since the ESC

   influences the parsing of the rest of the packet.

   With the third proposal, the 6LoRH uses free bit patterns that are

   defined in [RFC4944] in the 11 xxxxxx range, avoiding FRAG1 of 11

   000xxx and FRAGN of 11 100xxx.  The third bit, which differentiates

   FRAG1 from FRAGN in their particular ranges, indicates Elective vs.

   Critical, but the fourth bit is set to ensure that the 6LoRH does not

   override patterns that are already used for Fragments.  The net

   result is one bit less of encoding space in the 6LoRH, which means

   only 4 bits to encode the length in the Elective format, as discussed

   below, and only 4 bits TSE.

4.1.  Elective Format

   With the first and second proposals, the 6LoRHE uses the Dispatch

   Value Bit Pattern of 101xxxxx.

   A 6LoRHE may be ignored and skipped in parsing.

   If it is ignored, the 6LoRHE is forwarded with no change inside the

   LLN.

"

"

.1.  Elective Format

   With the first and second proposals, the 6LoRHE uses the Dispatch

   Value Bit Pattern of 101xxxxx.

   A 6LoRHE may be ignored and skipped in parsing.

   If it is ignored, the 6LoRHE is forwarded with no change inside the

   LLN.

       0                   1

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

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

      |1|0|1| Length  |      Type     |                    |

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

                                       <--    Length    -->

                 Figure 2: Elective 6LoWPAN Routing Header

   With the third proposal 6LoRHE uses the Dispatch Value Bit Pattern of

   1111xxxx.

       0                   1

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

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

      |1|1|1|1| Length|      Type     |                    |

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

                                       <--    Length    -->

                 Figure 3: Elective 6LoWPAN Routing Header

   Length:

      Length of the 6LoRHE expressed in bytes, excluding the first 2

      bytes.  This is done to enable a node to skip a 6LoRH that it does

      not support and/or cannot parse, for instance if the Type is not

      known.

   Type:

      Type of the 6LoRHE

4.2.  Critical Format

   With the first and second proposals, the 6LoRHC uses the Dispatch

   Value Bit Pattern of 100xxxxx.

   A node which does not support the 6LoRHC Type MUST silently discard

   the packet (note that there is no provision for the exchange of error

   messages; such a situation should be avoided by judicious use of

   administrative control and/or capability indications).

     0                   1

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

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

   |1|0|0|   TSE   |      Type     |                                  |

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

                                     <-- Length implied by Type/TSE -->

                 Figure 4: Critical 6LoWPAN Routing Header

   With the third proposal 6LoRHE uses the Dispatch Value Bit Pattern of

   1101xxxx.

     0                   1

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

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

    |1|1|0|1|  TSE  |      Type     |                                  |

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

                                     <-- Length implied by Type/TSE -->

“

“

6.  The RPL Packet Information 6LoRH

   [RFC6550], Section 11.2, specifies the RPL Packet Information (RPI)

   as a set of fields that are to be added to the IP packets for the

   purpose of Instance Identification, as well as Loop Avoidance and

   Detection.

<snip>

   With the third approach, the format becomes:

       0                   1

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

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

      |1|1|0|1|O|R|F|r|6LoRH Type 5-8 | ...

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

                 r = reserved

                         Figure 13: Third encoding

   And the types include the setting of I and K as follows:

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

     |   Type    |   I   |   K   |

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

     |     5     |   0   |   0   |

     |     6     |   0   |   1   |

     |     7     |   1   |   0   |

     |     8     |   1   |   1   |

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

                      Figure 14: The RPI-6LoRH Types

"

Cheers,

Pascal

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

> From: 6lo [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)

> Sent: lundi 20 avril 2015 12:12

> To: Carsten Bormann

> Cc: [email-masked]; Samita Chakrabarti;

> Gabriel Montenegro; [email-masked]; Ralph Droms;

> [email-masked]; James Woodyatt ([email-masked])

> Subject: Re: [6lo] ascertaining RPL compression mechanism way forward

> Dear all

> I agree with Carsten that we can also try something in the current whitespace:

> Please find an example of both approaches in

> https://bitbucket.org/6lo/rpi/src/master/draft-thubert-6lo-routing-dispatch-<https://bitbucket.org/6lo/rpi/src/master/draft-thubert-6lo-routing-dispatch-04.txt>

> 04.txt<https://bitbucket.org/6lo/rpi/src/master/draft-thubert-6lo-routing-dispatch-04.txt>

> Cheers,

> Pascal

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

> > From: Carsten Bormann [mailto:[email-masked]]

> > Sent: vendredi 17 avril 2015 13:46

> > To: Pascal Thubert (pthubert)

> > Cc: Gabriel Montenegro;

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

> > [email-masked]<mailto:[email-masked]>; Samita Chakrabarti; James

> > Woodyatt ([email-masked]<mailto:[email-masked]>); Ralph Droms; [email-masked]<mailto:[email-masked]>

> > Subject: Re: [6lo] ascertaining RPL compression mechanism way forward

> > I completely agree with this approach, except that I have no idea

> > where "ESCAPE" comes in.

> > RFC 4944 says:

> >          | 01  111111 | ESC        - Additional Dispatch byte follows |

> > I don't think we need an additional dispatch byte.  We just may have

> > to be more sparse in allocating bits in the dispatch byte than we

> > could be by executing on the Mesh Header renovation.

> > Grüße, Carsten

> > Pascal Thubert (pthubert) wrote:

> > > Hello Gabriel:

> > > Yes to all on my side, you are 100% clear and correct.

> > > My suggestion, then, is to republish using the escape, thus

> > > consuming an additional byte, but still in the background see if we can save

> it.

> > > Going to RFC will probably take a long time and we can keep that

> > > particular option open till the end, in case work with the other

> > > SDOs turn out positively.

> > > One remark is that the other SDOs might embrace the new spec in the

> > > future, and if they do, today’s reluctance would become tomorrow’s cost.

> > > What do others think ?

> > > Pascal

> > > *From:*6lo [mailto:[email-masked]] *On Behalf Of *Gabriel

> > > Montenegro

> > > *Sent:* jeudi 16 avril 2015 22:28

> > > *To:* [email-masked]<mailto:[email-masked]>;

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

> > > *Cc:* Samita Chakrabarti; James Woodyatt ([email-masked]<mailto:[email-masked]>); Ralph

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

> > > *Subject:* [6lo] ascertaining RPL compression mechanism way forward

> > > Dear authors of [1] and [2],

> > > [1] https://tools.ietf.org/html/draft-thubert-6lo-rpl-nhc/

> > > [2] https://tools.ietf.org/html/draft-thubert-6lo-routing-dispatch/

> > > During the RPL compression mechanism discussion at the recent IETF

> > > meeting in Dallas, there was an emerging position which we’d like to

> > > ascertain. The authors and the WG seemed to gravitate away from

> > > NHC++ (a possible extension of [1]) as the path forward. Instead,

> > > the sentiment in the room was to focus on the DISPATCH header

> > > approach [2], regardless of whether the Mesh Header could be

> > > reclaimed or whether the Escape mechanism had to be used.

> > > As authors of these documents, do you agree that dropping NHC++

> > > (based on [1]) represents your current thinking?

> > > Furthermore, it seems like going forward you would rather focus on

> > > the dispatch solution (based on [2]) even if this means using the

> > > ESC and paying the cost (an extra byte, correct?).

> > > In a discussion among the chairs, James and Ralph, we noted that

> > > **if** you were ok with moving forward with the ESC approach, this

> > > would simplify the process tremendously. Reclaiming the Mesh Header

> > > entirely or partially is something that entails the liaison queries

> > > to other SDO’s and would incur very careful and critical scrutiny from the

> IESG.

> > > The liaisons have not yet gone out, so before we launch that very

> > > involved process (with uncertain ending and results) we would like

> > > to double-check if you could would be willing to live with an

> > > ESC-based Dispatch solution. This could be dealt with internally to

> > > the WG and to the IETF, of course, and would be a much more

> > > controlled and simple

> > process.

> > > Thanks,

> > > Samita, James, Ralph and Gabriel

> _______________________________________________

> 6lo mailing list

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

> https://www.ietf.org/mailman/listinfo/6lo

---

From: James Woodyatt <[email-masked]>
Date: Mon, 20 Apr 2015 10:06:15 -0700

On Mon, Apr 20, 2015 at 4:42 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>
> With the Escaped Mesh Header reuse, the 6LoRH also reuses the bit patterns
> that are defined in [RFC4944] for the Mesh Header, but an ESC dispatch,
> with a value of 01 000000, must be placed before the first 6LoRH.  The ESC
> indicates that the parsing of the pattern of 10xxxxxx will now be performed
> following this specification.  There is no need to place an ESC before each
> 6LoRH, since the ESC influences the parsing of the rest of the packet.

My reading of RFC 4944 and RFC 6282 is that this would be a redefinition of
the semantics of the ESC 6LoWPAN header type.

First, a quote of the relevant excerpt from RFC 4944:

   The dispatch type is defined by a zero bit as the first bit and a one
>    bit as the second bit.  The dispatch type and header are shown here:
>                         1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |0 1| Dispatch  |  type-specific header
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    Dispatch               6-bit selector.  Identifies the type of header
>                           immediately following the Dispatch Header.
>    type-specific header   A header determined by the Dispatch Header.
>                     Figure 1: Dispatch Type and Header

[...]

> [...]
> ESC:  Specifies that the following header is a single 8-bit field for
>       the Dispatch value.  It allows support for Dispatch values larger
>       than 127.

A brief digression: It's curious why the number 127 appears here. I asked
Jonathan Hui about it on Friday when I noticed it, and he couldn't tell me
why this number is 127 and not 63. It looks like there are 6 bits of
dispatch "type selector" in the Dispatch Header, so 0-63 not 0-127. I think
an erratum is in order.

Continuing: aside from the confusion about the size of the type selector
code [6 bits, instead of 7], this seems to indicate that a 6LoWPAN Header
beginning with the ESC dispatch type selector indicates a Dispatch Header
with a type selector (what the text calls "the Dispatch value") requiring
eight bits instead of six, i.e. values ranging from 0 to 255. It does not,
for example, indicate that encapsulated 6LoWPAN headers use dispatch type
selectors from a different number allocation.

Secondly, a quote from the relevant excerpt of RFC 6282:

>
> This assignment preempts the assignment of 01 111111 for ESC [RFC4944];
> this preemption is possible because extension bytes that would enable the
> use of ESC have not been allocated yet.  Instead, the value 01 000000 is
> reserved as a replacement value for ESC, to be finally assigned with the
> first assignment of extension bytes.

Here we see RFC 6282 updating RFC 4494 with a redefinition of the ESC
Dispatch Header type selector code, but the semantics of the ESC Dispatch
Header remain unchanged.

I think if you want to further redefine the ESC Dispatch Header so that its
first appearance in a packet entails a reinterpretation of subsequent
appearances of Dispatch Header type selectors, then you need to update RFC
4494 again.

As an alternative, I suggest simply defining the type selectors you need
somewhere in the range 64 to 255 and using the ESC Dispatch Header for each
appearance of a 6LoRH.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 20 Apr 2015 19:58:26 +0000

Hello James,

Updating the ESC is not an issue since it has not been used yet, whatever the original intent and format were.

On your side question, we just have an extended space of 256 values, whether we call that dispatch or header. We could even define several of them when the first one is full or too fragmented like the first byte. The reference to 127 or 63 or whatever doesn't constraint what we do in the additional octet. ESC was defined before it was needed, classical mistake.

The particular clause I'm adding that factors the ESC is because the mesh header, if it occurs at all, will occur before the first 6LoRH and never after. So we can lock the semantics for the rest of the packet, though arguably, the proposal is ugly. We can use a value that we do not call ESC if that makes it look any better. We can call it no-mesh for instance...

The issue behind it is that a packet will have several 6LoRH, and doubling the dispatch for each of them would be prohibitive. If we do not play the rather ugly trick, the ESC strategy is doomed...

Cheers,

Pascal

Le 20 avr. 2015 à 19:06, James Woodyatt <[email-masked]<mailto:[email-masked]>> a écrit :

On Mon, Apr 20, 2015 at 4:42 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

With the Escaped Mesh Header reuse, the 6LoRH also reuses the bit patterns that are defined in [RFC4944] for the Mesh Header, but an ESC dispatch, with a value of 01 000000, must be placed before the first 6LoRH.  The ESC indicates that the parsing of the pattern of 10xxxxxx will now be performed following this specification.  There is no need to place an ESC before each 6LoRH, since the ESC influences the parsing of the rest of the packet.

My reading of RFC 4944 and RFC 6282 is that this would be a redefinition of the semantics of the ESC 6LoWPAN header type.

A brief digression: It's curious why the number 127 appears here. I asked Jonathan Hui about it on Friday when I noticed it, and he couldn't tell me why this number is 127 and not 63. It looks like there are 6 bits of dispatch "type selector" in the Dispatch Header, so 0-63 not 0-127. I think an erratum is in order.

Continuing: aside from the confusion about the size of the type selector code [6 bits, instead of 7], this seems to indicate that a 6LoWPAN Header beginning with the ESC dispatch type selector indicates a Dispatch Header with a type selector (what the text calls "the Dispatch value") requiring eight bits instead of six, i.e. values ranging from 0 to 255. It does not, for example, indicate that encapsulated 6LoWPAN headers use dispatch type selectors from a different number allocation.

This assignment preempts the assignment of 01 111111 for ESC [RFC4944]; this preemption is possible because extension bytes that would enable the use of ESC have not been allocated yet.  Instead, the value 01 000000 is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes.

Here we see RFC 6282 updating RFC 4494 with a redefinition of the ESC Dispatch Header type selector code, but the semantics of the ESC Dispatch Header remain unchanged.

I think if you want to further redefine the ESC Dispatch Header so that its first appearance in a packet entails a reinterpretation of subsequent appearances of Dispatch Header type selectors, then you need to update RFC 4494 again.

As an alternative, I suggest simply defining the type selectors you need somewhere in the range 64 to 255 and using the ESC Dispatch Header for each appearance of a 6LoRH.

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2015 00:36:11 +0200

Broken record mode:
This has nothing to do with ESC, and there is no point in touching ESC.
Can someone dig up for me why ESC is coming up again and again?

(Pascal: As a co-author of RFC 6282, you should be aware that we already moved ESC once from where it was in RFC 4944.
[We seem to have been a bit more pragmatic with our allocations at the time. Ahem.]
ESC is more of a “reserved for future use” allocation than a precisely [and thus prematurely] defined thing.

Grüße, Carsten

On 20 Apr 2015 at 21:58:52, Pascal Thubert (pthubert) ([email-masked]) wrote:

Hello James,

Cheers,

Pascal

Le 20 avr. 2015 à 19:06, James Woodyatt <[email-masked]> a écrit :

On Mon, Apr 20, 2015 at 4:42 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:

[email-masked]

---

From: Robert Cragie <[email-masked]>
Date: Tue, 21 Apr 2015 08:27:28 +0100

Hi Carsten,

ESC is still one way of doing it. As Pascal points out, it is simply a 
way of defining another 256 code points which can be used for dispatch 
or header at the expense of having to include an extra byte (I also 
don't get the "127" text in RFC 4944; as James points out, that is 
probably an error). ESC was probably defined as a simple "get out of 
jail free" card to make sure there was always going to be a way of 
expanding the dispatch codes. Sure it could have been done much more 
efficiently but hindsight is a wonderful thing. So it isn't "reserved 
for future use" as it is explicit (if not precise) about its meaning.

The proposal is to use ESC as a "switch" to mean "the subsequent codes 
are not those in RFC4944 or RFC6282". What that means is that we 
probably have to have a "through the looking glass" set of dispatch 
codes which:

* Retain IPHC, FRAG1 and FRAGN as the most commonly used dispatch codes
* Reserve the codes where NALP, IPv6, LOWPAN_HC1 and LOWPAN_BC0 as these 
would no longer be used
* Replace MESH with 6LoRH

Current set (RFC4944 merged with RFC6282)

           Pattern    Header Type
+------------+-----------------------------------------------+
          | 00  xxxxxx | NALP       - Not a LoWPAN frame               |
          | 01  000000 | ESC        - Additional Dispatch byte follows |
          | 01  000001 | IPv6       - Uncompressed IPv6 Addresses      |
          | 01  000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6       |
          | 01  000011 | reserved   - Reserved for future use          |
          |   ...      | reserved   - Reserved for future use          |
          | 01  001111 | reserved   - Reserved for future use          |
          | 01  010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast             |
          | 01  010001 | reserved   - Reserved for future use          |
          |   ...      | reserved   - Reserved for future use          |
          | 01  011111 | reserved   - Reserved for future use          |
          | 01  1xxxxx | IPHC       - LOWPAN_IPHC compressed IPv6      |
          | 10  xxxxxx | MESH       - Mesh Header                      |
          | 11  000xxx | FRAG1      - Fragmentation Header (first)     |
          | 11  001000 | reserved   - Reserved for future use          |
          |   ...      | reserved   - Reserved for future use          |
          | 11  011111 | reserved   - Reserved for future use          |
          | 11  100xxx | FRAGN      - Fragmentation Header (subsequent)|
          | 11  101000 | reserved   - Reserved for future use          |
          |   ...      | reserved   - Reserved for future use          |
          | 11  111111 | reserved   - Reserved for future use          |
+------------+-----------------------------------------------+

Possible ESC set:

           Pattern    Header Type
+------------+-------------------------------------------------+
          | 00  000000 | reserved   - Reserved for future use            |
          |   ...      | reserved   - Reserved for future use            |
          | 01  011111 | reserved   - Reserved for future use            |
          | 01  1xxxxx | IPHC       - LOWPAN_IPHC compressed IPv6        |
          | 10  xxxxxx | 6LoRH      - draft-thubert-6lo-routing-dispatch |
          | 11  000xxx | FRAG1      - Fragmentation Header (first)       |
          | 11  001000 | reserved   - Reserved for future use            |
          |   ...      | reserved   - Reserved for future use            |
          | 11  011111 | reserved   - Reserved for future use            |
          | 11  100xxx | FRAGN      - Fragmentation Header (subsequent)  |
          | 11  101000 | reserved   - Reserved for future use            |
          |   ...      | reserved   - Reserved for future use            |
          | 11  111111 | reserved   - Reserved for future use            |
+------------+-------------------------------------------------+

As the number of choices has now been expanded and we are actually 
trying to converge on a solution, it would be useful to gauge opinion as 
to whether this ESC approach is acceptable or not.

Robert

On 20/04/2015 23:36, Carsten Bormann wrote:
> (Pascal: As a co-author of RFC 6282, you should be aware that we 
> already moved ESC once from where it was in RFC 4944.
> On 20 Apr 2015 at 21:58:52, Pascal Thubert (pthubert) 
> ([email-masked] <mailto:[email-masked]>) wrote:
>
>> Hello James,
>>
>> Updating the ESC is not an issue since it has not been used yet, 
>> whatever the original intent and format were.
>>
>> On your side question, we just have an extended space of 256 values, 
>> whether we call that dispatch or header. We could even define several 
>> of them when the first one is full or too fragmented like the first 
>> byte. The reference to 127 or 63 or whatever doesn't constraint what 
>> we do in the additional octet. ESC was defined before it was needed, 
>> classical mistake.
>>
>> The particular clause I'm adding that factors the ESC is because the 
>> mesh header, if it occurs at all, will occur before the first 6LoRH 
>> and never after. So we can lock the semantics for the rest of the 
>> packet, though arguably, the proposal is ugly. We can use a value 
>> that we do not call ESC if that makes it look any better. We can call 
>> it no-mesh for instance...
>>
>> The issue behind it is that a packet will have several 6LoRH, and 
>> doubling the dispatch for each of them would be prohibitive. If we do 
>> not play the rather ugly trick, the ESC strategy is doomed...
>>
>> Cheers,
>>
>> Pascal
>>
>>> On Mon, Apr 20, 2015 at 4:42 AM, Pascal Thubert (pthubert) 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>
>>>     With the Escaped Mesh Header reuse, the 6LoRH also reuses the
>>>     bit patterns that are defined in [RFC4944] for the Mesh Header,
>>>     but an ESC dispatch, with a value of 01 000000, must be placed
>>>     before the first 6LoRH.  The ESC indicates that the parsing of
>>>     the pattern of 10xxxxxx will now be performed following this
>>>     specification.  There is no need to place an ESC before each
>>> My reading of RFC 4944 and RFC 6282 is that this would be a 
>>> redefinition of the semantics of the ESC 6LoWPAN header type.
>>>
>>> A brief digression: It's curious why the number 127 appears here. I 
>>> asked Jonathan Hui about it on Friday when I noticed it, and he 
>>> couldn't tell me why this number is 127 and not 63. It looks like 
>>> there are 6 bits of dispatch "type selector" in the Dispatch Header, 
>>> so 0-63 not 0-127. I think an erratum is in order.
>>>
>>> Continuing: aside from the confusion about the size of the type 
>>> selector code [6 bits, instead of 7], this seems to indicate that 
>>> a 6LoWPAN Header beginning with the ESC dispatch type selector 
>>> indicates a Dispatch Header with a type selector (what the text 
>>> calls "the Dispatch value") requiring eight bits instead of six, 
>>> i.e. values ranging from 0 to 255. It does not, for example, 
>>> indicate that encapsulated 6LoWPAN headers use dispatch type 
>>>     This assignment preempts the assignment of 01 111111 for ESC
>>>     [RFC4944]; this preemption is possible because extension bytes
>>>     that would enable the use of ESC have not been allocated yet.
>>>     Instead, the value 01 000000 is reserved as a replacement value
>>>     for ESC, to be finally assigned with the first assignment of
>>>     extension bytes.
>>>
>>>
>>> Here we see RFC 6282 updating RFC 4494 with a redefinition of the 
>>> ESC Dispatch Header type selector code, but the semantics of the ESC 
>>> Dispatch Header remain unchanged.
>>>
>>> I think if you want to further redefine the ESC Dispatch Header so 
>>> that its first appearance in a packet entails a reinterpretation of 
>>> subsequent appearances of Dispatch Header type selectors, then you 
>>> need to update RFC 4494 again.
>>>
>>> As an alternative, I suggest simply defining the type selectors you 
>>> need somewhere in the range 64 to 255 and using the ESC Dispatch 
>>> Header for each appearance of a 6LoRH.
>>>
>>>
>>> --
>>> james woodyatt <[email-masked] <mailto:[email-masked]>>
>>> [email-masked] <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2015 09:47:25 +0200

On 21 Apr 2015 at 09:28:09, Robert Cragie ([email-masked]) wrote:
Hi Carsten, 

ESC is still one way of doing it. 
ESC is defined as a way to get more dispatch code points once the first 192 are finished up.

We are not there yet, so ESC does not enter the picture.

As Pascal points out, it is simply a 
way of defining another 256 code points which can be used for dispatch 
or header at the expense of having to include an extra byte 
Yes, we will have to allocate one or more dispatch code points, which are then followed by additional header bits if we can’t get a large enough space.  But that’s true for everything we do at the dispatch level.

(I also 
don't get the "127" text in RFC 4944; as James points out, that is 
probably an error). ESC was probably defined as a simple "get out of 
jail free" card to make sure there was always going to be a way of 
expanding the dispatch codes. 
Yes, that is its point.

It’s not being used here.

Sure it could have been done much more 
efficiently but hindsight is a wonderful thing. So it isn't "reserved 
for future use" as it is explicit (if not precise) about its meaning. 

* Retain IPHC, FRAG1 and FRAGN as the most commonly used dispatch codes 
Why would I use an ESC-like mechanism for these?  They work without such a mechanism.

* Reserve the codes where NALP, IPv6, LOWPAN_HC1 and LOWPAN_BC0 as these 
would no longer be used 
All codes from ESC-0 to ESC-255 are already waiting for allocation.  No need to reserve anything.

* Replace MESH with 6LoRH 
Why would I want to waste two more bits?

I understand the appeal to use something like an ESC-like mechanism for this:  We could then simply say “ignore that you should be sending ESC-like for this deployment”, doing the Mesh Header Renovation through the back door.  But that is exactly the same as saying “reinterpret 11xxxxxx for this deployment”, except that it causes a giant confusion, as if there were some mechanism there that isn’t.  And we would need to allocate a new code for the purposes ESC is allocated for.  We might as well allocate the new code for this new thing!

Actually, if we don’t do the Mesh Header renovation, then we should be allocating an appropriate number of dispatch codes for the RH/New Mesh Header/whatever we call it.

01 000100 through 01 001111	reserved for future use

01 010001 through 01 011111	reserved for future use

11 001000 through 11 011111	reserved for future use

11 101000 through 11 111111	reserved for future use

75 codes waiting to be allocated.

It should be easily justifiable to get three bits out of the dispatch code by allocating eight of these (~ 10 %); four bits (~ 20 %) might be stretching it (but might be appropriate if there is a good allocation structure within the new structure).  In particular if we can hope to get the unused part of the old MH space back.
Look, Ma, no ESC.

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Apr 2015 08:25:20 +0000

Completely agree, Carsten.

And as author of 6282 I suffered from that premature definition, and place the new just behind IPv6. I’m sure you noticed that I used that updated version in the draft.

Cheers,

Pascal

From: Carsten Bormann [mailto:[email-masked]]
Sent: mardi 21 avril 2015 00:36
To: Pascal Thubert (pthubert); James Woodyatt
Cc: [email-masked]; [email-masked]
Subject: Re: [6lo] ascertaining RPL compression mechanism way forward

Broken record mode:

Grüße, Carsten

On 20 Apr 2015 at 21:58:52, Pascal Thubert (pthubert) ([email-masked]<mailto:[email-masked]>) wrote:
Hello James,

Cheers,

Pascal

---

From: Robert Cragie <[email-masked]>
Date: Tue, 21 Apr 2015 09:44:11 +0100

Hi Carsten,

I accept it was probably confusing to use "ESC" as that is an actual 
code point and the intent is to refer to an escape mechanism. I agree we 
don't have to use ESC (0b01000000) and we should probably leave ESC 
alone and keep it for the implied case where it really does have to be 
used before every alternative dispatch code. This also renders it 
virtually useless in practice as Pascal points out.

So, considering using one of the reserved codes; the principle is 
similar to ESC but the suggestion is that it is more like a SWITCH. We 
could do the following:

0b01001xxx: SWITCH: Switch to secondary dispatch code page

This would give 7 secondary dispatch code pages. We could reserve 6LoRH 
as page 0.

Again, I stress we are trying to converge on a solution. If ESC or 
SWITCH (or whatever you want to call it) is not liked, we can drop it.

Further comments inline.

Robert

On 21/04/2015 08:47, Carsten Bormann wrote:
> On 21 Apr 2015 at 09:28:09, Robert Cragie ([email-masked] 
> <mailto:[email-masked]>) wrote:
>> Hi Carsten,
>>
<RCC>That is one interpretation of ESC. Another is to avoid touching 
RFC4494/6282 space at all</RCC>
> Yes, we will have to allocate one or more dispatch code points, which 
> are then followed by additional header bits if we can’t get a large 
> enough space.  But that’s true for everything we do at the dispatch level.
>
<RCC>Of course if you generalise it like this, it is all the same and 
it's about where you draw the line between which bits are dispatch and 
which bits are protocol fields. However, the concept of using an 
alternative dispatch code space seems different to me</RCC>
> It’s not being used here.
<RCC>It could be but we would probably not choose to use ESC. See 
above.</RCC>
> Why would I use an ESC-like mechanism for these?  They work without 
<RCC>If you have already switched, then these codes are likely to come 
after the switch so need to be retained. You could of course completely 
change all of this but I don't see the point.</RCC>
>  No need to reserve anything.
<RCC>Sure; this is just a clarification point that if you saw a frame 
starting with e.g. SWITCH(0), you would not see these codes subsequently 
in the first incarnation.</RCC>
> Why would I want to waste two more bits?
<RCC>To save further bits. The whole point of the exercise is to make 
this as efficient as possible.</RCC>
>
> I understand the appeal to use something like an ESC-like mechanism 
> for this:  We could then simply say “ignore that you should be sending 
> ESC-like for this deployment”, doing the Mesh Header Renovation 
> through the back door.  But that is exactly the same as saying 
> “reinterpret 11xxxxxx for this deployment”, except that it causes a 
> giant confusion, as if there were some mechanism there that isn’t. 
>  And we would need to allocate a new code for the purposes ESC is 
> allocated for.  We might as well allocate the new code for this new thing!
>
<RCC>I did miss out ESC in the secondary page I proposed earlier and 
agree that ESC (or SWITCH maybe?) should go in. I'm not sure what you 
mean by "Mesh Header Renovation". The original 
draft-thubert-6lo-routing-dispatch draft was an attempt to code 
efficiently and to do so, using 1/4 of the dispatch code space (i.e. 
reappropriating MESH) was considered the most efficient way. If we 
define a secondary dispatch page we can do what we want, however it 
makes sense to me not to trample too much on it to save lots of code 
rewriting.</RCC>
>
> Actually, if we don’t do the Mesh Header renovation, then we should be 
> allocating an appropriate number of dispatch codes for the RH/New Mesh 
> Header/whatever we call it.
>
> 01 000100 through 01 001111reserved for future use
>
> 01 010001 through 01 011111reserved for future use
>
> 11 001000 through 11 011111reserved for future use
>
> 11 101000 through 11 111111reserved for future use
>
> It should be easily justifiable to get three bits out of the dispatch 
> code by allocating eight of these (~ 10 %); four bits (~ 20 %) might 
> be stretching it (but might be appropriate if there is a good 
> allocation structure within the new structure).  In particular if we 
> can hope to get the unused part of the old MH space back.
<RCC>You can do it that way as well - Pascal has proposed that too in 
his Bitbucket draft. It is using up further space in the current set of 
dispatch codes of course. For a single extra byte at the beginning of 
the packet, we can define our own dispatch code page and if we don't 
make it too weird then it will have some compatibility with existing 
implementations.</RCC>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Apr 2015 08:53:59 +0000

Hello Robert:

This is very much what  was trying to express. Thanks for this. Not meaning that I favor this approach. 

Note that I did not write about the 4h approach, use 00…. I’m not sure that one was a much better idea than the fragmented world we have inherited.

Cheers,

Pascal

From: Robert Cragie [mailto:[email-masked]] 
Sent: mardi 21 avril 2015 10:44
To: Carsten Bormann; James Woodyatt; Pascal Thubert (pthubert)
Cc: [email-masked]; [email-masked]
Subject: Re:

Hi Carsten,

I accept it was probably confusing to use "ESC" as that is an actual code point and the intent is to refer to an escape mechanism. I agree we don't have to use ESC (0b01000000) and we should probably leave ESC alone and keep it for the implied case where it really does have to be used before every alternative dispatch code. This also renders it virtually useless in practice as Pascal points out.

So, considering using one of the reserved codes; the principle is similar to ESC but the suggestion is that it is more like a SWITCH. We could do the following:

This would give 7 secondary dispatch code pages. We could reserve 6LoRH as page 0.

Again, I stress we are trying to converge on a solution. If ESC or SWITCH (or whatever you want to call it) is not liked, we can drop it.

Further comments inline.

Robert

Hi Carsten, 

<RCC>That is one interpretation of ESC. Another is to avoid touching RFC4494/6282 space at all</RCC>

<RCC>Of course if you generalise it like this, it is all the same and it's about where you draw the line between which bits are dispatch and which bits are protocol fields. However, the concept of using an alternative dispatch code space seems different to me</RCC>

(I also 

Yes, that is its point.

<RCC>It could be but we would probably not choose to use ESC. See above.</RCC>

<RCC>If you have already switched, then these codes are likely to come after the switch so need to be retained. You could of course completely change all of this but I don't see the point.</RCC>

<RCC>Sure; this is just a clarification point that if you saw a frame starting with e.g. SWITCH(0), you would not see these codes subsequently in the first incarnation.</RCC>

<RCC>To save further bits. The whole point of the exercise is to make this as efficient as possible.</RCC>

<RCC>I did miss out ESC in the secondary page I proposed earlier and agree that ESC (or SWITCH maybe?) should go in. I'm not sure what you mean by "Mesh Header Renovation". The original draft-thubert-6lo-routing-dispatch draft was an attempt to code efficiently and to do so, using 1/4 of the dispatch code space (i.e. reappropriating MESH) was considered the most efficient way. If we define a secondary dispatch page we can do what we want, however it makes sense to me not to trample too much on it to save lots of code rewriting.</RCC>

<RCC>You can do it that way as well - Pascal has proposed that too in his Bitbucket draft. It is using up further space in the current set of dispatch codes of course. For a single extra byte at the beginning of the packet, we can define our own dispatch code page and if we don't make it too weird then it will have some compatibility with existing implementations.</RCC>

Look, Ma, no ESC.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Tue, 21 Apr 2015 10:19:26 +0100

Hi Pascal,

One correction below:

This would give 8 secondary dispatch code pages. We could reserve 6LoRH 
as page 0.

(I was thinking 6LoRH plus another 7).

Sorry, I meant to say that you have proposed an alternative based on 
existing dispatch codes but you have clarified that already.

Robert

On 21/04/2015 09:53, Pascal Thubert (pthubert) wrote:
> Note that I did not write about the 4h approach, use 00…. I’m not sure 
> that one was a much better idea than the fragmented world we have 
> inherited.
>
> Cheers,
>
> Pascal
>
> *From:*Robert Cragie [mailto:[email-masked]]
> *Sent:* mardi 21 avril 2015 10:44
> *To:* Carsten Bormann; James Woodyatt; Pascal Thubert (pthubert)
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re:
>
> Hi Carsten,
>
> code point and the intent is to refer to an escape mechanism. I agree 
> we don't have to use ESC (0b01000000) and we should probably leave ESC 
>     On 21 Apr 2015 at 09:28:09, Robert Cragie
>     ([email-masked] <mailto:[email-masked]>)
>     wrote:
>
>         Hi Carsten,
>
> after the switch so need to be retained. You could of course 
> completely change all of this but I don't see the point.</RCC>
>
> starting with e.g. SWITCH(0), you would not see these codes 
> subsequently in the first incarnation.</RCC>
>
> his Bitbucket draft. It is using up further space in the current set 
> of dispatch codes of course. For a single extra byte at the beginning 
> of the packet, we can define our own dispatch code page and if we 
> don't make it too weird then it will have some compatibility with 
> existing implementations.</RCC>
>
> Look, Ma, no ESC.
>
> Grüße, Carsten
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2015 11:31:55 +0200

> This would give 8 secondary dispatch code pages. We could reserve 6LoRH

Again, this ("dispatch code pages") provides the illusion of a
"mechanism" we don't need.

01 000001 is not a "SWITCH" to IPv6.  It is just a dispatch code that
has further header formats associated with it (in this case, the IPv6
header).

Similarly,

(since superseded by RFC 6282, which properly allocated 32 dispatch
codes in one swoop) did not SWITCH to HC1, it was just a dispatch code
that was associated to the HC1 header:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | HC1 encoding  |     Non-Compressed fields follow...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In RFC 6282, this is combined into:

       0                                       1
       0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     | 0 | 1 | 1 |  TF   |NH | HLIM  |CID|SAC|  SAM  | M |DAC|  DAM  |
     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

     |-----------DISPATCH------------|---------REST-OF-HEADER--------|

where the first 8 bits are the 32 dispatch codes, and the next 8 bits
complete the five bits already covered by the dispatch codes.

I would expect the RH work to use the same model, independent of whether
we get five or six bits from renovating MH or three or four bits from
just normally allocating dispatch codes.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Tue, 21 Apr 2015 11:24:53 +0100

Hi Carsten,

I see your point but the dispatch codes have historically occupied two 
bits then a further six bits to occupy up to one byte; why otherwise 
does the table define codes like 0b011xxxxx as well as 0b01000001 for 
example? Therefore, it would make sense to me to define further "pages" 
in a similar way.

Switch/dispatch essentially mean the same thing but the subtle 
difference is that "switch" means switching to a different code page but 
using the same stage of parsing, i.e. subsequent bytes will still be 
parsed at the 6lo dispatch stage using an alternative page. "Dispatch" 
(to me at least) implies handing off to another stage; in your example, 
the other stages would be the IPv6 parsing stage and the IPHC parsing 
stage respectively. One might say it is a moot point and from a bits and 
bytes angle it probably is but I see no harm in this distinction for 
clarification.

Robert

On 21/04/2015 10:31, Carsten Bormann wrote:
> I would expect the RH work to use the same model, independent of 
> whether we get five or six bits from renovating MH or three or four 
> bits from just normally allocating dispatch codes.

I completely agree, however using the SWITCH, we can define an 
alternative page which legitimately uses 0b10xxxxxx for the cost of one 
byte prior to the first 6LoRH use.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2015 12:43:35 +0200

On 21 Apr 2015 at 12:25:38, Robert Cragie ([email-masked]) wrote:
Therefore, it would make sense to me to define further "pages" 
in a similar way. 
Another reason not to introduce a concept of “pages”.

I don’t want 6lo to turn into ISO 2022 [1].

Grüße, Carsten

[1]: http://en.wikipedia.org/wiki/ISO/IEC_2022

---

From: Robert Cragie <[email-masked]>
Date: Tue, 21 Apr 2015 12:48:39 +0100

Hi Carsten,

So I take it you're a "no" for using any form of one octet code for a 
SWITCH and that your proposal would be to use up codes from the existing 
space?

Robert

On 21/04/2015 11:43, Carsten Bormann wrote:
> On 21 Apr 2015 at 12:25:38, Robert Cragie ([email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2015 14:01:56 +0200

Robert Cragie wrote:
> SWITCH 

Right.  I don't know a reason to bind ourselves to using up exactly one
dispatch code point for 6loRH, and I don't know why we would call that
code point SWITCH if in reality it is about 6loRH.

> and that your proposal would be to use up codes from the existing
> space?

Any proposal will have to do that, SWITCH included.  There is no
difference.  Except that I would prefer to label code points with what
they are for.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Tue, 21 Apr 2015 13:48:45 +0100

> code point SWITCH if in reality it is about 6loRH.
<RCC>It was just a suggestion - a two step process: (1) Allocate 
SWITCH(0)-SWITCH(7) and associated IANA code space, (2) Assign 6LoRH to 
SWITCH(0). But I would be fine with allocating a single code to 6LoRH as 
well. I think this discussion is probably done now.</RCC>
> difference.  Except that I would prefer to label code points with what
<RCC>SWITCH would just use 1 (or 8 if we take the two step approach) 
code points for the purpose of SWITCH alone. The other proposal (which 
Pascal distinguishes quite clearly) is to allocate a set of code points 
for the newly-defined dispatch. I believe there is a difference - I 
guess we will just have to disagree on that point.</RCC>