RE: [802.3ae] Link Fault Signaling due to FIFO under/over run
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,
> > > 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