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@xxxxxxxx
-----------------------------------------