Re: More comments (clauses 49 & 46)
Pat,
In your response below, you are willing to error a
frame that has 5 octets of idle after the T character
before there are any errors. That seems to me to require
quite a lot of delimiter robustness! In fact, if I
follow through with your line of reasoning, the delimiter
robustness ranges between 0 & 7 octets of idle following
the T depending upon which lane the T lines up in (unless
of course, should the last word of a packet end in
DDDDDDDT, you check that the next word is all idles
then the range is from 1 to 8 octets). Anyway, I'm
tempted to think that it is only necessary to trash the
T word if the octet following it is not an idle or,
conversely, is an E (I think there is a subtle difference).
I'm not sure we want to extend our delimiter robustness
by that many octets. Yes, it will make the definition
a bit more difficult but it is probably worth it.
In other words, DDDDDTIE is passed as is and the packet
should be received while DDDDDTEI is replaced with 8
octets of E and the packet is trashed. All 8 flavors of
this must be defined according to the alignment of the T.
Thoughts?
Ben
"THALER,PAT (A-Roseville,ex1)" wrote:
>
> 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
--
-----------------------------------------
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@xxxxxxxx
-----------------------------------------