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]
> 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]
> 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]
> > 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]
> > 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]
> > > 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
Fax: 408-486-9783 http://www.intel.com