Re: More comments (clauses 49 & 46)
Hi Pat, Ben
These are really good points, I'm glad we're catching them.
As for point 3,
Maybe I'm confusing the issue, but if the RX receives an E frame (which
it interprets as a valid C frame) it will not detect a violation in
sequencing. But, the way I see it, it will map the E frame into the
corresponding RS control codes for E (0xfe,1 I think...). It seems like
this is what we want. The RS will receive the E codes in the end and
will decide what to do with them - it has the necessary information to
know there was an error there (whether it happened on the Transmit end
or the Receive PCS it can't tell - but it sees the E's)
As to the first point of just one E octet in a valid C field of a T
codeword, I'm not sure what the appropriate action to take is. I see
some validity in the argument to have the PCS replace this with an all E
frame, but I ask myself whether an E following a T implies that the
previous packet is bad. The D before the T is the last octet of the
ethernet packet, the T is there to let you know that - and also to let
you know that the packet was ok (correct me if I'm wrong on this), so -
if there is an E after the T, I'm not convinced it means the packet
wasn't good.
Let me know your thoughts, I just wanted to put out an alternate opinion
on this before changes are made to the draft.
-Dave
pat_thaler@agilent.com wrote:
>
> Ben,
>
> Good questions.
>
> On the third ocmment (and also related somewhat to your second comment), it
> may be that the frame type should be E when a frame is received that has a
> control character of E in it. At least, if the frame is all E's, it should
> be detected as an E frame or the end delimiter check on the receiver will
> pass some frames to the RS as okay that should have had an error.
>
> If a transmit machine is sending D frames followed by a T and then an
> errored frame, it will send a the D frames followed by the T followed by a
> valid block filled with the E character according to the change to which we
> agreed. The receiver should get an error on the frame but if the block of
> all E characters is detected as a C frame, it will pass the frame to the
> XGMII with no errors and the RS won't detect the error. I think I should
> modify the FRAME_TYPE descriptions for C and E to make a frame of all E
> characters be detected as an E frame.
>
> Regards,
> Pat
>
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@amcc.com]
> Sent: Thursday, November 16, 2000 10:36 AM
> To: 802.3ae
> Subject: More comments (clauses 49 & 46)
>
> Clause 49 & 46:
>
> This brings up another interesting point about how the
> PCS & RS currently handle delimiter robustness. Consider
> the case of a packet that is ended with the following
> octet stream (broken into 8-octet words that a 64b/66b
> PCS might encounter):
>
> DDDDDDDD
> DDDDTEII
> IIIIIIII
>
> The PCS would send to the XGMII these bytes exactly as is
> and would not replace the T word (or even the T octet) with
> Es. Because the PCS treats any of the defined encodings in
> table 49-1 (other than T & S) as C, it decodes and forwards
> what it receives (barring actual decoder violations).
> Will the RS corrupt this packet? Does the RS expect the
> PCS to corrupt the /T/ if the C following the T is anything
> but an I?
>
> Enjoy,
> Ben