RE: Local Fault/Remote faults
Ben,
I have a question about generating Local Fault in TX
direction. It is embeded in this email.
Thanks
-bipin d. dama
bipin_dama@xxxxxxxxxxxxxx
(610) 289 5218
> -----Original Message-----
> From: Ben Brown [SMTP:bbrown@xxxxxxxx]
> Sent: Tuesday, February 20, 2001 12:45 PM
> 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.
>
Suppose that we have XAUI retimers on both ends of the fiber.
MAC1->RS1_TX->PCS1_TX->XAUI-RETIMER1_TX -> ---------- FIBRE ---------> XAUI-RETIMER2_RX->RS2_RX->MAC2
MAC1<-RS1_RX<-PCS1_RX<-XAUI-RETIMER1_RX<- ----------- FIBRE ---------<-XAUI-RETIMER2_TX<-RS2_TX<-MAC2
What happens when the XAUI-RETIMER2_TX losses sync ? Is it suppose to generate Local Fault ? If the answer is
yes, then what additional value does it bring as compared to doing nothing ? If it does nothing then the XAUI-RETIMER1_RX
will loose sync and will generate Local Fault due to receiving junk.
As generation of this Local Fault does not help in fault isolation, I suggest we dont require that a Local Fault be generated
towards the Fibre.
> > 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
> -----------------------------------------