RE: [EFM] Re: [EFM-OAM] Question on bit and byte ordering in OAMPDUs
Hi,
Thanks for the responses. Personally, I don't want to add more figures like
43-7, because the figures already present in the draft do the job just fine
(Figures 57-9, 57-10, 57-11, 57-12, 57-13, 57-14, 57-15). The essence of
the confusion is that tables 57-13 and 57-14 look similar to the previous
tables (57-8 to 57-11) but are in fact not representing the same kind of
information. The earlier tables each represent a single object to be
encoded in an OAMPDU, but 57-13 and 57-14 represent multiple objects, and
hence the order goes wrong.
In my view the "Bits" column represents the bits in a single object being
encoded (contrary to what I said in my original email below). Therefore the
"Bits" column in 57-13 and 57-14 should be deleted - these are not single
objects. This would be replaced by an "octets" column, which would match
the figures 57-12 and 57-13. To see the conflict, compare table 57-9 with
table 57-14. The first must be encoded as an integer that spans multiple
octets, but the second would be ridiculous if encoded as a single object
using that rule.
My proposed change is to change the "Bits" column in tables 57-13 and 57-14
to an "Octets" column giving the size of each item in octets. The text of
each entry would talk in terms of the individual fields' bit numbers. Also,
to reverse the order of the entries in those tables (so, the tables would
both start with Variable Branch, matching the corresponding Figures 57-13
and 57-14). That's all I think it's necessary to do to fix this problem.
On balance I don't think it's necessary to remove the "shall" statements
above tables 57-13 and 57-14.
Regards,
-- John
-----Original Message-----
From: Stephen Suryaputra [mailto:ssuryaputra@HatterasNetworks.com]
Sent: 02 March 2004 13:29
To: benjamin.brown@ieee.org; John Messenger
Cc: stds-802-3-efm@ieee.org; stds-802-3-efm-oam@ieee.org
Subject: 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
-----------------------------------------