Re: [802.3ae] Link Fault Signalling
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.
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.
> 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
Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783 http://www.intel.com