GbE Remote Fault signaling via Auto Negotiation
JR,
The problem is with use of GbE AN protocol, which requires full-duplex link
handshakes to successfully complete, to signal a Loss_of_Signal condition via a
Remote Fault indication. Since AN does not complete, the RF information is not
available for most practical purposes.
I agree that one can specify a "one way ordered set" to signal remote fault.
However, that's not the way it's currently done.
I would support an objective to reliably signal remote fault on 10 GbE. Therefore,
if 10 GbE uses GbE AN to do this, either the protocol must be modified or the
interpretation of AN results must be modified.
Best regards,
Rich
--
JR Rivers wrote:
> I think that we are starting to talk in circles here...
>
> If you can use a "one way ordered set" to signal remote fault, then you can
> use an "auto-negotiation like" interface to do the same thing (along with
> the traditional signalling performed during AN). Is the problem that you
> refer to below related to the signalling (as seen on the cable), or with
> the operation of the AN state machines?
>
> JR
>
> At 12:44 AM 11/18/99 -0800, Rich Taborek wrote:
> >
> >JR,
> >
> >I agree with Brad on this one. I didn't make this clear in my last note, but
> >Remote Fault in GbE was designed to signal conditions like Loss_of_Signal at
> >the remote receiver. However, AN cannot successfully complete in this case
> >since it required full duplex link operability. So even though the proper RF
> >information may be reported to the local device, that device is not sure
> how to
> >handle the RF/AN failure condition.
> >
> >The "fix" I alluded to in my previous note is to use a specific one way code
> >(e.g. ordered-set) to indicate this condition rather than requiring a
> >successful full-duplex handshake when full-duplex operation is not possible.
> >Alternatively, AN protocol can be modified to have a receive always treat RF
> >info received from a remote device as valid, even if AN protocol fails.
> >
> >Best regards,
> >Rich
> >
> >--
> >
> >"Booth, Bradley" wrote:
> >
> >> JR,
> >>
> >> I agree that if it is done correctly, then signaling link faults via
> >> auto-negotiation is quite elegant. The problem lies in the fact that link
> >> fault (or remote fault) signaling was optional and it was sometimes
> >> misinterpreted by the implementor. Remote fault indication in the
> >> auto-negotiation base page was a source of numerous problems during the UNH
> >> IOL connectivity tests, as was it an issue during Microsoft certification
> >> testing. The concept behind it was great, but in practicality, it created
> >> more headaches than it was worth and most people abandoned it.
> >>
> >> Cheers,
> >> Brad
> >>
> >> -----Original Message-----
> >> From: JR Rivers [SMTP:jrrivers@xxxxxxxxx]
> >> Sent: Wednesday, November 17, 1999 9:16 PM
> >> To: rtaborek@xxxxxxxxxx; rtaborek@xxxxxxxxxxxxx; HSSG
> >> Subject: Re: Hari and train-up sequences
> >>
> >> One of the advantages to providing an "auto-negotiation" type
> >> signalling
> >> path is in signalling link faults.
> >>
> >> JR
----------------------------------------------------------
Richard Taborek Sr. 1441 Walnut Dr. Campbell, CA 95008 USA
Tel: 408-370-9233 Cell: 408-832-3957 Fax: 408-374-3645
Email: rtaborek@xxxxxxxxxxxxx