Re: Local Fault/Remote Fault
Pat,
I afraid that we're addressing different Fault scenarios. You seem to be
addressing only the case of PHY devices not blocking frames when they
see Fault messages. I was addressing the case where a Fault condition,
which is not a Fault message, is detected by a PHY device. In many such
cases, the PHY device detecting the Fault condition implicitly blocks
frames because of the existence of the fault condition. I believe that
this is what you're alluding to when you say: " They should just forward
what they receive to the extent possible."
Best Regards,
Rich
--
pat_thaler@xxxxxxxxxxx wrote:
>
> Rich,
>
> I agree that the fault messages should be mutually exclusive with frames.
> However, this is accomplished by having the RS block frames during a fault
> condition (and of course having any device detecting a fault such as loss of
> lock not send frames). The other PHY devices have no need to block frames
> based on receipt of RF or LF. They should just forward what they receive to
> the extent possible.
>
> Regards,
> Pat
>
> -----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