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

RE: Local Fault/Remote Fault




Rich,

If a device is receiving RF, it doesn't even get a unidirectional link by
transmitting. The other side is telling it it can't hear the transmission,
so if it transmits it is going into half a unidirectional link - a
transmitter without a receiver. A unidirectional link would only be achieved
by enabling packet transmission while receiving LF. 

All our links will achieve lock even with minimum IPGs. In the case of
10GBASE-X, lock will take longer under that condition - worst case, one gets
an A or a K each minimum IPG but it is statistical which one gets so it
probably takes between 10 and 20 frames to have a high probability of having
gotten enough to get lock but it will occur. It is better to switch to idle
so lock reoccurs quickly when it is able, but we would still lock if we
didn't.

Regards, Pat

-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Tuesday, January 02, 2001 3:39 PM
To: HSSG
Subject: Re: Local Fault/Remote Fault



Eric,

This is worth a comment, because it is what we voted in as a baseline
proposal in Tampa in taborek_2_1100.pdf (see page 5 and others). I don't
believe that a unidirectional Ethernet link is of any value to the user.
Therefore, a RF condition should cause Link Status to be set to Fail in
the RF transmitting and receiving devices. In addition, how else is the
failing link direction going to get a chance to heal if it broke while
it was receiving, at best, only Idles, and at worst, Idles with minimum
IPGs. 

Happy Holidays,
Rich

--

Eric Lynskey wrote:
> 
> Rich,
> 
> This is something I've been trying to figure out for a while.  Perhaps you
> can shed some light on this.
> 
> > 3.  The RS layer is where the Local Fault Pulse Ordered Set is
> >     processed.  The RS layer is the only place that a Remote
> >     Fault Pulse Ordered Set can be generated.  If an RS receives
> >     a Local Fault Pulse Ordered Set it must stop sending packets
> >     and begin sending alternating columns of Idles and Remote
> >     Fault Pulse Ordered Sets.  If an RS receives a Remote Fault
> >     Pulse Ordered Set, it must stop sending packets and send
> >     only Idles.
> 
> I cannot find any indication that if an RS receives a Remote Fault Pulse
> Ordered Set, that it must stop sending packets and send Idles.  As far as
I
> can tell, all Clause 46 says about reception of Remote Fault messages is
> that this "indicates that the link partner DTE has detected a fault (and
> consequently will not transmit frames."  I know the end paranthesis is
> missing, but I take that to simply mean that the link partner will not
> transmit frames, but it says nothing about the local device inhibiting
> transmission of MAC frames.  Later on, it describes what happens when the
> local device receives local fault messages, but nothing about remote fault
> messages.  What exactly was your intention with this?  Should the local
> device stop transmitting frames when it receives Remote Fault status
> messages?  It seems as if this is so, and I'll submit a comment about it
if
> that is correct.
> 
> Eric Lynskey
> UNH InterOperability Lab

------------------------------------------------------- 
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@xxxxxxxxxxx
Santa Clara, CA 95054            http://www.nSerial.com