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

[Jonathan Hui <[e-mail]>]

Robert,

On Tue, Jul 28, 2015 at 1:06 PM, Robert Cragie <[e-mail]>
wrote:

>
>> 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.
>>
>
> <RCC>That is true, but we already discussed this and tried this to some
> extent with the repurposing of the mesh header. That isn't defining a whole
> new set of codes for a new technology but is tantamount to it. It didn't
> seem to go down well, hence the idea of page codes/markers.</RCC>
>

I understand why the particular design choices were made in the current
draft.

FWIW, I don't think flat out repurposing the Mesh Header was the right
approach.  It basically meant that the RFC 4944 Mesh Header is never to be
used at the same time as a 6LoRH.  Some have argued that it becomes
confusing when 6lo implementations are just following RFCs (rather than
some external alliance) as to what Dispatch values to use, and I can
understand that viewpoint as well.

Instead, I think a better approach is to be explicit and say that devices
can configure what 6lo headers are in use and how those headers are
identified in a packet.  Still maintain a single "default" namespace that
devices use if no such configuration is used or available.  But the
configuration allows devices to use more efficient header identifiers if
they choose to do so.  As mentioned previously, this is not much different
from assigning 4-bit Context IDs to IPv6 prefixes.  The difference is that
the 6lo header configuration will typically be static, so distributing the
configuration is much simpler than what's required for Context IDs.

The result is that no new 6lo header definition "supersedes" an existing
one.  Instead, new 6lo header definitions can be defined within the
existing RFC 4944 Dispatch space and implementations could agree on more
efficient identifiers if they choose to do so.  The implementation cost is
simply a jump table with dynamic value, rather than static ones.

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.
>>
>
> <RCC>Indeed we could. Perhaps a wholesale change might actually be more
> palatable than just repurposing some of the dispatch code space?</RCC>
>

Certainly something to consider.

--
Jonathan Hui