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

RE: Local Fault/Remote faults


I have a question about generating Local Fault in TX
direction. It is embeded in this email.


-bipin d. dama
 (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
> 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
> -----------------------------------------