On May 1, 2015, at 6:53 PM 5/1/15, Carsten Bormann <cabo(_at_)tzi(_dot_)org>
wrote:
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").
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
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.)
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.
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).
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.
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).
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
Grüße, Carsten
[1]:
https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml