Re: [6lo] Fwd: [Technical Errata Reported] RFC4944 (4359)

[Jonathan Hui <[e-mail]>]

On Fri, May 29, 2015 at 11:46 PM, Carsten Bormann <[e-mail]> wrote:

> It is true that the RFC is not internally consistent here -- some
> counterexamples to the ones you give here are Figure 2 and the text
>    NALP:  Specifies that the following bits are not a part of the LoWPAN
>       encapsulation, and any LoWPAN node that encounters a dispatch
>       value of 00xxxxxx shall discard the packet
>
> Nor is it consistent with the actual usage of the term "dispatch value"
> in the literature, as can be seen e.g. in
>
> http://solomon.ipv6.club.tw/Course/ProtocolEngineering/archrock-6lowpan-tutorial.pdf
> or the 6LoWPAN book.
>

Unfortunately, the RFC also does not carry forward the original intent of
the value "127".  All of the counterexamples you gave appear in the RFC (or
as a result of the RFC) and not in draft-ietf-6lowpan-format-07.

Also, there is no mandate that ESC-based dispatch values can only be
> used for things other than mesh addressing and fragmentation.  There is
> also no intention that the values 0 to 63 following ESC have the same
> meaning as the dispatch values 01 000000 to 01 111111.
>

You are correct that the intent was not to preclude things that have to do
with mesh addressing and fragmentation.  But I can say that the intent was
the "Mesh Addressing Type and Header" and "Fragmentation Type and Header"
were not included in the "Dispatch Type and Header".  As mentioned
previously, the original version of Figure 2 did not include the Mesh
Addressing and Fragmentation header bit patterns.  To Kerry's point, the
original table included 128 entries, *not* 256 entries.

Expanding the confusing use of the term "dispatch value" just for the
> six-bit field in 01 xxxxxx would be wrong.
>

If you look at draft-ietf-6lowpan-format-07, the term "dispatch value" was
only used in reference to the Dispatch Type and Header.  The update to
draft-ietf-6lowpan-format-08 is where the confusing use of "dispatch value"
started to appear.  draft-ietf-6lowpan-format-07 actually used the 7-bit
dispatch value of 0 to support NALP.  However, there was concern about
consuming too many bits for NALP.  So in draft-ietf-6lowpan-format-08, we
updated NALP to only take one additional bit.  That lead to having 00xxxxxx
for NALP and 01xxxxxx for Dispatch.  Unfortunately, the edits that were
made were quick and dirty.  In retrospect, we should have create a fourth
"Type and Header" for NALP, in addition to Dispatch, Mesh Addressing, and
Fragmentation.  Doing so would have removed any discussion of NALP from the
"Dispatch Type and Header" section as well as the "Bit Pattern" table.

But putting aside the discussion on the original intent of the value "127"
and taking a step back, the high-level intent was to support
arbitrary-length bit patterns for identifying 6LoWPAN headers.  It may be
that removing any reference to a maximum "dispatch value" offered within
the first 8 bits is the best path forward, as Kerry has suggested.

--
Jonathan Hui

Grüße, Carsten
>
>
> Jonathan Hui wrote:
> > I believe the Erratum under discussion is correct and should be marked
> > as Verified.
> >
> > The original intent of "Dispatch value" was:
> > 1) To refer to the Dispatch field in the Dispatch Header - note the
> > capitalization in "Allows support for Dispatch values larger than 127."
> > 2) To identify a namespace that *excludes* the Mesh Addressing and
> > Fragmentation headers.
> >
> > The original draft text (draft-ietf-6lowpan-format-07) was less
> > ambiguous about the original intent.  Referring to that draft:
> >
> > 1) The draft separated the concept of "Header Type" from "Dispatch
> > Value".  The draft defined Header Types: Dispatch, Mesh Delivery, and
> > Fragmentation, and Dispatch Values: NALP, IPv6, LOWPAN_HC1, LOWPAN_BC0,
> > and ESC.  The draft also includes the following text that indicates the
> > Mesh Addressing and Fragmentation headers are not included in the
> > dispatch value namespace:
> >
> >    The definition of headers, other than mesh addressing and
> >    fragmentation, in LoWPAN consists of the dispatch value, the
> >    definition of the header fields that follow
> >
> > Note that the text above still lives in RFC 4944.
> >
> > 2) The bit pattern figure was titled "Dispatch Type Bit Pattern", not
> > "Dispatch Value Bit Pattern", with the intent that the table only
> > included the initial allocations within the Dispatch Header and did
> > *not* include any mention of Mesh Delivery and Fragmentation headers.
> >
> > --
> > Jonathan Hui
> >
> > _______________________________________________
> > 6lo mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/6lo
>