Re: More comments (clauses 49 & 46)
Hi Rich,
In your case of
lane 0: DD
lane 1: DT
lane 2: DI
lane 3: DE
or all the case of /E/ been seen in the same column as /T/ but after /T/.
If it's from 64/66B PCS, I don't think we need to declare it as a
bad packet. If it's from 8B/10B PCS and the /E/ is a result of the
data. I think the FCS checker in the MAC will trash the packet.
In either case, it's ok for RS to treat it as a good packet.
Regards,
Louis
Ben Brown wrote:
> Rich,
>
> I completely agree with you. This is a fundamental difference
> between a serial link and parallel links (physically or
> optically). With the parallel link your example uses, the E
> directly follows part of the packet. In my example, the E
> directly follows an I.
>
> Thanks,
> Ben
>
> Rich Taborek wrote:
> >
> > Ladies and Gentlemen,
> >
> > (I apologize for the last runt message, I hit send by mistake and
> > couldn't snag the bits going down the wire in time)
> >
> > 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 1: DT
> > lane 2: DI
> > lane 3: DE
> >
> > The E could be the result of an error with the I (AKR) code-group being
> > received or a running disparity error. The PCS doesn't differentiate
> > between the two and mark the error with an /E/. Per Task Force
> > direction, the PCS moves running disparity errors detected in Idle
> > columns back into the Terminate column. In this case, a propagated
> > running disparity error would have been detected in the data. The simple
> > 10GBASE-X rule is that if /E/ occurs anywhere in ||T||, the packet
> > should be trashed. The enforcer would be the RS.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > 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
> >
> > -------------------------------------------------------
> > 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
>
> --
> -----------------------------------------
> 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
> -----------------------------------------