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

Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building



Stephen,

 

It depends on the FEC protocol adopted, implementation requirement, and the associated latency. The discussion got started around the idea of using Clause 73 AN for FEC ability exchange in the optical domain.

 

Considering we’re still in the study group phase, some of those questions cannot be answered as we have not adopted an FEC proposal. If an exchange protocol is required, then IMHO the use of sequence ordered sets would be preferred over creating of a new autoneg protocol.

 

Cheers,
Brad

 

 

From: Stephen Bates [mailto:Stephen_Bates@xxxxxxxxxxxxxx]
Sent: Friday, December 02, 2011 1:04 PM
To: STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Cc: Booth, Brad
Subject: RE: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building

 

Hi Brad

 

In this scenario is it not sufficient to simply not decode the FEC? In that case the line format does not have to change and the RX can make an informed decision on whether to utilize the FEC parity to improve performance or  ignore the parity and reduce the latency? I do not see why the FEC has to dynamically turn on and off to satisfy this scenario given the complications associated with such switching.

 

Cheers

 

Stephen Bates PhD

Technical Advisor

Corp Strategy and Tech Office, PMC-Sierra.

Cell: 403 609 1784

 

PS Brad, I do not seem to be able to email the reflector. If you get this and the reflector does not do you mind passing it on while I sort out the problem? Thanks.

 

From: Stephen Bates
Sent: Friday, December 02, 2011 11:49 AM
To: STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building

 

Hi Brad

 

In this scenario is it not sufficient to simply not decode the FEC? In that case the line format does not have to change and the RX can make an informed decision on whether to utilize the FEC parity to improve performance or  ignore the parity and reduce the latency? I do not see why the FEC has to dynamically turn on and off to satisfy this scenario given the complications associated with such switching.

 

Cheers

 

Stephen Bates PhD

Technical Advisor

Corp Strategy and Tech Office, PMC-Sierra.

Cell: 403 609 1784

 

From: Brad Booth [mailto:Brad_Booth@xxxxxxxx]
Sent: Friday, December 02, 2011 9:53 AM
To: STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building

 

Hugh,

 

Shorter answer: VMs & SDN.

 

There is a trade-off between latency and BER with FEC. With virtual machines (VMs) and software defined network (SDN), there should be the ability for that trade-off to be made without being locked into a choice that is suboptimal. And yes, synchronization/hand-shaking would be required to make it work.

 

Cheers,

Brad

 

 

From: Hugh Barrass (hbarrass) [mailto:hbarrass@xxxxxxxxx]
Sent: Friday, December 02, 2011 10:12 AM
To: Booth, Brad; STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Cc: Hugh Barrass (hbarrass)
Subject: RE: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building

 

Brad,

 

One short question: What is the application that requires the FEC to be turned on/off after the link is established?

 

The current assumption is that FEC should always be used if it is advertised as available. If there is a critical application that requires the FEC to be selectable without bringing the link down then it may have other knock-on effects - particularly if we choose a FEC that does not pass the data through unscrambled (with the parity block sent separately). Clearly, for a simple FEC (such as RS), the receiver can independently choose to use the parity block or not – allowing the receiver to save power or reduce latency if the BER is acceptable. Anything that requires a change to the transmitter will necessarily need some form of synchronization between the transmitter and receiver to ensure that the receiver doesn’t misinterpret the data stream after the change.

 

Thanks,

 

Hugh.

 

From: Brad Booth [mailto:Brad_Booth@xxxxxxxx]
Sent: Wednesday, November 30, 2011 11:38 AM
To: STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building

 

I put both groups on this just in case someone is not on both reflectors.

 

There are a few aspects to FEC and Autoneg that the TF and SG may wish to consider:

  1. Exchanging FEC abilities
  2. Agreeing upon FEC use
  3. Switching between FEC on/off
  4. Autoneg location

 

Autoneg location has been an interesting discussion in the past (P802.3ap for instance). The optical domain autoneg in Gigabit Ethernet was performed in Clause 37 which had the autoneg function as part of the PCS. The electrical domain autonegs have been performed at the bottom of the stack between the MDI and the PMD (Clause 28 and 73). Adding an optical domain autoneg to be similar to that used by the electrical domain may not be worth the effort considering there are other alternatives.

 

Also, autoneg works fine for #1 and #2, but doesn’t work well in situation #3. For example, upon link bring-up if the local device and link partner have exchanged that they are both capable of FEC but have decided not to use it, the only way for FEC to be turned on at a later point in time is to perform another autoneg. Whether in the electrical or the optical domain, restarting autoneg to switch FEC on and off is very cumbersome due to traffic interruption and link downtime.

 

A possible solution to solve #3 and #4 is the following:

  • Electrical domain autoneg (for .3bj) uses Clause 73 for #1 and #2
  • Optical domain uses PCS level sequence order sets to perform #1 and #2
  • Both electrical and optical use sequence order sets for #3

 

There are likely corner cases that would need to be considered in an implementation, but the goal should be to provide a mechanism by which a system can perform these operations in a manner to eliminate the corner cases.

 

Thoughts?

 

Cheers,

Brad

 

 

 

 

From: Oren Sela [mailto:orens@xxxxxxxxxxxx]
Sent: Wednesday, November 30, 2011 11:16 AM
To: STDS-802-3-100GCU@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_100GCU] 802.3bj Auto-negotiation consensus building

 

One more thing to consider-

This is not necessarily a 802.3bj issue but we need to think about it – there was some discussion in the next generation optics study group about FEC. If we’ll end up with optional FEC for the optical interface we will probably want to use the same CL73 AN for negotiating the FEC. It makes sense to do this once and add the 100GBASE-SR4 for example to the CL73 base page.

If we decide to take this path we need to make sure that the slow frequency of the DME pages (312.5 MHz) is physically feasible on a 25 Gb/s optical interface.

 

Thanks,

Orens

 

From: Chalupsky, David [mailto:david.chalupsky@xxxxxxxxx]
Sent: Wednesday, November 30, 2011 6:52 PM
To: STDS-802-3-100GCU@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_100GCU] 802.3bj Auto-negotiation consensus building

 

Thanks for the proposal, Arthur. 

This is a great start. There are a couple dependencies upon baselines in other areas that could affect this.

  • FEC -  if we have an optional FEC how does that affect AN?
  • Multi signaling schemes: if a PAM4 baseline is adopted in addition to NRZ we will need more fields and naming to distinguish them.  We would also need to discuss the priority.  Process-wise, should we leave it to PAM-4 supported to propose the AN solution as part of their baseline?

Thanks,

Dave


-

 

From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx]
Sent: Wednesday, November 30, 2011 8:20 AM
To: STDS-802-3-100GCU@xxxxxxxxxxxxxxxxx
Subject: [802.3_100GCU] 802.3bj Auto-negotiation consensus building

 

Folks,

   Below follows a draft baseline proposal for 802.3bj auto-negotiation. Please let me know if:

  1. You wish to be listed as a supporter
  2. You wish to be involved in consensus building discussions
  3. You have any comments on the proposal

 

Arthur Marris (arthurm at cadence dot com)

 

 

 

802.3bj Baseline Proposal for Auto-Negotiation

Assumptions:

·         Implementation of Auto-Negotiation will be mandatory for 100GBASE-KR4 and 100GBASE-CR4

·         802.3bj  EEE (Energy Efficient Ethernet) will make use of AN next pages just like 802.3az

·         802.3bj will take the same approach as 802.3ba for Auto-Negotiation

 

 

Proposed revisions to IEEE 802.3-2012:

Clause 30:

Change 30.6.1.1.5  aAutoNegLocalTechnologyAbility attribute to insert 100GBASE-KR4 and 100GBASE-CR4 after 100GBASE-CR10.

 

 

Clause 45:

Change 45.2.7.12 Backplane Ethernet, BASE-R copper status (Register 7.48) register to include 100GBASE-KR4 and 100GBASE-CR4. Insert 100GBASE-KR4 and 100GBASE-CR4 bits into Table 45–172 and 45.2.7.12.2 Negotiated Port Type.

 

Change 45.2.7.13 EEE advertisement (Register 7.60) to include 100GBASE-KR4 and 100GBASE-CR4. Insert 100GBASE-KR4 and 100GBASE-CR4 bits into  Table 45–173 and Table 45–174. Insert subclauses for the bit definitions as necessary.

 

 

Clause 73:

Change note at beginning of Clause 73 to read “Note that although the Auto-Negotiation defined in this clause was originally intended for use with Backplane Ethernet PHYs, it is also specified for use with 40GBASE-CR4, 100GBASE-CR10 and 100GBASE-CR4 PHYs.”

 

Change last sentence in third paragraph of 73.3 to read “Technology-Dependent PHYs include 1000BASE-KX, 10GBASE-KX4, 10GBASE-KR, 40GBASE-KR4, 40GBASE-CR4, 100GBASE-CR10, 100GBASE-KR4 and 100GBASE-CR4.”

 

Change Table 73-4 Technology Ability Field encoding to insert A6 for 100GBASE-KR4 and A7 for 100GBASE-CR4.

 

Change third paragraph in 73.6.4 to read “40GBASE-CR4 and 40GBASE-KR4 shall not be advertised simultaneously and likewise 100GBASE-CR4 and 100GBASE-KR4 as their physical interfaces are different.

 

Change last sentence in 73.7 Receive function requirements to read “The receive function incorporates a receive switch to control connection to the 1000BASE-KX, 10GBASE-KX4, or 10GBASE-KR, 40GBASE-KR4, 40GBASE-CR4, 100GBASE-CR10, 100GBASE-KR4 or 100GBASE-CR4 PHYs.”

 

Change 73.7.1 DME page reception to read “To be able to detect the DME bits, the receiver should have the capability to receive DME signals sent with the electrical specifications of the PHY (1000BASE-KX, 10GBASE-KX4, 10GBASE-KR, 40GBASE-KR4, 40GBASE-CR4, 100GBASE-CR10, 100GBASE-KR4 or 100GBASE-CR4). The DME transmit signal level and receive sensitivity are specified in 73.5.1.1.”

 

Change last sentence of 73.7.2 Receive Switch function to read “During Auto-Negotiation, the Receive Switch function shall connect the DME page receiver controlled by the Receive state diagram to the MDI and the Receive Switch function shall also connect the 1000BASE-KX, 10GBASE-KX4, 10GBASE-KR, 40GBASE-KR4, 40GBASE-CR4, 100GBASE-CR10, 100GBASE-KR4 and 100GBASE-CR4 PMA receivers to the MDI if the PMAs are present.”

 

Change Table 73–5—Priority Resolution to insert 100GBASE-CR4 at priority 1 and 100GBASE-KR4 at priority 2 and move the existing entries in the table down appropriately.

 

Insert appropriate variable for 100GBASE-KR4 and 100GBASE-CR4 into 73.10.1 State diagram variables

 

 

 

Clause 80:

Change the last sentence of 80.2.6 Auto-Negotiation to read “Clause 73 Auto-Negotiation is used by the 40 Gb/s and 100 Gb/s backplane PHYs (40GBASE-KR4 and 100GBASE-KR4) and the 40 Gb/s and 100 Gb/s copper PHYs (40GBASE-CR4, 100GBASE-CR10 and 100GBASE-CR4).”

 

 

Clause 82:

Change the first sentence of 82.6 Auto-Negotiation to read “The following requirements apply to a PCS used with a 40GBASE-KR4 PMD, 40GBASE-CR4 PMD, 100GBASE-CR10, 100GBASE-KR4 or 100GBASE-CR4 PMD where support for the Auto-Negotiation process defined in Clause 73 is mandatory.”