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

RE: [EFM] Re: [EFM-OAM] Question on bit and byte ordering in OAMPDUs




I think a picture similar to link aggregation clause is sufficiently
clear (figure 43-7).

Cheers,

-----Original Message-----
From: Benjamin Brown [mailto:benjbrown@comcast.net]
Sent: Monday, March 01, 2004 3:07 PM
To: John Messenger
Cc: 'stds-802-3-efm@ieee.org'; 'stds-802-3-efm-oam@ieee.org'
Subject: [EFM] Re: [EFM-OAM] Question on bit and byte ordering in
OAMPDUs




John,

I'm finally getting around to looking at the draft. You have definitely
found an inconsistency or at least a point of confusion. A potential
solution is to make a fairly drastic change to make this section look
much more like Clause 43 - Link Aggregation, in particular 43.4.2
and 43.5.3. This effectively removes all of the tables describing
specific fields (57-3, 57-7, 57-8, 57-9, 57-10, 57-11, 57-13, and
57-14).

Thoughts? My concern is that there is very little time in Orlando to
make this change since our editing needs to be complete before we
get on our respective planes Friday afternoon/evening. It would be
best if the new text was available at the start of the meeting (not
necessarily at the same time the comment is made) so, should it be
accepted, the text is dropped in. John are you willing to make this
level of effort? If not, then perhaps a simpler solution can be
explored with merely some explanatory text.

Regards,
Ben

John Messenger wrote:

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

-- 
-----------------------------------------
Benjamin Brown
178 Bear Hill Road
Chichester, NH 03258
603-491-0296 - Cell
603-798-4115 - Office
benjamin.brown@ieee.org
-----------------------------------------