RE: Start checking
Ben:
I agree with your conclusion, but for different reasons. The RS check you
describe is optional, and therefore can't be used in computing the
probability of undetected error. Obviously, making this check mandatory
would improve start delimiter robustness.
Two error cases to consider. The first is a lengthening of the frame
through the creation of a starting sequence in the Idle preceding the frame.
For an undetected error, this requires changing the inter-frame idle (e.g.,
/A/, /K/, /R/)into a start. Also, all sequential control codes have to be
changed into data, excluding the original start (e.g., /S/) up to the
preamble. Next, one of these data bytes or an existing preamble byte has to
be changed into a MAC SFD.
I doubt we want to do anything more for this case, since the frame can also
be lengthened when an existing preamble byte is changed into an SFD, without
any error related to the start code. In this case, we trust the CRC check
to catch the error.
I am more concerned about the second case, because I see shortcuts an
implementer might take that don't exactly mirror the behavior of the
standard. This case is the conversion of a data byte into a start within
the body of a frame. The way clause 46 is currently written, the RS does
not change the status of DATA_VALID, and it would convert the start into a
preamble byte. This isn't much different than changing a data byte into
another data byte. Again, this is something we trust the CRC check to
detect.
--Bob Grow
-----Original Message-----
From: Ben Brown [mailto:bbrown@amcc.com]
Sent: Thursday, November 23, 2000 5:34 AM
To: 802.3ae
Subject: Re: Start checking
Rich,
The RS is capable of performing a preamble check that
byte 0 is in lane 0 and is an S. It then checks that
the next 6 bytes are data (not necessarily 0x55) then
that byte 7 is an SFD. Given this level of check at
the RS, I agree that you don't need to check beyond
the S.
Ben
Rich Taborek wrote:
>
> Ladies and Gentlemen,
>
> Clause 48 has a mandate to check packet delimiters per agreement in
> Tampa. Clause 48 currently specifies Start as a single code-group in
> lane 0 but does not check the data bytes in lanes 1 through 3. As editor
> I'm going to leave it like this because I haven't had any comments to
> date on it.
>
> The other obvious possible check to do is to check lanes 1 through 3 for
> the corresponding preamble bytes.
>
> If anyone can think of a good reason to change the way it is I'd like to
> hear it. Historically, 1000BASE-X had a similar "hair-trigger" for Start
> so I believe that checking only for Start in lane 0 is adequate.
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------
> Richard Taborek Sr. Phone: 408-845-6102
> Chief Technology Officer Cell: 408-832-3957
> nSerial Corporation Fax: 408-845-6114
> 2500-5 Augustine Dr. mailto:rtaborek@nSerial.com
> Santa Clara, CA 95054 http://www.nSerial.com
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@amcc.com
-----------------------------------------