RE: Local Fault/Remote Fault
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