Re: Link Status thoughts
Hi Rich,
Just one small comment on following part. It may not be possible (or worth
figuring out) to distinguish
between remote fault and local fault if they happen in the same direction.
To me local fault is if
I can not transmit and remote fault is if I can not receive. If we could go
beyond this (like if I knew that receiving
transceiver is not functioning), it could be defined as local fault but it
may be going into more of detail OAM&P.
Regards,
Tripathi.
>The most complex scenario involving Remote Fault and Local Fault that I
>can envision is one where both Remote Fault and Local Fault conditions
>exist for the same link, in the same direction. For the sake of
>completeness, the Remote Fault and Local Fault transport protocol should
>allow for the indication of all combinations of these two conditions.
>Note that this scenario is not covered in the latest RF/BL proposal from
>Shimon Muller.
>
>I'd be honored to work on a common Link Initialization and Link Status
>Reporting protocol presentation with you for Tampa.
>
>Best Regards,
>Rich
>
>--
>
>pat_thaler@agilent.com wrote:
> >
> > Ben,
> >
> > Link_status is not complete at the PCS. The XAUI link
> > is long enough that it is possible that a marginal
> > device has been attached and lock is not obtained.
> > We can have the case where an XGXS connects to a
> > daughter card or transceiver module and that device
> > is not present. Also, as you point out, a DTE XGXS
> > can function as a PCS.
> >
> > For indicating a local fault in the receive direction,
> > this is pretty simple to cope with. For the sake of
> > easing the discussion, lets say that the status line
> > is a local fault line - asserted when there is loss
> > of signal, loss of lock, or loss of sync. It may be
> > an inband signal or an out of band signal.
> >
> > At each sublayer, the local fault out (going up the chain)
> > should then be the OR of the local fault in (from
> > the direction toward the MDI) and the internal fault
> > detection (loss of signal, loss of lock, loss of sync)
> > of the sublayer.
> >
> > If the signal is out of band, this is just an OR gate.
> > If the signal is in band, then if I'm getting valid
> > signal from below I send it on - if the layer below
> > has detected a local fault the signal I forward will
> > indicate the local fault. If I'm not getting valid
> > signal from below, I send the local fault in band signal.
> >
> > I would suggest that we either keep local fault out of
> > band all the way up the chain or we convert it from
> > out of band to in band at the PCS. My preference would
> > be the latter though the one concern I have is it uses
> > more of our fairly limited code space to signal it simply.
> >
> > I have thought of one way around the code space problem.
> > Right now in the Muller proposal, RF is signaled on
> > all 4 lanes. One could send the RF code word on two lanes
> > with K or R on the other two lanes and reuse the same
> > code word for LF but put it on the other two lanes or
> > across all 4 lanes (in case one is worried about lane
> > mix-ups). This is a small complication of the Muller
> > proposal since currently the same thing is sent on
> > all 4 lanes, but perhaps no more difficult to implement
> > then having two kinds of code and it preserves our
> > unused code space.
> >
> > The other question you raise is what do we do when the
> > receive link is fine but there is a problem on the
> > transmit side between the MAC and the MDI. For instance
> > a PHY XGXS can't get sync on the XAUI sighal. I think
> > that that should also assert local fault toward the MAC.
> > Identifying the exact nature of the local fault should
> > be left to the MDIO registers. That still leaves the
> > question of what that PHY XGXS should transmit. Candidates
> > arme:
> > Remote Fault
> > Local Fault
> > Idle
> > yet another signal.
> >
> > If we send Remote Fault then Remote Fault's meaning becomes
> > the other end of the line detects a problem. The problem
> > might be in the receive or transmit side, but something
> > isn't in lock over there. You have to go over to the remote
> > node to narrow it down.
> >
> > If we send Local Fault, then Local Fault becomes more like
> > Receive fault - there is a problem somewhere between the
> > transmit of the other MAC and me - and Remote Fault is
> > a Transmit fault - there is a problem between my MAC transmit
> > and the other MAC's receive. To figure out if the "Local
> > Fault" is from the other guy's Phy I have to query my
> > sublayers via MDIO to see if any of them is out of lock
> > and generating Local Fault. This seems better to me
> > but it implies we should change the signal names.
> >
> > If we send Idle, then it seems a hole in our fault detection.
> > Why do we bother to publish some faults to the remote node
> > and leave out others?
> >
> > A new signal - I really want to keep this simple and our
> > code space for simple signals is limited so I'd rather
> > not do this one.
> >
> > I'll try to get a presentation ready for next week.
> >
> > Pat
> >
> > -----Original Message-----
> > From: Ben Brown [mailto:bbrown@amcc.com]
> > Sent: Tuesday, October 31, 2000 5:46 PM
> > To: 802.3ae
> > Subject: Re: Link Status thoughts
> >
> > Pat,
> >
> > Would link_status be complete at the PCS? What if a
> > XAUI link was used to extend the XGMII? Does this
> > need any indication of the link from the PCS toward
> > the MDI? What about the case of a DTE XGXS turned
> > into a PCS because the PHY XGXS/PCS/PMA is really
> > only a retimer? Does the DTE XGXS not care about
> > signal_detect in one case but care about it in the
> > other?
> >
> > All these cases show me a pretty confusing picture.
> > I'm hoping someone can enlighten all of us next
> > week :)
> >
> > Ben
> >
> > pat_thaler@agilent.com wrote:
> > >
> > > Ben,
> > >
> > > I've looked at your slides. I'm not sure if you intend all
> > > the signals shown coming out of blocks (especially those on
> > > slides 8 and 10) to be pins. If so, that is way too many
> > > pins for link status.
> > >
> > > What I propose is one pin from the PMD to the PMA indicating
> > > whether the link is good (that is, signal detect is okay on
> > > all inputs) or not. One pin from the PMA to the PCS/WIS
> > > indicating whether the receive link at the PMA and below
> > > is okay. That would be an AND of the signal it gets from
> > > the PMD and the PMA's lock signal. The WIS to PCS interface
> > > is only defined as a logical interface, so it would have
> > > a message defined to pass whether the link below was up -
> > > the AND of the signal it gets from the PMA and its frame
> > > sync acquired status.
> > >
> > > Pat
> > >
> > > -----Original Message-----
> > > From: Ben Brown [mailto:bbrown@amcc.com]
> > > Sent: Thursday, October 26, 2000 8:44 AM
> > > To: 802.3ae
> > > Subject: Link Status thoughts
> > >
> > > Hey,
> > >
> > > After a discussion some of us had during the editorial
> > > meeting yesterday, I thought I'd put some of our thoughts
> > > down on paper. There are still quite a few questions
> > > buried in these slides. Anyone with comments, please
> > > feel free to share them. I'd like to have these comments
> > > before the November meeting so we can put a proposal on
> > > the table.
> > >
> > > Thanks,
> > > Ben
> >
> > -----------------------------------------
> > Benjamin Brown
> > AMCC
> > 2 Commerce Park West
> > Suite 104
> > Bedford NH 03110
> > 603-641-9837 - Work
> > 603-491-0296 - Cell
> > 603-647-2291 - Fax
> > 603-798-4115 - Home Office
> > bbrown@amcc.com
> > -----------------------------------------
>
>-------------------------------------------------------
>Richard Taborek Sr. Phone: 408-845-6102
>Chief Technology Officer Cell: 408-832-3957
>nSerial Corporation Fax: 408-845-6114
>2500-5 Augustine Dr. mailto:rtaborek@nSerial.com
>Santa Clara, CA 95054 http://www.nSerial.com
Best Regards,
Devendra Tripathi
Vitesse Semoconductor Corporation
3100 De La Cruz Boulevard
Santa Clara, CA 95054
Phone: (408) 986-4380 Ext 103
Fax: (408) 986-6050