RE: [802.3ae] Link Fault Signaling due to FIFO under/over run
I think this meets the objective or being an editorial word-to-the-wise.
--Bob
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Friday, February 08, 2002 10:22 AM
To: Geoff Thompson
Cc: Grow, Bob; HSSG (E-mail); Eric Lynsky
Subject: Re: [802.3ae] Link Fault Signaling due to FIFO under/over run
All,
Here's the editorial wording I'd like to propose to be added to Clause
48 to provide guidance for 10GBASE-X fault and error indication usage:
1) Add as item f) to 48.1.1 Objectives the following:
f) Support error and link indication.
(the period at the end of e) should be changed to a semicolon)
2) In 48.2.4.4 Error /E/, change the second sentence as follows:
"/E/ may also be generated by the PCS client to indicate a
transmission error to its peer entity or deliberately corrupt
the contents of the frame in such a manner that a receiver
will detect the corruption with the highest degree of
probability".
How's that? Please note that Pat may need to add similar wording to
Clause 49.
Best Regards,
Rich
--
Geoff Thompson wrote:
>
> All-
>
> My guess on this is, given the text that Rich has pointed out, that all
> that is necessary is a note that lcarifies things a little and points to
> the text that Rich noted.
>
> Since it would only be a note and really only a heads up to something that
> already exists then it would be my opinion that it is editorial.
>
> Geoff
>
> At 02:31 PM 2/7/02 -0800, Grow, Bob wrote:
>
> >Rich:
> >
> >While a change to the draft may not be necessary, it may be advisable to
add
> >something to PCS that reminds people to do the things that assure
> >robustness. Too often, something that is obvious to one person is obtuse
to
> >another. I would encourage a recirculation ballot comment. The worst
> >outcome would be implementions that add or drop data without inserting
/E/
> >because the implementer didn't make the same extrapolation you and I do
from
> >the clause 46 text.
> >
> >--Bob Grow
> >
> >-----Original Message-----
> >From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> >Sent: Thursday, February 07, 2002 12:06 PM
> >To: HSSG (E-mail)
> >Subject: Re: [802.3ae] Link Fault Signaling due to FIFO under/over run
> >
> >
> >
> >Shawn,
> >
> >Yours is a good question. The most applicable words I can find in the
> >document are in Clause 46, 46.3.3.2, Conditions for generation of
> >transmit Error control characters, which says: "If, during the process
> >of transmitting a frame, it is necessary to request that the PHY
> >deliberately corrupt the
> >contents of the frame in such a manner that a receiver will detect the
> >corruption with the highest degree of probability, then an Error control
> >character may be asserted on a transmit lane by the appropriate encoding
> >of the lane's TXD and TXC signals."
> >
> >This would seem to allow a PCS to do the same for a FIFO
> >underrun/overrun where sync and deskew is not affected. I would not
> >invoke link fault protocol. It should be noted that this condition
> >should not occur if all P802.3ae specs are followed and also that the
> >nature of this error is such that it may be fairly deterministic. In my
> >opinion no change to the draft is necessary.
> >
> >Best Regards,
> >Rich
> >
> >--
> >
> >"THALER,PAT (A-Roseville,ex1)" wrote:
> > >
> > > In a FIFO underrun/overrun, the PCS is not able to faithfully output
the
> > > same data stream that it received. It should not silently corrupt the
data
> > > by stuffing or dropping characters. Therefore, in the underrun case it
> > > should stuff with /E/. In the overrun case, it should insert at least
one
> > > column of /E/ into the data stream where it has dropped characters
from
> >the
> > > FIFO (which will mean it will have to drop an extra column.
> > >
> > > I don't think either PCS definition says this explicity. The same
applies
> >to
> > > the WIS. This material has all been through sponsor ballot without
anyone
> > > raising this. (Actually, I think that 1 Gig also doesn't say anything
> >about
> > > what to do for underrun/overrun.)
> > >
> > > Someone could put in a recirc comment to add an explicit statement. If
so,
> > > it shouldn't mention "FIFO" because that is an implementation
dependent
> > > term. It should refer to something like "clock skew compensation"
instead.
> > > The task force will then have to decide whether this justifies a
technical
> > > change on a new issue.
> > >
> > > Regards,
> > > Pat
> > >
> > > -----Original Message-----
> > > From: Rogers, Shawn [mailto:s-rogers@xxxxxx]
> > > Sent: Wednesday, January 23, 2002 8:46 AM
> > > To: rtaborek@xxxxxxxxxxxxx; pat_thaler@xxxxxxxxxxx
> > > Cc: HSSG (E-mail)
> > > Subject: RE: [802.3ae] Link Fault Signaling due to FIFO under/over run
> > >
> > > Pat, Rich, I didn't get a chance to ask you this last week in Raleigh.
Do
> > > you have any comments on how the PCS should handle a FIFO under/over
run
> > > condition?
> > >
> > > Regards,
> > > Shawn
> > >
> > > > -----Original Message-----
> > > > From: Rogers, Shawn
> > > > Sent: Monday, January 14, 2002 4:22 PM
> > > > To: 'rtaborek@xxxxxxxxxxxxx'; 'pat_thaler@xxxxxxxxxxx'
> > > > Cc: HSSG (E-mail)
> > > > Subject: RE: [802.3ae] Link Fault Signaling due to FIFO under/over
run
> > > >
> > > >
> > > > Rich, Pat, on a slightly different tack:
> > > >
> > > > if a PCS encounters a FIFO under/over run condition, but is
> > > > still frame and or column synchronized, it should still post
> > > > a LF to the RS. The condition I'm thinking of is handling a
> > > > jumbo packet or a jabbering station. The question is how
> > > > should the PCS come out of the under/over run condition?
> > > >
> > > > Should it:
> > > > a. wait for MDIO intervention to clear it's link fault condition?
> > > > b. wait for idles on the in-bound path?
> > > > c. something else in clause 48 or 49 I haven't read yet.
> > > >
> > > > Regards,
---------------------------------------------------------
Richard Taborek Sr. Intel Corporation
XAUI Sherpa Intel Communications Group
3101 Jay Street, Suite 110 Optical Strategic Marketing
Santa Clara, CA 95054 Santa Clara Design Center
408-496-3423 JAY1-101
Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783 http://www.intel.com