RE: Local Fault/Remote Fault
Hi Rich,
This response is a bit late, but I don't think we are in as much
disagreement as it first appeared.
I also mis-spelled/spoke in the last sentence that you felt was
contradictory. By "link fault detected" I was thinking of detection of a LF
message from an upstream device, not of a true fault local to the detecting
device. I agree with you that when a frame arrives at a faulty device, that
device should transmit LF messages instead of the frame (it is unlikely it
would be possible for it to forward the frame anyway). If a properly
functioning device receives LF messages, however, it should simply forward
those messages along with whatever else it receives rather than go into a
special state where it generates LF messages. (Exception being the 8b/10b
transmitter that randomizes ||P|| columns with ||I|| when receiving fault
messages in the idle pattern across the XGMII.) Likewise a properly
functioning device should simply forward RF messages, along with whatever
else it receives.
I know Shimon was adamant that frames be mutually exclusive with fault
messages. With LF messages this should happen naturally because whichever
faulty device first generates LF messages, it will do so instead of
forwarding frames. With RF messages this happens because they are only
generated at the RS, and the RS can be specified to inhibit frame
transmission interspersed with RF messages. Thus we get the behavior Shimon
wanted by controlling it only where the messages are generated. It does not
need to be enforced, nor should it be enforced, by devices that simply
repeat the messages.
Steve
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Wednesday, January 03, 2001 6:03 PM
To: HSSG
Subject: Re: Local Fault/Remote Fault
Steve,
Reset...
OK
I mis-spelled/spoke when I said: "a RF condition should cause Link
Status to be set to Fail in the RF transmitting and receiving devices."
The second RF should have been an RS.
I agree that the RS is the only point or origin of RF messages.
However, with respect to LF, if a frame enters a device (a.k.a. link
element) which has a fault, and that fault is detected, that device will
block frames and instead forward LF messages. This rationale, seems to
conflict with your last sentence. Shimon Mueller was very adamant that
Fault messages be mutually exclusive with frames.
Happy Holidays,
Rich
--
Steve Haddock wrote:
>
> 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