Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3ae] Link Fault Signalling


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.

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,

"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 Group 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