RE: [802.3ae] Link Fault Signaling due to FIFO under/over run
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,
> > Shawn
> > > -----Original Message-----
> > > From: Rich Taborek [ mailto:rtaborek@xxxxxxxxxxxxx
> <mailto:rtaborek@xxxxxxxxxxxxx> ]
> > > Sent: Monday, December 24, 2001 3:01 PM
> > > To: HSSG (E-mail)
> > > Subject: Re: [802.3ae] Link Fault Signalling
> > >
> > >
> > >
> > > Gal,
> > >
> > > You are correct. Fault recognition does not require the
> > usage of LF/RF
> > > sequences.
> > >
> > > Happy Holidays,
> > > Rich
> > >
> > > --
> > >
> > > "Ofek, Gal" wrote:
> > > >
> > > > Pat,
> > > >
> > > > re:"The RS does not poll the MDIO"
> > > > Of course, you're right!(formally...)
> > > >
> > > > re:"but if the PMD/PMA isn't getting good signal, the PCS
> > > will not be
> > > > able to get lock to the signal from the PMD/PMA"
> > > >
> > > > Still, in general, there will be cases in which a fault
> > > will be indicated
> > > > through the link status bit (1.1.7) and not
> > > > through the LF/RF sequences, right?
> > > >
> > > > Thanks
> > > > Happy&Merry Holidays
> > > > Gal Ofek
> > > > Intel Communications Group - ISRAEL(Omer)
> > > > Email: gal.ofek@xxxxxxxxx
> > > >
> > > > -----Original Message-----
> > > > From: THALER,PAT (A-Roseville,ex1) [ mailto:pat_thaler@xxxxxxxxxxx
> <mailto:pat_thaler@xxxxxxxxxxx> ]
> > > > Sent: Thursday, December 20, 2001 8:54 PM
> > > > To: rtaborek@xxxxxxxxxxxxx; HSSG (E-mail)
> > > > Subject: RE: [802.3ae] Link Fault Signalling
> > > >
> > > > Rich,
> > > >
> > > > I want to clarify something. The local fault bit in a
> > > device is only set
> > > > when the device detects a problem; for example low power or
> > > inability to
> > > > acquire sync. It is not set in response to receiving a
> > > Local Fault signal on
> > > > its input.
> > > >
> > > > Gal,
> > > >
> > > > The RS does not poll the MDIO. The RS is not required or
> > > expected to have a
> > > > connection to the MDIO. If the receive side of the link
> > > isn't working, the
> > > > RS should receive LF. True the PMD/PMA doesn't send LF when
> > > it detects a
> > > > fault, but if the PMD/PMA isn't getting good signal, the
> > > PCS will not be
> > > > able to get lock to the signal from the PMD/PMA.
> > > >
> > > > The purpose of the MDIO is to allow the local management to
> > > determine PHY
> > > > layer status and localize problems. The MDIO is not
> > > designed to support
> > > > multiple masters so it would be awkward to have the
> > > management agent and the
> > > > RS both poll the MDIO.
> > > >
> > > > Regards,
> > > > Pat
> > > >
> > > > -----Original Message-----
> > > > From: Rich Taborek [ mailto:rtaborek@xxxxxxxxxxxxx
> <mailto:rtaborek@xxxxxxxxxxxxx> ]
> > > > Sent: Wednesday, December 19, 2001 11:12 PM
> > > > To: HSSG (E-mail)
> > > > Subject: Re: [802.3ae] Link Fault Signalling
> > > >
> > > > Gal,
> > > >
> > > > Sorry about the late reply. Sometimes my email gets way backed up.
> > > >
> > > > Status register bit 1.1.7 is defined as Local Fault. This
> > bit is set
> > > > when a local fault condition exists. The local fault
> > > condition may have
> > > > been signaled via LF/RF signaling but this is only one
> > > possibility. The
> > > > others include LF detection at the receiver not via LF/RF
> > > signaling and
> > > > LF detection inboard of the receiver.
> > > >
> > > > Happy Holidays,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > > -----Original Message-----
> > > > > From: Ofek, Gal [ mailto:gal.ofek@xxxxxxxxx
> <mailto:gal.ofek@xxxxxxxxx> ]
> > > > > Sent: Monday, December 10, 2001 9:48 AM
> > > > > To: 'rtaborek@xxxxxxxxxxxxx'
> > > > > Cc: HSSG (E-mail)
> > > > > Subject: RE: [802.3ae] Link Fault Signalling
> > > > >
> > > > > Rich,
> > > > >
> > > > > Thanks but I would like one more clarification:
> > > > > Is the following true:
> > > > > it is not enough that the RS
> > > > > will relay totally on the Local/Remote fault signaling to
> > > report for
> > > > > link fault. It should also poll the link status bit (bit 1.1.7)
> > > > > in order to get a complete indication about the link status.
> > > > >
> > > > > Yes?
> > > > >
> > > > > Thanks
> > > > > Gal
> > > > >
> > > > > -----Original Message-----
> > > > > From: Rich Taborek [ mailto:rtaborek@xxxxxxxxxxxxx
> <mailto:rtaborek@xxxxxxxxxxxxx> ]
> > > > > Sent: Sunday, December 09, 2001 11:18 PM
> > > > > Cc: HSSG (E-mail)
> > > > > Subject: Re: [802.3ae] Link Fault Signalling
> > > > >
> > > > > Gal,
> > > > >
> > > > > No. I was creating a distinction between the stages of a
> > > link fault and
> > > > > the reporting of the fault. Here's a more complete
> > > distinction in the
> > > > > life of a fault. and LF
> > > > >
> > > > > a) the existence of a link fault condition;
> > > > > b) the recognition and of the link fault condition (note
> > > that some link
> > > > > fault conditions may not be detected and recognized,
> > > preventing their
> > > > > reporting by a local fault message);
> > > > > c) the reporting of a recognized link fault condition via
> > > a local fault
> > > > > message (note that this requires a "fault message
> > > reporting facility"
> > > > > such as an 8B/10B PCS or equivalent);
> > > > >
> > > > > In most cases, a link fault condition is recognized at
> > > the DTE through
> > > > > either reception of a local fault message or detection of
> > > a link fault
> > > > > condition. An example of a link fault condition which may escape
> > > > > detection and recognition by any link element including
> > > the DTE's is a
> > > > > receiver failure where crosstalk from the associated
> > > transmitter covers
> > > > > up failure condition at the receiver.
> > > > >
> > > > > I hope this explanation helps,
> > > > > Best Regards,
> > > > > Rich
> > > > >
> > > > > --
> > > > >
> > > > > "Ofek, Gal" wrote:
> > > > > >
> > > > > > Do you mean that a situation in which a link is down
> > > (fault condition)
> > > > > > but no local fault will be generated is allowed?
> > > > > >
> > > > > > Thanks
> > > > > > Gal
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rich Taborek [ mailto:rtaborek@xxxxxxxxxxxxx
> <mailto:rtaborek@xxxxxxxxxxxxx> ]
> > > > > > Sent: Sunday, December 09, 2001 7:32 AM
> > > > > > Cc: HSSG (E-mail)
> > > > > > Subject: Re: [802.3ae] Link Fault Signalling
> > > > > >
> > > > > > Chuck,
> > > > > >
> > > > > > I'll address two issues here. One is yours, the other
> > > is other is
> > > > > > related to kicking off Fault Messages.
> > > > > >
> > > > > > 1) Unidirectional link behavior is not supported
> > > because it does not fit
> > > > > > the scope of Ethernet objectives. Specifically, a
> > > full-duplex link
> > > > > > cannot be reinitialized properly when a fault occurs if
> > > no feedback
> > > > > > mechanism is provided to insure that both link
> > > directions participate in
> > > > > > initialization. I understand your point about this mode
> > > of operation
> > > > > > being about the scope of 802.3ae (and 802.3 in
> > > general). However, even
> > > > > > protocols like SONET provide other mechanisms, such as
> > > DCC channels to
> > > > > > accomplish the same thing. The problem is that the DCC
> > > channel is only
> > > > > > the feedback mechanism and provides no help in
> > > resolving the actual
> > > > > > fault, which is likely to require manual intervention
> > > upon fault if the
> > > > > > link is properly designed.
> > > > > >
> > > > > > 10GE employs LF/RF protocol as a means of quickly
> > > determining the
> > > > > > operational state of a link. If the link is not
> > operational, an
> > > > > > alternate link should be switched in.
> > > > > >
> > > > > > 2) Local Fault Ordered Sets are only generated upon
> > > detection of a link
> > > > > > fault condition when a capability exists that can
> > > generate Local Fault
> > > > > > Ordered Sets. Some sublayers and link elements such as
> > > PMDs, retimers
> > > > > > and PMAs may have the capability of detecting link
> > > fault conditions but
> > > > > > not of generating Local Fault Ordered Sets. In this
> > > case, no error may
> > > > > > be reported at all or an error may be reported through
> > > an alternate
> > > > > > means. IEEE 802.3ae has no requirement to generate
> > > local fault ordered
> > > > > > sets upon detection of a link fault condition.
> > > > > >
> > > > > > Best Regards,
> > > > > > Rich
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Chuck Harrison wrote:
> > > > > > >
> > > > > > > Ben, all --
> > > > > > >
> > > > > > > Ben Brown wrote:
> > > > > > > >
> > > > > > > > > > [BC] Thanks for the replies. My understanding
> > > now is as follows:
> > > > > > > > > >
> > > > > > > > > > 1. If a fault is detected on the receive path,
> > > at the PMD or
> > > > > > > > > > the PMA, Local Fault Ordered Sets (LFOS)
> > > will be transmitted
> > > > > > > > > > by the PCS to the RS. Consequently, the RS
> > > will send Remote
> > > > > > > > > > Fault Ordered Sets (RFOS) to the PCS.
> > > > > > > >
> > > > > > > > [BB] This is correct.
> > > > > > >
> > > > > > > Agree 100%, this is the standard behavior and *must*
> > > be supported.
> > > > > > >
> > > > > > > However, I recommend that silicon manufacturers implementing
> > > > > > > RS consider whether they also wish to support a non-standard
> > > > > > > mode in which LF->RF reflection does *not*
> > > automatically occur.
> > > > > > > This would allow their products to work in
> > application niches
> > > > > > > using a *unidirectional* optical link. (The transmit
> > > end always
> > > > > > > sees a receive LF, but goes on talking anyway.)
> > > > > > >
> > > > > > > I recognize this is outside the scope of 802.3ae, but some
> > > > > > > industry segments would value this capability.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Chuck Harrison
> > > > > > > Far Field Associates, LLC
> > > > > > > member, SMPTE DC28.1 Steering Committee on Digital Cinema
> > >
> > > ---------------------------------------------------------
> > > 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
> <mailto:rich.taborek@xxxxxxxxx>
> > > Fax: 408-486-9783 http://www.intel.com
> <http://www.intel.com>
> > >
> >
---------------------------------------------------------
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