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

[Robert Cragie <[e-mail]>]

Hi Jonathan,

More comments inline, bracketed by <RCC2></RCC2>

Robert

On 28 July 2015 at 21:38, Jonathan Hui <[e-mail]> wrote:

> 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.
>

<RCC2>That was the point, as 6LoRH redefines the mesh header. Therefore you
would never use RFC 4944 mesh header and 6LoRH together as you would never
need to.</RCC2>


>   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.
>

<RCC2>
I can understand the viewpoint but cast on its own, it is somewhat
meaningless. If put into context then it makes more sense.

In an abstract sense, there is what I call a "hierarchy of constraints". By
this I mean at lower ranks, more things are optional and superior ranks
reclassify options into mandatory or excluded. At the top of the hierarchy,
an interoperable implementation can be built where devices can autonomously
figure out based on a configuration how they operate. In this case, the
superior rank to the RFC rank simply states which dispatch codes are being
used and which aren't.

For example, the mesh dispatch code is never used in ZigBee IP so we said
it was excluded, i.e. if a device receives a packet with a mesh header, it
is silently discarded and devices should never generate them under normal
operation. I don't see what is particularly confusing about this.

TL;DR: I guess what I am trying to say is that it probably is confusing
just following the RFCs as you inevitably need some hierarchy of
constraints above. If you don't have that, interoperability will be
difficult to achieve.
</RCC2>


> 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.
>

<RCC2>The only obvious issue I can see here is variable length dispatch
codes. For example, NALP and MESH are both 2 bits, thus giving 6 bits of
the remaining octet to the subsequent data. In this way, it could be
difficult to define generic 6lo headers which would fit into an arbitrarily
allocated dispatch space</RCC2>


>   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.
>

<RCC2>It's not much different in that it is stateful but I think that's
where the similarities end. The page configuration(s) would really have to
be innate in a device. If there is only one innate page configuration, then
no page identifiers are needed as you say. I am not sure how a device could
dynamically learn pages unless there is some sort of "dispatch code schema"
and I don't think we are proposing that?</RCC2>

>
> 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.
>

<RCC2>The concept of pages is key to this though. The question comes down
to whether these pages are defined in an IANA registry with (a) possible
page code(s) in the current "page 0" (effectively proposal 2 in
draft-thubert-6lo-routing-dispatch-04) or, as you suggest, defined outside
of IETF. There are certainly some who think that 6lo framing is really
nothing to do with IETF as it is below layer 3 and I think they have a
point. The "wet finger in the air" attempt at MESH and BC0 in RFC 4944 also
bears this out to some extent.</RCC2>

>
> 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.
>

<RCC2>Over to the list and WG...</RCC2>