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

RE: Local Fault/Remote faults




Hi, Ben,

I think Tim's issue, which echoes a question I had as well, relates to
an LF being generated by the transmit path of some far-end PHY sublayer
and being propagated down the link to the local PHY. Note that D2.1
Clause 46.3.4 (Page 264, lines 33 + 34) states that:

"Though most fault detection is on the receive data path of a PHY, in
some specific sublayers, faults can be detected on the transmit side
of the PHY. This is also indicated by the PHY with a Local Fault status."

It would seem to me that this LF status would have to be transmitted
by the remote PHY down the regular path to the fiber and finally to the
local PHY in order to generate a proper RF indication coming back.
Clearly, in this case the local PHY will not detect any loss of sync
(it's getting good signal), and the local RX PCS will simply pass along
the /E/ characters to the RS. I'm not exactly sure what the MDIO
registers on the local PHY will be reporting at this time, but I can't
seem to find any bits that allow a remotely generated LF to be clearly
distinguished from a locally generated LF.

Is this interpretation correct, and, if so, does this mean that the only
way to unambiguously resolve the problem would be to attach a console
to the remote equipment and query its PHY?

Cheers,

- Tom

-----Original Message-----
From: Ben Brown [mailto:bbrown@amcc.com]
Sent: Tuesday, February 20, 2001 9:45 AM
To: 802.3ae
Subject: Re: Local Fault/Remote faults


Tim,

Let me ask a few clarifying questions:

Tim Warland wrote:
>
> Before submitting as a comment, I wanted some feedback
> from the community.
>
> 46.3.4  Fault signalling.  As defined, local fault is declared for any fault
> which occurs between the remote RS and the local RS. Remote fault is
> defined as any fault which occurs between the local RS and the remote
> RS. This signalling is still inadequate for in-system failure correction.
> For example: If the remote LAN equipment has a failure in the PCS layer,
> this will be declared to the local RS as a local fault.

Where is the local fault generated in this example? Is it at
the local RX PCS because it can't get sync? Is it at the local
PMA/PMD because it can't get signal_detect? I assume it's one
of these.


> The far end will
> still receive data (as defined).

With the local end detecting LF, the local RS will respond with
RF, not receive data. The remote RS will detect the RF and know
there's something wrong between it and the local RS.

> Since the local port is in LF, the operator
> would query the MDIO (if installed) to determine the source of the
> fault. The local RS may or may not be transmitting data at this time.

As stated above, the local RS will not be transmitting data, it will
be transmitting RF.

> Discovering no fault, the operator would run local diags to isolate the
> source of the local fault.

Why won't it find any faults? If the remote PCS is broken, then
the local PCS won't get sync. There should be a problem there.

> In the meantime, the far end device which is
> the source of the error has no why of knowing it has a problem.

The remote RS detects the RF from the local RS.

> When the local operator has gone through the all built-in checks and
> found nothing (likely changed the line card just to be sure), the
> port is reconnected to discover the LF is still present. The local
> operator must then inform the remote operator that the fault
> may be in that system even though the remote system displays
> no fault condition.

The local operator would still likely have to report to the
remote operator that there is a problem but it should be
able to provide information such as the local PCS can't get
sync. When the remote end runs diagnostics, such as PMD of
external loopback, it will likely also not be able to get sync.

> Suggested remedy:  Change the signalling so that LF defines
> a failure between the input to the PMD and the RS. RF defines
> a failure between the remote RS and the local PMD input. This requires
> another bit in table 46-4 defined as far-end fault.

In our current design, the only place this would apply is the
PHY XGXS can't get sync in the TX direction, or perhaps the TX
PCS is still in reset (but the gearbox and scrambler aren't?).
No other place can actually put a different encoding onto the
wire.

> Far-end
> fault (FEF) is the feedback mechanism in the RS to RS communication.
> When the RS receives an RF, it clears the RF and sets the
> FEF.  When an RS receives a FEF, it knows the error is in its
> transmit path.
> Similarly a LF condition is terminated by the RS. The remote
> device does not know that the local device is broken, since
> there is no corrective action to be taken at the remote site.
> This can be communicated in the MAC to MAC layers.

Separating "some of" the TX side faults from the RX side faults
could be marginally useful but I think we currently have enough
debug information in the register bits to allow both sides to
work together to solve the problem.

Regards,
Ben

>
> --
> Tim Warland     P.Eng.
> Hardware Design Engineer  Broadband Products
> High Performance Optical Component Solutions
> Nortel Networks                (613)765-6634
>
>


--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@amcc.com
-----------------------------------------