Re: More comments (clauses 49 & 46)
Ladies and Gentlemen,
I agree with Ben and Tripathi in general about looking too far into the
future to trash a packet. However, there are going to be some Clause 48
cases which should result in a trashed packet, one of those is the exact
example you describe:
Ben suggests that a Clause 49 frame of DDDDDTIE should not trash a
packet. However, the same sequence issued by the 8b/10b PCS would may be
the result of a packet error detected by 8b/10b running disparity
checking. For the 10GBASE-X PCS this sequence appears as:
lane 0: DD
lane 0: DD
Devendra Tripathi wrote:
>
> 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
--
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@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com