RE: [802.3ae] Link Fault Signalling
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