RE: Local Fault/Remote Fault
Steve,
Generally I agree with you, but there are a couple of points I think you
missed.
> > 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 lock
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 zeros
or ones is how the next device would know to either send the fault signal
(if it is still below the PCS) or the local fault pulse ordered set up the
stack. Only on the transmit path does a device need to force all zeros or
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 ordered
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 when
they detect a fault condition. When XGXS and 10GBASE-X PCS detects repeated
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:
> >
> > 45.2.1.2.3
> > 45.2.2.1.7
> > 45.2.3.1.7
> > 45.2.4.2.3
> > 45.2.5.2.3
> > 46.2.5.1 (last paragraph)
> > 46.2.6
> > Table 46-4
> > 48.1.3.1
> > 48.2.2
> > 48.2.4.5 and 48.2.4.5.1
> > Figure 48-10
> > 48.2.5.4 and 48.2.5.4.1 and 48.2.5.4.2
> > 49.2.4.5
> > 49.2.11.1.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 message.
>
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 to
process the signal. That is, loss of signal, loss of sync, loss of lock. It
should not include receiption of a local fault message.
Also, I have written comments about clause 45's usage of receive, transmit,
outbound, and inbound which I feel is not consistant with other 802.3 usage.
802.3 normally uses Rx to describe the path from the MAC to the MDI and Tx
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 proposed
> > fixes.
>
> Go for it!
>
> > Steve Finch
--
Happy Holidays,
Rich
-------------------------------------------------------
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