|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
I would like to address the question of whether 2.5GBASE-T needs link fault signaling.
Like 10GBASE-T, the design of 5GBASE-T and 2.5GBASE-T is based upon the XGMII and associated Reconciliation Sublayer (RS) that performs link fault signaling specified in 22.214.171.124. We should not remove this piece of the system without a thorough understanding of the consequences.
Removing the requirement of link fault signaling at the RS will have undesireable consequences on 2.5GBASE-T. One example is the recovery from a fault during EEE low power idle.
xGBASE-T EEE low power idle mode is asymmetric and may be entered by one or both PHY transmitters. During LPI, the transmitters and receivers are powered down except during short refresh transmit periods. The PHY must handle long periods without any signal at the receiver, but maintain extremely precise clock synchronization with the link partner as well as keep all of the adaptive equalizers and cancellers updated for changing conditions.
Should anything go wrong in the PHY receiver, link fault signaling provides the mechanism for recovery without dropping link and performing a multi-second link retrain.
A PHY with a receiver fault during LPI uses fault messaging to wake up the link partner transmitter and clear the fault in order to avoid a link drop. It sends local fault toward the local RS. The RS responds by sending remote fault towards the link partner RS which responds by sending idle ( instead of LPI) into the link partner PHY causing the transmitter to wake up and transmit idle symbols to the near-end PHY until the fault is cleared. Without fault signaling there is no other way to force the link partner to wake and transmit continuous signal for recovery without dropping link and retraining.
I think it is necessary to keep fault signaling as a requirement in Clause 46.
If the vast majority of people all agree that having 2.5G Ethernet (in all its various and future forms) support link fault signalling is the right thing to do then fair enough. My concern is that this has slipped in un-noticed and people are not aware of the extra requirement.
Also I am not sure that 2.5GBASE-T “needs” link fault signalling. My understanding is that it is unnecessary for 2.5GBASE-T but is required for 10GBASE-T and possibly for 5GBASE-T.
I would have preferred to simply take the 1G PCS, RS, and MAC and simply scale it to 2.5G. However 802.3bz chose to scale down 10G RS and MAC for 2.5G. I don't think it is a good idea to have RS attached to one kind of PHY not support link fault signaling while supporting it in another when both PHYs are operating the same speed.
Note that 802.3cb could simply scale down 10GBASE-R to 2.5G and avoided all this link fault signaling issue but didn't. We are aware of the scaled up 1000BASE-X solutions in the field for 2.5G and crafted something something that will allow legacy solutions to be compatible (see annex 127B) and yet align to the decisions that 802.3bz task force has made.
I do not think it is justified to ask 2.5GBASE-T to disable something that it needs simply for the sake that some legacy non-IEEE sped up version of 1000BASE-X, RS, MAC can't handle fault signaling. If there is a market demand to connect up this legacy interface to 2.5GBASE-T there are vendor specific workarounds that can be applied.