RE: More comments (clauses 49 & 46)
David,
The plan that was agreed to last week was for the RS to not check outside
the packet for errors. The PCS sublayers and if present the XGXS would be
responsible for doing the checks that are necessary after the end delimiter
to preserve error robustness and converting any such error detected to an
error in the frame.
Therefore, if the XGMII passes a frame that ends something like:
DDTI
IIII
EEEE
EEEE
which is what could happen in the case you mention, then the
RS will send the frame to the MAC without any error indication.
If a 10GBASE-R PCS receives:
DDTIIIII
EEEEEEEE
it needs to turn that into something with an error before the
end of frame. Similar rules apply for a 10GBASE-X PCS that
receives a frame with an error in the column after the T.
Regards,
Pat
-----Original Message-----
From: David Gross [mailto:dgross@xxxxxxxxxxxxxxxxxx]
Sent: Friday, November 17, 2000 7:49 AM
To: pat_thaler@xxxxxxxxxxx
Cc: bbrown@xxxxxxxx; stds-802-3-hssg@xxxxxxxx
Subject: 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@xxxxxxxxxxx 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@xxxxxxxx]
> 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