| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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] 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> 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] 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] 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] 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:
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:
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] 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] Thanks for the proposal, Arthur. This is a great start. There are a couple dependencies upon baselines in other areas that could affect this.
Thanks, Dave
From: Arthur Marris [mailto:arthurm@xxxxxxxxxxx] Folks, Below follows a draft baseline proposal for 802.3bj auto-negotiation. Please let me know if:
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.” |