Re: headless chicken
Osamu,
It may be that we're entering a crossroads in 802.3 with respect to more complex
cabling plants which contain repeaters, patch panels, media converters, pure
optical switches, etc. However, my suspicion is that architecting MAC operation
separate from PHY operation is an implementation ONLY issue. Most Ethernet
devices I'm aware of power their PHY's in concert with the MAC. You mention
"stand-alone PHY" below in your note. However, this PHY is attached to a MAC as
well as the rest of the stack. All layers operate in unison. In the case that
one layer breaks, management, if present, can disable the link.
I agree with the simple LSS based Remote Fault and Break Link mechanism
described in your original note. This protocol is far simpler and more robust
that its Auto Negotiation based counterparts. This is primarily due to the
absence of full-duplex handshakes in the LSS mechanisms.
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.
In summary, any hot swapping, PHY isolate, MAC re-booting, swapping XAUI
interfaces, etc. issues are implementation dependent and outside the scope of
the P802.3ae standard.
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
> 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
--
Best Regards,
Rich
-------------------------------------------------------
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