Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building
Dan,
I see where you're coming from. The other option would be to have two objectives written like #1 where one objective can only be met with some method that increases the SNR (i.e. FEC) and another objective that is shorter and does not require any extra margin.
The "at least one" in #2 is not a viable objective format as it is too open-ended.
Cheers,
Brad
-----Original Message-----
From: Daniel Dove [ddove@xxxxxxx<mailto:ddove@xxxxxxx>]
Sent: Monday, December 05, 2011 07:15 PM Central Standard Time
To: Booth, Brad; 100G Group
Subject: Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building
Hi Brad,
I think its a matter of perspective with regard to why FEC is used.
If FEC is being used to improve SNR and reduce BER (to improve performance beyond the minimum) on a given channel, then its a single PMD with an optional FEC.
If FEC is being used to increase channel capacity (ie: allow longer/worse channels), then a PMD that supports FEC may run on the longer/worse channel but the PMD that does not support it would not operate on that longer/worse channel. This means they are two different PMDs. You cannot connect them together on the longer/worse channel and expect interoperability.
You are right that in the study group phase, its early to decide things like whether or not we are going to use FEC or even auto-negotiation. In the study group, we are supposed to be deciding upon objectives.
This discussion might be simply boiled down to whether our MMF objective looks like #1 or #2 below;
1. Define a PMD that supports up to X meters of OMn Multi-Mode Fiber
2. Define at least one PMD that supports up to X meters of OMn Multi-Mode Fiber.
If its #1, then we need only define X and determine whether we can achieve X on some form of available MMF to achieve broad market potential. If FEC is required, that is fine.
If its #2, we might find that a FEC PMD and a non-FEC PMD solve different market spaces and both satisfy technical feasibility and broad market potential.
If its #2, we might indeed need to auto-negotiate, but we would also want to be sure that AN worked over the worst-case FEC required channel.
Dan
From: Brad Booth <Brad_Booth@xxxxxxxx<mailto:Brad_Booth@xxxxxxxx>>
Reply-To: <Brad_Booth@xxxxxxxx<mailto:Brad_Booth@xxxxxxxx>>
Date: Mon, 5 Dec 2011 16:00:40 -0600
To: 100G Group <STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building
Dan,
802.3ap specified a single PMD that supported operation with/without FEC; hence, I don’t quite understand your statement relative to the phase of this project.
If we were in the task force phase and evaluating PMDs to meet the objectives of the project, then I would agree that avoiding a plethora of PMDs would be beneficial.
At this point in the study group’s life, it may be preferential to limit what the task force may wish to consider.
Cheers,
Brad
From: Daniel Dove [mailto:ddove@xxxxxxx]
Sent: Monday, December 05, 2011 1:56 PM
To: STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building
Hi All,
For simplicity in specification, and to avoid a plethora of PMDs (with/without FEC are two different PMDs) I would recommend that we decide on whether or not FEC is required to reach any given distance and if so, allow the receiver to decode and not iterate if it can maintain SNR without FEC.
This way, for short reaches with good SNR, FEC may be turned off at the receiver and latency objectives meet. For longer reach where SNR may not be sufficient, the latency impact will be worth it.
Dan
From: "Hugh Barrass (hbarrass)" <hbarrass@xxxxxxxxx<mailto:hbarrass@xxxxxxxxx>>
Reply-To: "Hugh Barrass (hbarrass)" <hbarrass@xxxxxxxxx<mailto:hbarrass@xxxxxxxxx>>
Date: Fri, 2 Dec 2011 10:19:26 -0800
To: 100G Group <STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building
Chris,
You seem to be describing normal AN behavior. My question was (is):
What is the application that requires the FEC to be turned on/off after the link is established?
Please note the words used – “after the link is established.”
Hugh.
From: Chris Cole [mailto:chris.cole@xxxxxxxxxxx]
Sent: Friday, December 02, 2011 9:34 AM
To: Hugh Barrass (hbarrass); STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_100GNGOPTX] 802.3bj Auto-negotiation consensus building
Hugh,
Permit me to offer a couple of AN scenarios for discussion.
The NGOPTX standard is a few years away from being adopted. Hopefully, in the meantime we will be shipping lots of 100G ports. These ports will be deployed with .ba or proprietary 100G optics. However, once NGOPTX is adopted, if newly deployed ports that support FEC can recognize that the far end does not support FEC, that will allow any new optics we define like 100GE-SR4 to be plugged into and functional in all the legacy ports.
Another scenario is if we want to use the same physical modules to support applications at two different performance levels, one without FEC and the other with FEC. For example we may have a 30m or 50m reach 100GE-SR4 baseline PMD specification, and a 100 or 125m 100GE-SR4f (with FEC) PDM specification. AN guarantees that any PMD in any port can still establish a link over the shorter reach.
Chris
From: Hugh Barrass (hbarrass) [mailto:hbarrass@xxxxxxxxx]
Sent: Friday, December 02, 2011 8:12 AM
To: STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-100GNGOPTX@xxxxxxxxxxxxxxxxx>
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<mailto: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<mailto: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<mailto: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]<mailto:[mailto:arthurm@xxxxxxxxxxx]>
Sent: Wednesday, November 30, 2011 8:20 AM
To: STDS-802-3-100GCU@xxxxxxxxxxxxxxxxx<mailto: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.”