Re: More comments (clauses 49 & 46)
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
-----------------------------------------