Re: Hari and train-up sequences
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