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.
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 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 http://www.intel.com