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

Re: headless chicken


Thanks for your clarification.  

At 2:09 PM -0700 00.6.23, Rich Taborek wrote:
> After reading your responses, my gut feel is that the Ethernet standard
> specifies how a MAC converses with its one associated PHY. If the MAC or PHY
> fails, the standard also specifies the reporting mechanism and specific reports
> made. When a MAC and its associated PHY is put into service, the standard
> specifies how the link is made operational. It seems that this issue focuses on
> events between the time an Ethernet link between two devices fails and the same
> or other link between the same two devices is put into service again. Please
> correct me if I am mistaken about the scenario you are addressing in this issue.
> On the outside chance that I nailed the scenario correctly, I believe that the
> issue is not an Ethernet standards issue, it is rather an implementation issue.

> Osamu ISHIDA wrote:

My initial motivation of discussing this 'stand-alone PHY' implementation 
is to consider how we would specify the transient behavior at the link 
startup, break link (dead/reboot MAC), or link failure.  I understand that 
the result of these transients is an Ethernet standards issue, and their 
intermediate states could be preserved until next link startup as an 

Here is my current link start-up scenario.  Please correct me if it will 
not work in the Ethernet standards.

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      |
The duplex PHY links would be up independently.  
During the local PHY#1 is establishing the receiver PCS Sync, it should 
continue to transmit idles with RemoteFault#1 indicator insertion.  
When the local PHY has established the receiver PCS Sync, this 
RemoteFault#1is changed to normal (Sync Up).  If the received idles 
include the RmoteFault#2 indicator, the remote device #2 is still 
trying to establish its receiver Sync and hence the duplex PHY links 
have not yet been established.  

The duplex link startup is completed when 
  (1) the local receiver PCS Sync has been established, and 
  (2) the received idles include normal indicator (no-RemoteFault indicator).

These are PHY protocols and could be work even without the 
'chicken-head' (MAC).  This is why I refer to the 'stand-alone PHY'.

However I see another potential fault that the remote MAC (Layer-2) 
is dead while the remote PHY is still alive.  In this case the 
duplex PHY links (Layer-1) could be up while the local MAC has 
no partner to talk with.  

Therefore we have proposed the BreakLink together with the Remote 
Fault in our LSS proposal.  If the local PHY does not have the valid 
MAC while his duplex link is up, it should advertise 'Break Link'.  
This might correspond to the following situations;

 (a) rebooting MAC (by setting its local PHY into Isolate states)
 (b) hot-swapping ABOVE the XAUI
 (c) In the Attachment Unit, XGXS is out of Sync while Serial 
     64/66 PCS is In-Sync.

The BreakLink helps us to isolate the remote MAC failure from the 
PHY/link failure; in this case we do not need to consult with the 
dark fiber provider. 

In summary, the MAC can start Etherframe communication when
  (1) the local receiver PCS Sync has been established, 
  (2) the received idles include no-RemoteFault indicator, and
  (3) the received idles include no-BreakLink indicator.

Or PHY might integrate all the three above condition into just a single
status register value: 'Duplex Link Up with valid MAC partner'. 

I think this is simpler and more reliable than the GbE AutoNegotiation 
process.  It would be appreciated if anyone can find the interoperability 
issues and let me know about it.

Best Regards,