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

RE: Local Fault/Remote Fault




This was so lightly treated in the adopted presentation, that I missed
inhibiting frame transmission because of received RF as an RS function.
Shimon Muller has proposed a complete rewrite of 46.2.6 that fixes the
problem along with a number of others (e.g., how is the fault condition
cleared).  As clause editor I will recommend accepting Shimon's comment next
week (with minor edits).  

--Bob Grow

-----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