Re: headless chicken
Rich,
Thanks for your clarification.
At 2:09 PM -0700 00.6.23, Rich Taborek wrote:
http://grouper.ieee.org/groups/802/3/10G_study/email/msg02788.html
> 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:
> http://grouper.ieee.org/groups/802/3/10G_study/email/msg02772.html
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
implementation.
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,
Osamu