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

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