RE: [EFM-OAM] Question on invalid length/type field test
John,
A comment against D1.3 was made that essentially requested the definition of an errored frame. The text in question was my attempt to briefly describe an errored frame. Essentially, I leveraged the definition found in 30.3.1.1.5, which reads:
"A count of frames that are successfully received (receiveOK). This does not include frames
received with frame-too-long, FCS, length or alignment errors, or frames lost due to internal MAC sublayer error. This counter is incremented when the ReceiveStatus is reported as receiveOK."
As such, my attempt in Clause 57 was to briefly list the reasons why a frame would not be considered "OK" and hence be detected as errored at the MAC. In D1.732, I try to clear this up by simply pointing to 4.2.9 and giving the reader the MAC's definition of receive frames with detected transmission errors.
As to Geoff's comment "doesn't seem to be worth doing to me", Geoff may be thinking the OAM sublayer is performing some validity check of frames and probably felt simplifying the definition of errored frame would be sufficient. However, I only intended to point to existing MAC functionality rather than create new work for the OAM sublayer.
Kevin Daines
Editor, EFM OAM
-----Original Message-----
From: Geoff Thompson [mailto:gthompso@nortelnetworks.com]
Sent: 06 May 2003 19:21
To: John Messenger
Cc: stds-802-3-efm-oam@ieee.org
Subject: Re: [EFM-OAM] Question on invalid length/type field test
John-
At 05:49 PM 5/6/2003 +0200, John Messenger wrote:
> Hi,
>
> 57.5.3.2 deals with errored frames. One of the listed criteria (from (d))
> is a "frame containing an invalid Length/Type field". I presume this
refers
> to the check in the RemovePad function in 4.2.9. That is, I presume that
> this really means a "frame whose received length does not match the length
> recorded in the Length/Type field (if any)".
> Is this interpretation correct? If so, I think a change in wording would
be
> in order to make it clear that the check is not applicable in the case of
a
> "Type" field. I could not find a comment on this point in the recently
> posted comment list.
I would make no such assumption.
From the inadequate description I would assume that it gets set if the value
in the Type/Length field lies in the narrow range between the max
legitimate LLC dataSize (1500) and the lowest legitimate value of Type
(1536).
Values 1 - 1500 are legitimate as length interpretation.
Values of 1536 and above are legitimate as Type interpretation
(Ref: 802.3 cl 3.2.6)
Doesn't seem to be worth doing to me.
> Regards,
> -- John Messenger
Geoff