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

Re: [802.3_NGBASET] Link fault signaling for 2.5GBASE-T



Brett,

   As you are aware there has been much off-line discussion of this and we have been encouraged to post our thoughts to the email reflector for the benefit of others.

 

   I have made a comment against draft 3.1 to request making implementation of the link fault signalling state diagram optional for 2.5G and 5G data-rates. The actual change is in 46.3.4 as follows:

"The RS shall implement the link fault signaling state diagram (see Figure 46-11) for data rates of 10 Gb/s and above. For 2.5 Gb/s and 5 Gb/s data rates implementation of the link fault signaling state diagram is optional." I would be satisfied if it is only made optional for 2.5G rates.

 

  The benefit of making the link fault state machine optional is that it allows legacy 2.5G implementations to more easily inter-operate with 2.5GBASE-T PHYs.

 

  I have heard the following objections to making link fault signalling optional. I will list them below with my comments:

1.      Your email where you say 2.5GBASE-T needs it to recover more quickly if there are problems during LPI

a.      This a fair point although I would point out that if the state machine starts sending remote fault, data will be lost and the host system will be seeing a fault condition being reported from the link fault state machine

2.      It will be difficult to configure

a.      Configuration can be done through MDIO

3.      You will fail compliance testing if you use speeded up SGMII

a.      Seeing as the only interface specified is XGMII, you cannot fail compliance testing if XGMII is not exposed

4.      802.3cb allows you to use SGMII if you use a shim layer in the PHY

a.      Using a shim layer in the PHY is something I agree with. The problem is that this is 802.3bz and not 802.3cb and that the slides I have seen so far from 802.3cb address the issue of link fault signalling rather than the requirement of the state machine to respond to local and remote fault.

 

   If the state machine is made optional I accept you would still need a shim layer in the PHY to do the byte to four-byte alignment in the transmit path if a speeded up SGMII is used for the MAC/PHY interconnect. If it is made mandatory you also need to implement the link fault state machine in the shim layer.

 

Arthur

 

From: Brett McClellan [mailto:bmc@xxxxxxxxxxx]
Sent: 24 June 2016 07:38
To: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGBASET] Link fault signaling for 2.5GBASE-T

 

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 46.3.4.3. 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.

 

Regards,

Brett

 

From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
Sent: Tuesday, June 21, 2016 7:22 AM
To: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGBASET] IEEE 802.3bz 2.5/5GBASE-T TF Arch AdHoc conf call - reminder for Monday, June 20, 2016 9:00 AM-10:00 AM PDT.

 

William,

   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.

 

Arthur

 

From: William Lo [mailto:williaml@xxxxxxxxxxx]
Sent: 21 June 2016 15:06
To: Arthur Marris
Cc: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGBASET] IEEE 802.3bz 2.5/5GBASE-T TF Arch AdHoc conf call - reminder for Monday, June 20, 2016 9:00 AM-10:00 AM PDT.

 

Hi Arthur,

 

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.

 

Thanks,

William


On Jun 21, 2016, at 04:35, Arthur Marris <arthurm@xxxxxxxxxxx> wrote:

William,

   I think 802.3cb should not have modified the 1000BASE-X PCS. There are existing 2.5G implementations using the 1000BASE-X PCS speeded up and I think 802.3cb should just have re-used 1000BASE-X and not invented something new.

 

   Existing 1G implementations have two problems with the requirement to implement link fault signaling:

1.     Encoding sequence ordered sets

2.     Implementing the link fault state machine which generates remote fault on reception of local fault

 

    Because there is no requirement to signal link interruption the link fault state machine is un-necessary for 2.5G data-rates and just adds extra complexity and causes potential inter-operability problems with existing 2.5G implementations.

 

Arthur

 

From: William Lo [mailto:williaml@xxxxxxxxxxx]
Sent: 20 June 2016 17:41
To: Arthur Marris; STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_NGBASET] IEEE 802.3bz 2.5/5GBASE-T TF Arch AdHoc conf call - reminder for Monday, June 20, 2016 9:00 AM-10:00 AM PDT.

 

Hi Arthur,

 

For 2.5GBASE-X link fault signaling will be there. It lets 802.3cb align with 802.3bz.

Task force decided to keep it in for 802.3cb.

http://www.ieee802.org/3/cb/public/may16/Lo_3cb_01a_0516.pdf

 

Also 802.3cb is designed to be compatible with 1000BASE-X PCS running 2.5x faster.

This is true even if a 2.5GBASE-X PCS sends out link fault signaling.  The 2.5GBASE-X PCS

link fault signaling is designed to look like idles to the 1000ABSE-X PCS.

See Annex 127B in the 802.3cb for further description.

 

For 5GBASE-R the link fault signaling is already baked in since it adopts the 10GBASE- R PCS.

 

Thanks,

William

 

 

From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
Sent: Monday, June 20, 2016 3:54 AM
To: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGBASET] IEEE 802.3bz 2.5/5GBASE-T TF Arch AdHoc conf call - reminder for Monday, June 20, 2016 9:00 AM-10:00 AM PDT.

 

I have prepared the attached presentation for today’s ad hoc call.

 

I have also submitted a comment against draft 3.1 to request making link fault signalling optional for 2.5G and 5G data rates.

 

From: Peter Jones (petejone) [mailto:petejone@xxxxxxxxx]
Sent: 20 June 2016 05:05
To: STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGBASET] IEEE 802.3bz 2.5/5GBASE-T TF Arch AdHoc conf call - reminder for Monday, June 20, 2016 9:00 AM-10:00 AM PDT.

 

Folks,

 

Reminder for tomorrow.

 

I’m expecting a discussion of an unresolved negative vote from May in Whistler. The comment is i-56 (see below from http://grouper.ieee.org/groups/802/3/bz/comments/8023bz_D30_approved.pdf).

 

Regards

Peter

 

<image001.jpg>

 

_________________________________________________

Peter Jones 

802.3bz 2.5/5GBASE-T Task Force Arch Ad Hoc Chair           

_________________________________________________

 

 

-----Original Appointment-----
From: Peter Jones (petejone)
Sent: Sunday, June 12, 2016 10:17 PM
To: Peter Jones (petejone); STDS-802-3-NGBASET@xxxxxxxxxxxxxxxxx
Cc: Brillhart, Theodore; Liuyun (Daniel); Arthur Marris; sebastien2.vitrant@xxxxxxxxxxxxxxxxxxxxxx; Sambasivan, Sam; derek.cassidy@xxxxxx; Khan, Muhammad; Clark Carty (ccarty); Pachon, Arturo; Goh, Chee Kiang; Andrew Jimenez; Kamal Dalmia; Jon_Lewis@xxxxxxxx; Paul VANDERLAAN; Amrik Bains (ambains); Victor Renteria; Brian Holden; Elizabeth Kochuparambil (edonnay); Moffitt, Bryan; anna.an@xxxxxxxxxxxxxxx; George Zimmerman; Goel, Pankaj; Herman, Todd; kumaran.krishnasamy@xxxxxxxxxxxx; Matt SCHUMACHER
Subject: IEEE 802.3bz 2.5/5GBASE-T TF Arch AdHoc conf call
When: Monday, June 20, 2016 9:00 AM-10:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: Webex

 

 

Hi Folks,

 

This meeting is back by request. We have some Sponsor Ballot comments to look into before the interim on June 27th. The timeslot has been moved to accommodate some key people.

 

Agenda information will be provided prior to each meeting.

 

Please familiarize yourself with the meeting guidelines and patent policy before the meeting.

 

 



-- Do not delete or change any of the following text. --

 
Host key: 399004



Join WebEx meeting
Meeting number: 205 797 364 
Meeting password: 8023bz (802329 -- On Phone) 


Join by phone 
+1-408-525-6800 Call-in toll number (US/Canada) 
+1-866-432-9903 Call-in toll-free number (US/Canada) 
Access code: 205 797 364 
Global call-in numbers  |  Toll-free calling restrictions  
 
 
Can't join the meeting?
Contact support.

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. You should inform all meeting attendees prior to recording if you intend to record the meeting.