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

RE: Question about Link Fault Signalling




Your proposed change is too subtitle for me while I am trying to finish my
ballot comments, but I think you erred in thinking RF is repeated, it isn't.

I don't think the existing text has a fatal embrace nor a race condition iso
can't see any reason to change it.  RF is not repeated, so once LF goes
away, only Idle is transmitted until RF is no longer received.  

BTW, RF and LF can be simultaneously detected though the RS will only see
the higher priority LF.

FYI, someone else has pointed out that I may have misread Shimon's
SuggestedRemedy that the reset to LinkStatus = OK occurs on 8 * 4 bytes of
Idle, not 2 * 4 bytes as my edited version records.)  

--Bob

-----Original Message-----
From: David Gross [mailto:dgross@nortelnetworks.com]
Sent: Wednesday, January 03, 2001 2:35 PM
To: Grow, Bob
Cc: rtaborek@earthlink.net; HSSG
Subject: Re: Question about Link Fault Signalling


Thanks for the response Bob,

I'd just like to make one clarification which I think might be
necessary. I'd like to see "In the case of a Local Fault condition..."
rather than "Upon detection of a Local Fault condition..." (and likewise
for Remote Fault). The reason for this is that since upon start-up, one
can assume that both devices will be in LF and transmitting RF. This
implies that once a device can start recieving data (i.e.: no longer
have a LF) it will be recieving RF. As a result, as the definition seems
to imply, the Fault conditions won't be cleared (The IDLE control words
won't be detected for 2 clock edges), but instead Remote Fault will be
detected. Since RF and LF cannot be detected at the same time (LF
prevents the transmission of recieved RF), it is logical that LF will be
cleared while RF will be achieved. There should be something in there
which allows for the clearing of LF in such a case, and jumping from the
LF condition immediately to the RF condition. Let me know what you
think.

-Dave Gross


Grow, Bob wrote:
> 
> Shimon submitted a comment proposing changing the entry to link down
(eitner
> RF or LF) from 3 to 4 status messages, with exit on 8 consecutive idle
> bytes.  While I am open to discussion on the numbers, I think his proposed
> text with improved description of the protocol is a great starting point
for
> discussion.  Since this has come up again, here is a slightly edited
version
> of his proposed text.
> 
> "46.2.6 Link fault signaling
> 
> "Two link fault conditions are specified for 10Gb/s operation: Local Fault
> and Remote Fault. The Local Fault condition at the Reconciliation Sublayer
> indicates that a link failure has been detected on the receive path by a
> local DTE sublayer. The source of the failure could be at the remote
> transmitter, the interconnect between the two DTEs, at one of the local
> DTE's devices or the interconnect between the local DTE's devices. The
> Remote Fault condition is generated by the Reconciliation Sublayer, and
when
> received by at a Reconciliation sublayer indicates that a link failure has
> been detected  by the remote DTE. The source of the failure could be at
the
> local transmitter, the interconnect between the two DTEs, at one of the
> remote DTE's devices or the interconnect between the remote DTE's devices.
> 
> " Fault conditions are conveyed over the XGMII using status messages. All
> status messages are four bytes in length, and are sent on a single XGMII
> clock edge. A status message is indicated by a Pulse control character
> aligned to lane 0, with the status condition encoded in the three data
bytes
> of lanes 1, 2 and 3. The status encodings are shown in Table 46-4."
> 
>                               <Table 46-4>
>          <For the sake of completeness, also show Lane 0 encoding>
> 
> "A PHY indicates Local Fault conditions to the Reconciliation sublayer by
> alternating the corresponding status message with Idle control characters
on
> RXC<3:0> and RXD<31:0>.  The Reconciliation sublayer sends the Remote
Fault
> indication to the remote DTE by alternating the Remote Fault message with
> Idle control characters on TXC<3:0> and TXD<31:0>.
> 
> "The PHY repeats a Remote Fault indication received from the remote DTE
> unless a Local Fault condition is detected resulting in the PHY over
writing
> the received data with the Local Fault indication.
> 
> "The Reconciliation sublayer continuously monitors RXC<3:0> and RXD<31:0>
> for status messages. The reception of four status messages of the same
type
> shall indicate that the corresponding fault condition has occurred. The
> reception of  four Idle control characters on successive RX_CLK edges
(eight
> consecutive Idle control characters) shall clear all fault conditions.
> 
> " Upon detection of a Local Fault condition, the Reconciliation sublayer
> shall:
>  1) Set the link_fail status indication.
>  2) Inhibit the transmission of MAC frames.
>  3) Continuously send alternating Remote Fault messages and Idle control
> characters.
> 
>  "Upon detection of a Remote Fault condition, the Reconciliation sublayer
> shall:
>  1) Set the link_fail status indication.
>  2) Inhibit the transmission of MAC frames.
>  3) Continuously send Idle characters.
> 
> "After detecting that the Fault condition has cleared (both Local and
> Remote), the Reconciliation sublayer shall:
>  1) Clear the link_fail status indication.
>  2) Enable the transmission of MAC frames."
> 
> --Bob Grow
> 
> -----Original Message-----
> From: David Gross [mailto:dgross@nortelnetworks.com]
> Sent: Wednesday, January 03, 2001 8:48 AM
> To: rtaborek@earthlink.net
> Cc: HSSG
> Subject: Re: Question about Link Fault Signalling
> 
> Hi Rich,
> 
> I have a quick question about Remote Fault I was hoping you could
> answer. In 46.2.6, it says:"Reception of multiple local fault messages
> causes the Reconcilliation Sublayer to inhibit the transmission of
> frames by MAC, and to encode remote fault status messages on TXC<3:0>
> and TXD<31:0>" It goes on to specify that reception of three LF messages
> sets link_fail to 1, and none n 6 clock periods clears link_fail.
> 
> My question is this: I believe we said that upon recieving RF, the RS
> will output an IDLE stream until it no longer recieves RF. If this is
> so, how many RF messages set this condition to be true, and in how many
> clocks do we say that this condition is cleared if no RFs are detected.
> Is it similar to LF, or do we only require that one RF be detected (and
> then for how long before we reset this IDLE output condition of the RS
> Tx?)
> 
> Thanks in advance.
> 
> -Dave Gross