Re: More comments (clauses 49 & 46)
I strongly agree with Ben. I would have gone one step more (just T is good
to declare a good frame).
Looking for error to judge a link should be separated from looking for
error to declare a frame as good.
Tripathi.
At 01:32 PM 11/20/00 -0500, Ben Brown wrote:
>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
>-----------------------------------------
Best Regards,
Devendra Tripathi
Vitesse Semiconductor Corporation
3100 De La Cruz Boulevard
Santa Clara, CA 95054
Phone: (408) 986-4380 Ext 103
Fax: (408) 986-6050