RE: Local Fault/Remote Fault
The proposal we adopted in November said we would add a signal. Doing so is
preferable to requiring adding multiple squelch circuits. Clauses 49, 50,
and 53 all incorporated a primative for this signal. The direction we chose
in November works and it isn't the time to be inventing except where needed
to fix something broken. If pieces necessary to our November decision where
left out of the draft, we need to add them.
From: Stephen.Finch@xxxxxx [mailto:Stephen.Finch@xxxxxx]
Sent: Tuesday, January 02, 2001 7:03 AM
Subject: 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".
pat_thaler@xxxxxxxxxxx on 12/31/2000 01:30:28 PM
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.
> > Station management can obtain each device's status and localize
> > the problem.
> > What I found in the standard is in the following clauses:
> > 18.104.22.168.3
> > 22.214.171.124.7
> > 126.96.36.199.7
> > 188.8.131.52.3
> > 184.108.40.206.3
> > 220.127.116.11 (last paragraph)
> > 46.2.6
> > Table 46-4
> > 18.104.22.168
> > 48.2.2
> > 22.214.171.124 and 126.96.36.199.1
> > Figure 48-10
> > 188.8.131.52 and 184.108.40.206.1 and 220.127.116.11.2
> > 18.104.22.168
> > 22.214.171.124.1 (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
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 http://www.nSerial.com