Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt

[Jonathan Hui <[e-mail]>]

Having the "page switch" markers effectively increases the Dispatch space
to 2 octets or more, with a compression mechanism that allows consecutive
headers from the same page to elide the the first octet.  In the limit, if
I wanted to keep switching between the two spaces, then I incur one byte
overhead for each header.  Though, I agree that is a fairly contrived case.

Currently, we are going down a path where every 6LoWPAN network in
existence needs to respect the same header identifiers (i.e. Dispatch
values) at all times.  It's not obvious to me that this is a good idea.

For example, two devices in the field could easily determine what headers
are actually in use and the corresponding header identifiers.  In one view,
this is not much different than establishing 6LoWPAN contexts.  A 6LoWPAN
network already determines what prefixes are in use and binds short forms
(4-bit Context IDs) to those.  If there is ever any confusion on how those
4-bit Context IDs are assigned, then things will fail.  Typically, we
expect to use IEEE 802.15.4 security mechanisms to isolate networks.  After
devices establish a secure link, there is no need to worry about processing
packets that not a part of that secure link.  We could apply the same logic
to Dispatch values and forgo the overhead of "page switch" markers.

As a side note, strictly speaking, RFC 4944 was defined for IEEE
802.15.4-2003 and RFC 6282 defined for IEEE 802.15.4-2006.  In theory, we
could easily define a new Dispatch mechanism for TSCH (IEEE
802.15.4e-2012).  The frames are distinguishable using the IEEE 802.15.4
Frame Version field.

--
Jonathan Hui

On Mon, Jul 27, 2015 at 2:36 AM, Robert Cragie <[e-mail]>
wrote:

> Hi Jonathan,
>
> For most efficient use, i.e. just one extra octet per packet, you
> basically have to redefine the whole page as you would use that code (e.g.
> 01 000011) to switch to page 1 at the beginning of the packet. Some of that
> may be new, some could be carried over from "page 0" (i.e. the existing
> dispatch code space). This gives the most flexibility, however the main
> downside as I see it is that it is no longer 6LoWPAN as originally defined.
> It might also be useful to have a "switch to page 0" code in page 1 to
> potentially allow the insertion of an extra byte to switch back to the
> original dispatch codes. We could even allocate all codes from 01 000011 to
> 01 001111 as page switching codes, although that might be a step too far
> for some people.
>
> There are no repurposing issues as the new page is a completely new code
> space and would be managed by IANA.
>
> Also, just to be clear (as it seems to be getting mixed up in this
> thread), this should be completely distinct from the ESC discussion, which
> should go ahead as planned. In that discussion, I believe only the code
> points currently used by ITU-T should be allocated but this should include
> anything they have reserved. Looking at the union of codes, that does mean
> 0x01-0x1F as far as I can see. I think that is what we agreed in the
> liaison statement.
>
> Robert
>
>
> On 23 July 2015 at 21:15, Jonathan Hui <[e-mail]> wrote:
>
>> Pascal,
>>
>> If defining a new 6lo namespace is a path forward, then I'd rather be
>> very explicit about it and take full advantage of that opportunity.  I know
>> that the existing draft was somewhat constrained in making some attempt to
>> respect the existing Dispatch values, but now we are free.
>>
>> For example, only define two types of headers (elective and critical) and
>> only use a single bit to distinguish between them.  Then cast everything
>> (including RFC 4944 and RFC 6282) within those headers.  For example, don't
>> bother to reserve 00xxxxxx for something else.
>>
>> With my experience in using IEEE 802.15.4e-2012 Information Elements, I
>> have felt for a long time that 6lo headers can benefit from a TLV
>> structure.  It's good to see that here.
>>
>> At the same time, I still think it's useful to be able to assign blocks
>> of type values to specific headers so that headers that need an extra bit
>> or two of control can do that without consume a whole number byte.  But
>> that would mean we run into the same issue we do today in deciding how best
>> to assign type values.  As a result, I still find it useful to be able to
>> have come context that identifies 6lo headers are in use - much in the same
>> way contexts are needed to understand compressed IPv6 addresses.  In the
>> latter, we are effectively configuring how 4-bit identifiers map to
>> particular IPv6 prefixes.  But this idea can apply to both 6LoRH and RFC
>> 4944 and should be treated as such.
>>
>> --
>> Jonathan Hui
>>
>>
>> On Thu, Jul 23, 2015 at 12:34 PM, Pascal Thubert (pthubert) <
>> [e-mail]> wrote:
>>
>>>  True, Jonathan.
>>>
>>>
>>>
>>> In fact that’s already the case with RFC 6282… That space is booked on
>>> both pages.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Pascal
>>>
>>>
>>>
>>> *From:* Jonathan Hui [mailto:[e-mail]]
>>> *Sent:* jeudi 23 juillet 2015 21:26
>>> *To:* Pascal Thubert (pthubert)
>>> *Cc:* Samita Chakrabarti; [e-mail]
>>> *Subject:* Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>>>
>>>
>>>
>>> Hi Pascal,
>>>
>>>
>>>
>>> The compromise may be more significant than at first glance.
>>>
>>>
>>>
>>> The "page marker" effectively creates two namespaces.  Headers within a
>>> namespace must be contiguous.  RFC 4944 namespace must come before 6LoRH
>>> namespace.  That limits the flexility of 6lo headers.
>>>
>>>
>>>
>>> What if someone actually wanted to define a new 6lo header that may be
>>> used before or after the page marker?  The definition of that new 6lo
>>> header must be defined for both the RFC 4944 namespace and the 6LoRH
>>> namespace.
>>>
>>>
>>>
>>> For example, what if I wanted to use source routing to deliver a 6lo
>>> header to a particular destination?  It would be nice to use the existing
>>> 6LoRH header format.  But currently not possible since we've already left
>>> the RFC 4944 namespace after processing the source route header.
>>>
>>>
>>>
>>> In another example, what if someone came up with a much better way to do
>>> IPv6 datagram compression?  That person would need to define encodings for
>>> both RFC 4944 and 6LoRH to support both.  And because RFC 4944 and 6LoRH
>>> have different ways of identifying headers, there will be wasted bits
>>> somewhere.
>>>
>>>
>>>
>>> --
>>>
>>> Jonathan Hui
>>>
>>>
>>>
>>> On Thu, Jul 23, 2015 at 12:04 PM, Pascal Thubert (pthubert) <
>>> [e-mail]> wrote:
>>>
>>>  Hello Jonathan:
>>>
>>>
>>>
>>> Multiple things here.
>>>
>>>
>>>
>>> One is that I agree with your view and will support it. 6LoRH will work
>>> the same either way but we'd save one octet if your ether type is implicit
>>> vs. the new explicit dispatch in 3.2
>>>
>>>
>>>
>>> But if your view is too hard to swallow for the group or the world at
>>> large then I'll opt for the compromise. This page marker (I like Robert's
>>> view here) allows to reuse most of the space and the cost is just one
>>> octet, same as making ether type explicit.
>>>
>>>
>>>
>>> Now if the group takes the page marker approach, the mesh header will
>>> disappear from 6LoRH. That's because MH-6LoRH was an artifact only needed
>>> in the approach in section 3.1
>>>
>>>
>>>
>>> With 3.2, if you need fragments or mesh or NALP from RFC 4944 then you
>>> place them first in the compressed packet. When you're all done with 4944
>>> you place the marker (you pick another  coding page) and the space is
>>> available again. But since mesh and fragments were already done, the
>>> capability to encode them again is not required.
>>>
>>>
>>>
>>> Summary is that your opposition WRT MH and frags is not valid; but I
>>> still agree with your bottom line.
>>>
>>>
>>> Pascal
>>>
>>>
>>> Le 23 juil. 2015 à 17:23, Jonathan Hui <[e-mail]> a écrit :
>>>
>>>  Pascal,
>>>
>>>
>>>
>>> Section 3.2 uses a particular Dispatch value to delineate that
>>> everything before should utilize header identifiers as allocated in the
>>> Dispatch value registry and everything after utilize header identifiers
>>> proposed in this draft.
>>>
>>>
>>>
>>> My concern is that it becomes very difficult to truly mix the use of 6lo
>>> headers.  This draft defines how to map RFC 4944 Mesh Header into the the
>>> new header identifier space.  The MH-6LoRH definition is not just a simple
>>> change in the header identification, but it also changes the header
>>> encoding itself (HopsLft comes before the V and F flags).  This draft also
>>> chooses not to map the RFC 4944 Fragment Header into the new space, so does
>>> not define a mapping.
>>>
>>>
>>>
>>> In any case, my main concern is that any new definition of 6lo headers
>>> will need to show multiple definitions, one for the old (RFC 4944) and one
>>> for the new (draft-thubert-6lo-routing-dispatch).
>>>
>>>
>>>
>>> I would much prefer an approach that makes it possible to have a single
>>> header definition, regardless of how the headers are ordered within the 6lo
>>> packet.
>>>
>>>
>>>
>>> --
>>>
>>> Jonathan Hui
>>>
>>>
>>>
>>> On Thu, Jul 23, 2015 at 5:22 AM, Pascal Thubert (pthubert) <
>>> [e-mail]> wrote:
>>>
>>>  Dear all:
>>>
>>>
>>>
>>> It seems that we are finding a way which is workable and acceptable to
>>> all parties to extend 6LoWPAN with a TLV format. Not my favorite, I really
>>> think that Jonathan has the best proposal on the table. But if this is the
>>> one thing that can make a consensus, I’ll gladly go for it.
>>>
>>>
>>>
>>> The method is described in more details as option 2 In section 3.2 of
>>> the 6LoRH draft
>>> https://www.ietf.org/id/draft-thubert-6lo-routing-dispatch-05.txt
>>>
>>>
>>>
>>> If the group agrees with the chairs on this approach, I can rapidly
>>> republish the draft cleaning up the leftovers of the other options so we
>>> can move forward with 6lo compression work that RPL is expecting from us.
>>> That would be really welcome for the next ETSI plugtest.
>>>
>>>
>>>
>>> Let us confirm at the WG today and on this list.
>>>
>>>
>>>
>>> If/when that is behind us, my question to the WG will be whether folks
>>> want:
>>>
>>> 1) to split the doc in 2 to separate the TLV proper in a short document,
>>> or
>>>
>>> 2) if it is OK to keep the draft in one piece as it is today, using the
>>> first values of the type for RPL packet artifacts
>>>
>>>
>>>
>>> The former 1) leads to a quicker delivery of the TLV alone, so other
>>> work can safely start using it.
>>>
>>>
>>>
>>> The latter 2) is a quicker path for RPL compression since we do not need
>>> to advance 2 documents; it also has the advantage to illustrate why we
>>> suggest to have the type and the length structured the way they are. Rather
>>> to advance a format with no example usage.
>>>
>>>
>>>
>>> What do people think?
>>>
>>>
>>>
>>> Pascal
>>>
>>>
>>>
>>> *From:* Samita Chakrabarti [mailto:[e-mail]]
>>> *Sent:* mercredi 22 juillet 2015 23:43
>>> *To:* Pascal Thubert (pthubert); Jonathan Hui
>>> *Cc:* Thierry LYS ([e-mail]); [e-mail]
>>> *Subject:* RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>>>
>>>
>>>
>>> Hi Pascal,
>>>
>>>
>>>
>>> We discussed it in person. But for clarification purpose, I am
>>> responding to this email.
>>>
>>>
>>>
>>> See in-line.
>>>
>>>
>>>
>>> *From:* Pascal Thubert (pthubert) [mailto:[e-mail]
>>> <[e-mail]>]
>>> *Sent:* Thursday, July 09, 2015 5:00 AM
>>> *To:* Jonathan Hui; Samita Chakrabarti
>>>
>>> *Cc:* Thierry LYS ([e-mail]); [e-mail]
>>> *Subject:* RE: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>>>
>>>
>>>
>>> 100% agreement with Jonathan.
>>>
>>>
>>>
>>> I think that granting 6LoWPAN formats after the fact without a chance to
>>> discuss what goes where in that grant is a mistake that create the wrong
>>> type of precedent.
>>>
>>> *[SC>]  At the meeting(July 20th), we have discussed ITU-T code-space
>>> assignment and possible solutions at length and WG response was taken with
>>> hum and email of the quorum and liaison statement text was shared.*
>>>
>>>
>>>
>>>
>>>
>>> *We have proposed to use the current ESC sequence (01 000000) for ITU-T
>>> and for other possible organization specific usage(TBD). But only allocate
>>> code-space for which we have specs (G.9903 and G.9905).*
>>>
>>>
>>>
>>> *We are going to define a new ESC byte or will call that ‘Dispatch
>>> Extention Tag” or something similar to allow the WG to define a TLV
>>> structure and use it for different purpose – one of that could be
>>> link-specific. Though we need to be careful and see we don’t waste
>>> codespace in anticipation.*
>>>
>>>
>>>
>>> *We can definitely start looking into 6loRH draft as a starting point
>>> for the new ‘Dispatch Extension Tag(DET)”…*
>>>
>>>
>>>
>>> *Cheers,*
>>>
>>> *-Samita*
>>>
>>>
>>>
>>>
>>>
>>> What if another group also escaped its own stuff and used the same codes
>>> and comes tomorrow asking us the same range? Or any range? Why them and not
>>> us?
>>>
>>>
>>>
>>> We are pretty much in the mirror situation as the desire to reuse the MH
>>> space for 6LoRH. This becomes a problem of relation between not just 2 but
>>> an unknown number of other standardization bodies. At the end of the day,
>>> this is the core reason why there are some rules, and the reason why we are
>>> reconsidering the 6LoRH not to overlap with MH.
>>>
>>>
>>>
>>> A few remarks:
>>>
>>>
>>>
>>> -        6LoRH has built-in a signal that a header can be ignored.
>>> That’s a lesson we learnt from IPv6 Option Type identifiers encoding. When
>>> the header can be ignored, the size to skip is provided in octets.
>>>
>>> -        One option (option 2) for encoding 6LoRH is a form of escape.
>>> But we realized that the values being escaped (and thus reused modulo 256)
>>> are for dispatches that are at the head of the packet. So rather than
>>> having to escape every single occurrence of a 6LoRH, the proposal is to
>>> delineate the segment of the packet where 4944 is no more used and 6LoRH
>>> start applying. IOW we virtually escape all the rest of the packet, so we
>>> can reuse the space (modulo 256) the space used by NALP, MH and Fragments
>>> before the demarcation.
>>>
>>> -        6LoRH has a TLV structure and has room to receive the namespace
>>> required by G3-PLC.
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Pascal
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Pascal
>>>
>>>
>>>
>>> *From:* 6lo [mailto:[e-mail] <[e-mail]>] *On
>>> Behalf Of *Jonathan Hui
>>> *Sent:* mercredi 8 juillet 2015 22:48
>>> *To:* Samita Chakrabarti
>>> *Cc:* Thierry LYS ([e-mail]); [e-mail]
>>> *Subject:* Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>>>
>>>
>>>
>>> Hi Samita,
>>>
>>>
>>>
>>> See below:
>>>
>>>
>>>
>>> On Wed, Jul 8, 2015 at 11:17 AM, Samita Chakrabarti <
>>> [e-mail]> wrote:
>>>
>>>
>>>
>>> *From:* Jonathan Hui [mailto:[e-mail]]
>>> *Sent:* Tuesday, July 07, 2015 11:16 PM
>>> *To:* Samita Chakrabarti
>>> *Cc:* [e-mail]; Thierry LYS ([e-mail])
>>> *Subject:* Re: [6lo] draft-chairs-6lo-dispatch-iana-registry-00.txt
>>>
>>>
>>>
>>> If a legacy implementation does not understand the ESC header, the
>>> device cannot simply skip the ESC header and continue processing what
>>> follows.  So I'm not sure how an existing implementation can just ignore
>>> the ESC header.
>>>
>>> *[SC>] Yes, you’re right. It is limited to <dispatch><ESC> case.  I am
>>> still not sure how useful that is for the node that does not understand the
>>> ESC bytes. For sequence <dispatch><ESC><another-dispatch> will not
>>> work—Gabe and I discussed that.*
>>>
>>> *The question we probably need to answer – what would be the use-cases
>>> in different scenarios?  *
>>>
>>>
>>>
>>> I think we need to be clear about different "legacy" implementations.
>>> There's legacy implementations that don't understand any ESC headers (those
>>> that only used the 6lowpan headers defined in RFCs as of today).  There's
>>> legacy implementations that makeup their own use of ESC headers (G3-PLC).
>>> And then there's the "legacy" implementations that will understand the new
>>> ESC header encoding, but may not understand some subset of the headers
>>> defined within that ESC header encoding.
>>>
>>>
>>>
>>> If history is any indication, we can't possibly foresee all important
>>> use cases that may come up in the future.
>>>
>>>
>>>
>>>    *What was the original intention of having ESC bytes?  Could ESC
>>> byte be considered as 6lowpan extension header? [ like IPv6 extension
>>> headers? ]*
>>>
>>>
>>>
>>> As Carsten stated, the original intention was to give us an out in the
>>> case that all of the existing dispatch values were used up.
>>>
>>>
>>>
>>>    *Could ESC bytes occur multiple times? [ in practice, we want to
>>> minimize the header bits- that’s the purpose of 6lowpan, so I assume, we
>>> don’t want to add a very long set of sequences]*
>>>
>>>
>>>
>>> That's really up to how we define ESC headers, but I think it would be a
>>> mistake not to allow ESC headers to occur multiple times.
>>>
>>>
>>>
>>>    *Another question: It is possible that one implementation can only
>>> understand a set of ESC bytes but not other sets. Should it drop the
>>> packet? The problem is that without knowing ESC type, the receiver cannot
>>> know how many bytes to skip. It’s too late now to introduce TLV structure
>>> in ESC first byte. We can define TLV after first byte, but in either case
>>> we are stuck because of G.9903, I guess.*
>>>
>>>
>>>
>>> Again, that's really depends on whether or not we define a class of
>>> headers that can be ignored.  Personally, I do think 6lowpan could benefit
>>> from a class of ignorable headers.
>>>
>>>
>>>
>>> As I mentioned above, we can't possibly foresee all important use cases
>>> that may come up in the future.  So having an ignorable range of 6lowpan
>>> headers is something we should certainly consider.  IEEE 802.15.4
>>> originally started down a path of optimizing every bit, only to realize
>>> that it was too restrictive, and resulted in IEEE 802.15.4e-2012
>>> Information Elements (IEs).  Those IEs are now used in a number of ways to
>>> extend the base IEEE 802.15.4 header.  IEEE 802.15.4e-2012 even introduces
>>> an IE that carries the MAC payload such that new footers can also be
>>> defined.  Basically, most everything outside the base header can now be
>>> encapsulated by IEs.
>>>
>>>
>>>
>>> As Carsten mentioned, whether or not additional headers are encoded
>>> within the ESC range is a separate consideration.  But if such additional
>>> headers are encoded within the ESC range, then it is of interest to this
>>> draft.
>>>
>>>
>>>
>>> Finally, I'll reiterate that I think we should think carefully about
>>> simply giving a whole swath of the ESC namespace to G3-PLC.  One
>>> possibility is to have an encoding that can carry something like an OUI,
>>> allowing third parties to define whatever they want without any further
>>> coordination with the IETF.  IEEE 802.15.4e-2012 IEs have a form that can
>>> carry OUIs.
>>>
>>>
>>>
>>> --
>>>
>>> Jonathan Hui
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> 6lo mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lo
>>
>>
>