Re: Local Fault/Remote faults
Tom,
Apparently it isn't too obvious from 46.3.4 or we wouldn't be
having this discussion. From my perspective, it is obvious but
I've been spending more time with my nose in this book than a
lot of the software driver folks who will eventually be writing
the drivers for these products we're all building. If we don't
make it plain to them how the process works, we'll be in no
better position than P802.3z was in.
I would strongly recommend system companies to get their software
driver engineers to read this document and then come back and
explain how they'd debug a potential implementation with the
use of LF, RF and all the individual status bits. If it isn't
obvious to those people, we haven't done our job well (or
somebody needs to get that first book on the market very
soon !)
Regards,
Ben
Tom Alexander wrote:
>
> Hi, Ben,
>
> Thanks for the correction - I mixed up /E/ characters with LF ordered sets.
> Should read my own e-mails more carefully. :-)
>
> I suppose the signaling of RF by the local STA could be used by the remote
> STA as a trigger to poll all of its sublayers for evidence of a fault. Is it at all
> worth mentioning anywhere that RF could be received as a consequence of
> a local fault in the transmit path, or is this obvious from 46.3.4?
>
> Regards,
>
> - Tom
>
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Tuesday, February 20, 2001 1:08 PM
> To: Tom Alexander
> Cc: 802.3ae
> Subject: Re: Local Fault/Remote faults
> Tom,
>
> Tom Alexander wrote:
> >
> > 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.
>
> There are no /E/ characters, only LF ordered_sets. The local PCS
> would forward them as if they were regular data and the RS would
> see the LF and respond with RF. The local STA would poll each
> device's status and find no problems, even with signal_detect,
> so the problem would have to be on the remote end.
>
> >
> > 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?
>
> The local STA would have to somehow alert the remote STA that
> there is a problem on that end and the remote STA would poll
> it's devices and find a TX sync problem in the PHY XGXS.
>
> Regards,
> Ben
>
> >
> > Cheers,
> >
> > - Tom
> >
> > -----Original Message-----
> > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > 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@xxxxxxxx
> > -----------------------------------------
>
> --
> -----------------------------------------
> 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
> -----------------------------------------
--
-----------------------------------------
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
-----------------------------------------