RE: Local Fault/Remote Fault
Rich,
I tend to agree that a unidirectional link is of little value to the user,
but to justify this I find I'm assuming things like running 802.1d
transparent bridging over the link. Realistically this is a system
consideration, and the decision of whether to stop transmitting in response
to a remote or even local fault indication should be made at a system level.
To me this means that the MAC Client stops sending frames to the MAC, but
there is history in Ethernet for blocking frame transmission at a lower
layer. In any case I think the blocking should be done at a single point in
the transmit path. We went to a great deal of trouble to propagate local
fault indications all the way to the RS and make the RS the only point where
remote fault indications are generated. It seems appropriate that this also
be the only place where frames are blocked when a link fault is detected.
Steve
-----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