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

Re: headless chicken


Oops... I sent a copy of this before I finished it. Here's the finished version.

I agree with most of your suggestions. Please allow me to re-iterate them to
insure our level of understanding:

1) Link Status is already defined in clause 22 (table 22-8) as Status register
bit 1.2. Its definition is:
   1 = link is up
   0 = link is down
   Read only; Latching high

I believe that this definition goes way back in Ethernet history. For
compatibility reasons, I assume that your condition: "Duplex Link Up with valid
MAC partner" is equivalent to "link is up". In general, this bit reflects PHY
and not MAC state. I'd like to propose that we leave this bit defined as is and
not add any related bits or sub states. I'd be very happy to listen to proposals
to augment this bit and state. However, starting out as simple and compatible as
possible seems to be appropriate.

2) Remote Fault is already defined in clause 22 (table 22-8) as Status register
bit 1.4. Its definition is:
   1 = remote fault condition detected
   0 = no remote fault condition detected
   Read only; Latching high

Your note proposes that Remote Fault indicates "Local Sync Up/Down". However, I
believe that the Remote Fault Status bit reflects the status of the remote end
of the link, specifically a fault with the remote receiver. In your words, the
Status bit corresponds more appropriately to "Remote Sync Up/Down". I would
propose that we leave the current Remote Fault Status bit definition exactly as

Your note also proposes an a management register bit advertising Remote Fault
for signaling by LSS. I agree with this. I propose that Register 4,
Advertisement, bit 13 be defined as Remote Fault as already defined in clause 28
(table 28-2). 

3) Break Link is a bit more interesting as I don't see a Control register bit
already defined that maps exactly to this function. The ones that come close

   0.15 Reset
   0.12 Auto-Negotiation Enable
   0.10 Isolate
   0.5:0 Reserved

I'd have to agree with you that the best choice seems to be to additionally
define 0.10 as Break Link for 10GBASE-X.
Your note also proposes an a management register bit advertising Break Link for
signaling by LSS. I agree with this. I propose that a Register 4, Advertisement
bit 13 be additionally defined as Break Link.

4) I agree that both RF and BL can be signaled simultaneously. My point about
priority is that a recipient of an LSS message indication both RF and BL should
Break the Link rather than report Remote Fault and remain in operation. Perhaps
this is too obvious and need not be stated.

This is looking very solid, compatible and simple!

Best Regards,

Osamu ISHIDA wrote:
> Rich,
> Thanks for your clear definition of Break Link and Remote Fault.
> My point has been that we had better specify the two management
> register bits advertised by Link Signaling; RemoteFault of the
> STATUS register bit (Local Sync Up/Down), and BreakLink of the
> CONTROL register bit (Local Isolate or something else).  I believe
> that this two-bit advertising allows us flexible PHY implementation
> yet preserving the strict Ethernet inter-operability.
> Also it would be a good idea to define the Link Status bit in the
> status register to indicate 'Duplex Link Up with valid MAC partner'.
> I think this status bit shall be implemented with a latching
> function, such that the occurrence of a NotOK condition will
> be remained until it is read via the management interface.
> I agree with your definition below except the BL priority.
> The LSS Link Status Code reported once ever 125 usec will carry 3-bit
> information even with minimum 4-bit Hamming protection, and hence
> RemoteFault and BreakLink can be advertised simultaneously.
> I don't see any requirement to give priority to BreakLink over
> RemoteFault.  Either or both of them causes Link Status NotOK.
> Best Regards,
> Osamu
> At 18:54 00/06/27 -0700, Rich Taborek wrote:
> > However, I urge you to keep the LSS protocol simple and not include any
> > implementation specific features. My view of Remote Fault (RF) and Break Link
> > (BL) protocol is as follows:
> >
> > Remote Fault:
> > - LSS signals RF whenever the link, including all lanes, is not synchronized;
> > - LSS RF signaling occurs once every 125 usec +/- 14 usec;
> > - Received RF is indicated in a management register (TBD).
> >
> > Break Link:
> > - LSS signals BL upon management initiative;
> > - BL has priority over RF;
> > - LSS BL signaling occurs once every 125 usec +/- 14 usec;
> > - Received BL is indicated in a management registers (TBD).
> >
> > Link Status:
> > - Set to OK when the link, including all lanes, is synchronized; and,
> > - RF or BL is not being received;
> > - Set to FAIL otherwise.
> > Osamu ISHIDA wrote:
> >
> > >
> > > Local Device #1                           Remote Device #2
> > >
> > >    MAC                                               MAC
> > >     |   STA #1                         STA #2         |
> > >    PHY  Register                       Register      PHY
> > >     |    Local State                    #1 State      |
> > >     |     Sync Up/Down --(RemoteFault#1)---->         |
> > >     |     Isolate      ---(BreakLink#1)----->         |
> > >     |    Remote State                   #2 State      |
> > >     |             <----(RemoteFault#2)-- Sync Up/Down |
> > >     |             <-----(BreakLink#2)--- Isolate      |
> > >     |_________________________________________________|
> -----------------------------------------
> Osamu ISHIDA
> NTT Network Innovation Laboratories
> TEL +81-468-59-3263  FAX +81-468-55-1282
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