Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[EFM] Question on bit and byte ordering in OAMPDUs




Hi,

I need the help of all you die-hard expert 802.3 standard readers to resolve
a possible ambiguity in the EFM draft (3.1).  I am sufficiently confused by
the current representation to be confident that it will not result in
interoperable implementations, but not sure yet of the appropriate changes.

57.4.1 says that when the encoding of an element of an OAMPDU is depicted in
a "table", the least significant bit is bit 0.  We think that this statement
is true for some of the tables but not tables that represent more than one
element of an OAMPDU, such as Table 57-13 and 57-14.  (Some table entries
don't have a bit 0, e.g. Table 57-14's Variable Leaf is bits 23:8).

57.4.1 also says that when encoding of an element of an OAMPDU is depicted
in a "diagram", then (a) octets are transmitted from top to bottom and (c)
when consecutive octets are used to represent a binary number, the octet
transmitted first has the more significant value.  This looks OK to me for
the "Figures" (e.g. fig 57-9).  But many OAMPDU elements are specified in
"Tables".  I've chosen two such tables to make my point.  

The meaning of the "bits" column in the tables is not specified in the
draft.  I have assumed that it is the order the bits are sent on the wire
(at 10Mbit/s).

Table 57-14 (variable container format) shows the encoding of elements of a
variable response OAMPDU.  Figure 57-13 defines the structure of this OAMPDU
and shows that the elements in the table must be transmitted from bottom to
top of the table.  Starting from the top is meaningless.  So I conclude that
these Tables are not "diagrams" as referred to in 57.4.1 (a).  I know it is
the Figure and not the Table that defines the octet transmission order, but
having them in opposite orders is very confusing.  The rules above then seem
to require the following transmission order, taking the bit numbers from the
table: first bits 0..7 (Branch), then bits 16..23 then 8..15 (Variable Leaf
being a binary number per 57.4.1 (c)), then bits 24..31 (Width), then Value
(transmitted most significant octet first per 57.6.2.1).

Table 57-9 (OAMPDU configuration field) appears to contradict this
interpretation.  It shows the encoding of elements of an Information OAMPDU.
It contains two entries: a reserved field in bits 15:11 at the top, and a
Maximum OAMPDU size in bits 10:0 at the bottom.  The rule 57.4.1 (c)
requires the more significant octet of this number to be transmitted first,
which in this case requires transmission of the top element of the table
first, because the 11-bit field spans the two octets.  The rules therefore
require the following transmission order: first bits 8..10 (most significant
3 bits of Size), then 11..15 (Reserved), then 0..7 (least significant octet
of Size).  The "Bits" column in table 57-9 therefore does not represent the
bit order on the wire!  Perhaps instead, table 57-9 should be followed by
the statement "The complete OAMPDU Configuration Field is treated as a
16-bit binary number and encoded accordingly."

Have I got anything wrong? 

If my interpretations are correct, then
   * I think the "Bits" columns in the Tables are misleading and confusing,
and should be removed.  Even if they represent bit order on the wire they
are still confusing in cases such as Variable Leaf in table 57-14, because
while bits 23:8 on the wire may represent this field, they are sent in the
order 16..23 then 8..15.  The exception would be for table 57-9, where the
bit definitions are required.
   * I think the order of items in the Tables should match that in the
Figures (this means changing Tables 57-13 and 57-14).

Before I put comments in on the draft, it would be good to know if anyone
agrees.  Apologies for this long email - it is difficult to explain!

Regards,
	-- John