Subject: Re: [6lo] Possible 6LoWPAN dispatch type deprecation and re-use for route over purposes

From: James Woodyatt <[email-masked]>
Date: Fri, 1 May 2015 11:44:24 -0700

On Thu, Apr 30, 2015 at 12:21 PM, Michael Richardson <[email-masked]>
wrote:

>
> The proposed changes do not deprecate anything; they really just
> make mesh-under and route-over unable to operate in the same PANID.
>

I would say this is a serious understatement of the mesh header renovation
proposal [option 1]. It's not relevant whether the renovation "deprecates"
the Mesh Header dispatch type selector codes. It's enough to redefine them
without considering backward compatibility. That has a profound effect.
Sufficiently profound that I would argue that marking RFC 4944 as Obsolete
would be entailed.

Accepting the mesh header renovation proposal goes beyond making it
impossible to operate both mesh-under and route-over in the same PANID. It
also makes it impossible to build hardware or microcoded implementations of
6LoWPAN capable of operating in either mode without being configured first
with an operating parameter to distinguish between them. No standard way of
announcing this operational parameter is described in the mesh header
renovation proposal.

Furthermore the mesh header renovation proposal implies that hardware and
microcode implementations may claim to be compliant with the revised
standard, which includes the renovation, despite not supporting the current
standard in RFC 4944 [which, as I say, would seem to need marking as
Obsolete], and this could bring undesirable fragmentation in the technical
ecology, i.e. when I'm building a new device, I may choose at manufacturing
time which of the two standards the device can support— by selecting the
appropriate part or by burning in the appropriate microcode— but I may not
be able to support both modes in a single unit, even with a software
cut-out to enable the older mesh header standard.

This is why we need to use the Liaison Statement process and the IESG
review if we are to give serious consideration to the mesh header
renovation proposal. It's not a trivial step to redefine the Mesh Header
dispatch type selector codes, and if the proposal is to be seriously
considered, then it must be carefully scrutinized by the IESG and all the
external standards organizations with an interest in 6LoWPAN.

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 01 May 2015 23:36:41 +0200

James Woodyatt wrote:
> No standard way of announcing this operational parameter is described in
> the mesh header renovation proposal.

Yes, and there never has been a standard way of announcing the use (and
the purported semantics) of the RFC 4944 mesh header either, so nothing
would change in that respect.  As defined in RFC 4944, the mesh header
is an empty shell, to be filled in by a specific agreement that all
interoperating nodes in a mesh need to be aware of before they can start
using it.
Again, no change at all by the new proposal, except that the syntax now
would also be allowed to change with that special agreement.

If those who want to use the old syntax would actually tell what they
plan to use it for, there might maybe be a basis for some argument.  I
still haven't seen anything but political maneuvering.  Why is it so
hard to argue at a technical level?

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Fri, 1 May 2015 17:43:21 -0400

> On May 1, 2015, at 5:36 PM 5/1/15, Carsten Bormann <[email-masked]> wrote:
> 
> James Woodyatt wrote:

G3-PLC is defined in ITU-T G.9903, published by SG-15.  From my reading of that document, G.9903 specifies the use of the MESH Dispatch Type as defined in RFC 4944, as well as the ESC Dispatch Type, as redefined in RFC 6282.

- Ralph

> 
> Grüße, Carsten
> 
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 02 May 2015 00:53:33 +0200

Ralph Droms wrote:
> ITU-T G.9903

Thanks for bringing this discussion to a technical level.  So this
document has allocated the dispatch code ESC (RFC 6282's value of
01_000000) for the specific purposes of G.9903 ("command frames").  We
probably should add a comment to the IANA registry [1] that this code is
not available in G.9903-based networks.  (I can't seem to find the
liaison statement that alerted IETF to this allocation; however, another
part of that document mentions that "IANA consideration" is "for further
study", so that might still come.)

The other interesting observation is that G.9903 always seems to use the
mesh header with V=1 and F=1 (i.e., the dispatch region used is
10_11XXXX).  This might coincide with the purported plan by the Thread
Group to use the Mesh Header (of which I unfortunately know no details).

I'm not an expert on G.9903 (in particular, I don't understand the
interaction between its Annex E and RFC 6775; the latter only seems to
be reference for the HC area context distribution), but it seems to me
this is exactly a case where pre-configured knowledge of the way the
mesh header is intended to be used, is a prerequisite to being able to
use it ("a 6LoWPAN device requires a set of pre-deployed information,
called a LoWPAN information base(LIB), ..."; similarly, there is an
"Adaptation sublayer IB", IB = information base).

Grüße, Carsten

[1]:
https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml

---

From: Ralph Droms <[email-masked]>
Date: Sat, 2 May 2015 20:40:20 -0400

> On May 1, 2015, at 6:53 PM 5/1/15, Carsten Bormann <[email-masked]> wrote:
> 
> Ralph Droms wrote:
>> ITU-T G.9903
> 
> 01_000000) for the specific purposes of G.9903 ("command frames").

In my opinion, G.9903 defines the values 0x01-0x1f in the byte following the ESC Dispatch Type.  The other values are still available for use in other protocols.

> We

I suggest we actively engage ITU-T SG-15 to publish a very short RFC establishing a new IANA registry for the codepoints in the byte following the ESC Dispatch Type.  This registry would define 0x01-0x1f as "G.9903 Command ID values" and mark the other codepoints as "available for assignment".

BTW, I'm now the IAB Liaison Oversight manager.  I've alerted Scott Mansfield to the issue.  The 6lo chairs/secretary, Scott and I will get in touch with ITU-T SG-15 regarding the registry.

> Group to use the Mesh Header (of which I unfortunately know no details).

As far as I can tell, G.9903 uses the MESH Dispatch Type according to the definition in RFC 6282.  I don't think any speculation about the use of the Dispatch Type codepoints by the Thread Group is relevant to this discussion of G.9903.
> "Adaptation sublayer IB", IB = information base).

Here, I think we disagree.  I don't see how any internal configuration can be used to select how bits in a protocol header can be used.  The IETF, in fact, fought long and hard *against* a similar definition of an extension to the TCP segment header (Q.flowstatesig).  There is no way, within the protocol itself, to guarantee that all the nodes that might exchange frames with mesh headers will use the same interpretation.

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 03 May 2015 09:32:54 +0200

> In my opinion, G.9903 defines the values 0x01-0x1f in the byte following the ESC Dispatch Type.  The other values are still available for use in other protocols.

That's one way to read it, but not quite the way that I get from a
literal read.
It says (9.4.2.3.1):
»As shown in Figure 9-12, the ADP sublayer command frames are identified
using the ESC header type (see clause 5.1 of [IETF RFC 4944]), followed
by an 8-bit dispatch field indicating the type of ADP command.«
So all 256 values are meant to indicate a specific type of ADP command
frame.  Table 9-35 then goes ahead and allocates 31 values of those;
with a gap, so it identifies some as "Reserved by ITU-T".

(I'm not sure I understand the way G.9905 uses this command frame
concept for source routing; it says the command frame carrying the
source route header is "attached to the packet", but it doesn't quite
tell how both the command frame and the packet are transported, given
that "This header" (the command frame header) "shall be in the last
position if more than one header is present in the 6LowPAN frame."
according to 9.4.2.3.1 of G.9903.  I also don't understand how mesh
headers and those source routes mix, or how a forwarding node knows
where in that source route it is.  Oh well, there is probably nothing
there that 6lo would want to steal, anyway.)

However we read this, I agree that it does make a lot of sense to get
the protocol codes used by ITU-T into the IANA registries, and that we
should work with SG-15 to get this done.

(We do indeed disagree about the usefulness of being able to interpret
protocol syntax when there is no way to act on the semantics required
for handling the packet at all.  Self-describing syntax is certainly
good for wireshark etc., and it helps with hardware implementations.  It
is not a categorical imperative, however.)

Grüße, Carsten

---

From: Ralph Droms <[email-masked]>
Date: Mon, 4 May 2015 08:39:46 +0100

(Dropping [email-masked]; bcc'ed)

> On May 3, 2015, at 8:32 AM 5/3/15, Carsten Bormann <[email-masked]> wrote:
> 
> 
> 
> Ralph Droms wrote:

I'll work with Scott Mansfield (ITU-T Liaison Manager), Samita, Gabriel, James and the 6lo WG to collaborate with ITU-T SG-15 on establishing an appropriate IANA registry.

> is not a categorical imperative, however.)

I've moved the discussion to 6lo to continue this thread.

Can you say more, as I don't understand what you've written and I don't have a clue about where "self-describing syntax" fits into the discussion.

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 May 2015 12:21:24 +0000

I agree with Carsten here;

There is no ethertype in 15.4 and the networks do what they like. I'm sure that if we dig around we'll find networks that actually employ the same bits as what we understand as the mesh header dispatch sequence.
A way to sort networks out that used by Wireless HART is to define a well-known key in the standard for use during the join process. We are considering doing the same thing in 6TiSCH.

I read in a recent thread that the mesh header is even being used to carry IPv6 addresses in a compressed form as opposed to short and long 802.15.4 addresses. How could a standard implementation know that this is happening and deal with it? Inside a particular network, the expectation is that the mesh header dispatched is used in an interoperable way. From the above, that expectation is already untrue between standards that claim 6LowPAN compliance. 

If a network uses the RFC4944 mesh header format, then it cannot be extended and things are cast in stone forever. In my view, the only real worry is right there.  That network will not be able to use new stuff that the renovation format enables tomorrow. Which can be tons of stuff since now that the format is widely extensible.

And yes, a manufacturer will have to design his software for the particular network(s) it aims at. Because different standards and compliances require different things, and 6LowpAN is only a little portion of that.

Cheers,

Pascal

> -----Original Message-----
> From: 6lo [mailto:[email-masked]] On Behalf Of Carsten Bormann
> Sent: vendredi 1 mai 2015 23:37
> To: James Woodyatt
> Cc: IETF discussion list; Thierry LYS; [email-masked]; [email-masked]
> Subject: Re: [6lo] Possible 6LoWPAN dispatch type deprecation and re-use for
> route over purposes
> 
> James Woodyatt wrote:
> > No standard way of announcing this operational parameter is described
> > in the mesh header renovation proposal.
> 
> Yes, and there never has been a standard way of announcing the use (and the
> purported semantics) of the RFC 4944 mesh header either, so nothing would
> change in that respect.  As defined in RFC 4944, the mesh header is an empty
> shell, to be filled in by a specific agreement that all interoperating nodes in a
> mesh need to be aware of before they can start using it.
> Again, no change at all by the new proposal, except that the syntax now would
> also be allowed to change with that special agreement.
> 
> If those who want to use the old syntax would actually tell what they plan to use
> it for, there might maybe be a basis for some argument.  I still haven't seen
> anything but political maneuvering.  Why is it so hard to argue at a technical
> level?
> 
> Grüße, Carsten
>