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

RE: Local Fault/Remote Fault

Okay, we need a signal.  Or do we?  A PMA/PMD device can attach to a PCS
device using the XSBI bus.  But I don't see a signal called loss of
signal or loss of lock.  So, either we add such a signal, admit that the
XSBI isn't complete enough to do its job, OR  use the bus in a way that
"signals" these conditions by another means, such as sending all zeros
or all ones.

So, I went off and invented something new that works.

The question is, do we want to add another signal to XSBI?  I don't.
One could add an implementation dependent signal, but then the purpose
of the standardizing XSBI just bit the dust.

I suggest we don't add a new signal.  I suggest we state that if a
PMA/PMD "can't say something nice", then "shouldn't say anything at
all", and define the "all" as "all zeros".


Steve Finch

pat_thaler@xxxxxxxxxxx on 12/31/2000 01:30:28 PM

To:   rtaborek@xxxxxxxxxxxxx
cc:   stds-802-3-hssg@xxxxxxxx
Subject:  RE: Local Fault/Remote Fault


Generally I agree with you, but there are a couple of points I think you
> > Here are the concepts I think we need to communicate:
> >
> > 1.  Any device, in either its transmit or receive paths, could
> >     detect a fault condition.  The fault may be that the data
> >     being received is invalid or that some internal problem
> >     is causing the problem.  Some/many faults may go
> >     undetected.  If a device detects a fault condition (i.e.,
> >     a locally detected fault) it should set its link status
> >     to zero and not forward what is received, but should,
> >     at its output, either:
> >
> >   a.  generate a local fault pulse ordered set if it is
> >       capable of doing so,
> > or
> >   b.  generate all zeros or all ones, making it probable that
> >       the next device in the link will detect the problem and
> >       (hopefully) generate a local fault pulse ordered set.
PMD/PMA devices that detect problems such as loss of signal or loss of
on the receive signal are also suppose to generate a signal to the next
higher layer. So on the receive path, that signal rather than the all
or ones is how the next device would know to either send the fault
(if it is still below the PCS) or the local fault pulse ordered set up
stack. Only on the transmit path does a device need to force all zeros
all ones in response to fault detection.
> > 2.  All devices not detecting fault conditions should forward
> >     whatever is received.  Local fault pulse ordered sets and
> >     remote fault pulse ordered sets may be generated by other
> >     devices and, when received, must be forwarded on.  With the
> >     exception of the RS layer, receiption of a Local fault
> >     ordered set or a remote fault ordered set must have no
> >     effect on the device receiving these pulse ordered sets.
The XGXS and 10GBASE-X PCS do need to detect the local fault pulse
sets so that they can mitigate the EMI impact. Sublayers like RS and
10GBASE-R PCS send pulse ordered sets alternating with 4 bytes of idle
they detect a fault condition. When XGXS and 10GBASE-X PCS detects
pulse ordered sets or when it detects a fault, it will send the pulse
ordered set once after each A column until the condition clears.
> > 3.  The RS layer is where the Local Fault Pulse Ordered Set is
> >     processed.  The RS layer is the only place that a Remote
> >     Fault Pulse Ordered Set can be generated.  If an RS receives
> >     a Local Fault Pulse Ordered Set it must stop sending packets
> >     and begin sending alternating columns of Idles and Remote
> >     Fault Pulse Ordered Sets.  If an RS receives a Remote Fault
> >     Pulse Ordered Set, it must stop sending packets and send
> >     only Idles.
Correct except for the EMI mitigation above.
> > Devices detecting fault conditions set their link status to 0
> > and attempt to generate LF's (local fault ordered sets).  In some
> > cases, multiple devices may be detecting faults and attempt to
> > send LF's.
> Correct.
> > Station management can obtain each device's status and localize
> > the problem.
> Correct.
> > What I found in the standard is in the following clauses:
> >
> >
> >
> >
> >
> >
> >    (last paragraph)
> > 46.2.6
> > Table 46-4
> >
> > 48.2.2
> > and
> > Figure 48-10
> > and and
> >
> >  (definition of LFRAME_R)
> > Figure 49-14 --> top state
> >
> > I don't think these "pieces" capture what we need.  In fact, the
> > inconsist usage of terms is confusing.  For example, what
> > does "detected a local fault signal on the inbound path" mean?
> Loosely translated, inbound path is any devices receiver. Local fault
> signal could be a Loss_of_Signal, loss-of-sync, or local fault
I have written comments about the text that Steve quoted above. Devices
should not generally be expected to detect receipt of the local fault
message. The local fault bit should reflect the device's own inability
process the signal. That is, loss of signal, loss of sync, loss of lock.
should not include receiption of a local fault message.

Also, I have written comments about clause 45's usage of receive,
outbound, and inbound which I feel is not consistant with other 802.3
802.3 normally uses Rx to describe the path from the MAC to the MDI and
to describe the path from the MDI to the MAC.

> > I think we need some standardized terms used through out.
> > And I think we need a basic description (better written than what
> > I did above) place somewhere in the intro and not in one of
> > the "component" pieces where it could be missed by others.
> >
> > Before I start on what I think should be done, I'd like confirmation
> > that my description above is correct.  I'll then start on my
> > fixes.
> Go for it!
> > Steve Finch


Happy Holidays,

Richard Taborek Sr.                 Phone: 408-845-6102
Chief Technology Officer             Cell: 408-832-3957
nSerial Corporation                   Fax: 408-845-6114
2500-5 Augustine Dr.        mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054