802.3bj FEC Overview and Status IEEE P802.3bm

Transcription

1 802.3bj FEC Overview and Status IEEE P802.3bm September 2012 Geneva John D Ambrosia Dell Mark Gustlin Xilinx Pete Anslow Ciena

2 Agenda Status of P802.3bj FEC Review of the RS-FEC architecture How the FEC could be applied to 802.3bm PMDs Issues to think about 2

3 Status of 802.3bj FEC Comment resolution on draft 1.1 at this meeting Major open issues for Clause 91 RS-FEC sublayer: Signal_OK behavior FEC behavior with EEE FEC Codeword examples to be added Management needs to be added Delay constraints are TBD In general the clause is pretty complete, but of course is subject to change since we are in task force review with the complete document in scope 3

4 RS-FEC Architecture The figures below show possible implementations of the FEC architecture MAC/RS MAC/RS MAC/RS MAC/RS 100GBASE-R PCS 100GBASE-R PCS 100GBASE-R PCS 100GBASE-R PCS RS-FEC PMA (20:10) PMA (20:10) PMA (20:4) PMA (4:4) CAUI CAUI CAUI-4 PMD PMA (10:20) PMA (10:20) PMA (4:20) AN 1 RS-FEC RS-FEC RS-FEC MDI Medium PMA (4:4) PMA (4:4) PMA (4:4) PMD CAUI-4 CAUI-4 AN 1 PMA (4:4) PMA (4:4) MDI Medium PMD PMD AN 1 AN 1 MDI Medium MDI Medium Note 1: Conditional on PHY type CAUI-4 assumed new 25G+ interface 4

5 Draft 1.1 FEC Operation Backplane/Copper cable NRZ PHY (Clause 92 and 93): 256B/257B transcoding, so no increase in line rate for FEC operation FEC is required to always be sent Solves MTTFPA concerns when sending un-encoded 64B/66B data with 5 lane bit interleaving on a 25G lane No Auto Negotiation needed Adopted FEC code is RS(528, 514, T=7, M=10) ~4.9 db of gain at output BER assuming burst errors due to DFE ~5.3 db of gain at output BER assuming random errors Backplane PAM4: Same 256B/257B transcoding as NRZ FEC is required to always be sent and operates at 13.6 GBd Adopted FEC code is RS(544, 514,T=15, M=10) ~5.4 db of gain at output BER assuming burst errors due to DFE ~6.5 db of gain at output BER assuming random errors Gain figures assume that the only penalty for increase in rate is increased noise B/W Includes pre-coding to reduce the effect of burst errors 5

6 Draft 1.1 FEC Operation Cont Draft 1.0 allowed you to send 64B/66B encoded data if FEC is not needed (loss < 30dB) for the NRZ PHY (backplane and copper cable) This reduces the latency for those channels/applications that don t need FEC In cideciyan_01_0512 it was shown that sending 64B/66B data at a BER has an MTTFPA of ~10 4 years, falling to less than a year at a 10-7 BER Mainly due to the high probability of an error burst that extends to 4 bits due to the DFE, and how that error burst is spread in the packet due to the PCS lane bit multiplexing Given the MTTFPA issues with sending bit multiplexed 64B/66B encoded data even on a low loss backplane or copper cable channel, the task force decide to require that FEC encoded data is always sent by the transmitter Other options explored were: block multiplexing, a new 4 lane PCS, pre-coding The receiver has the option to: always correct (~100ns of added latency) only detect errors for low loss channels (~ 50ns of added latency) or do some proprietary trailing error detection if absolute lowest latency is needed (as low as 5ns of added latency depending how this is done) 6

7 Reed Solomon FEC Architecture Processing flow is the same for NRZ and PAM4 PMDs in the FEC sublayer 7

8 NRZ FEC frame structure first 256B/257B block starts here FEC payload FEC parity to PMA lane 0 40 bits tddddddddd dddddddddd dddddddddd to PMA lane 1 to PMA lane 2 dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddtdd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd dddddddddd pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp pppppppppp to PMA lane 3 second 256B/257B block starts here 40 bits 256B/257B block 0 256B/257B block 1 256B/257B block 2 256B/257B block 3 256B/257B block 4 256B/257B block 5 Parity Legend: t = 256B/257B header bit d = 256B/257B data bit p = FEC parity bit 256B/257B block 19 parity 8

9 Low Latency FEC Architecture The figure below shows an incorrect architecture, once the Low Latency FEC is inserted, the number of lanes cannot change! At least not with the standard 802.3ba PMAs Architectural restrictions being evaluated, exploring the possibility of supporting 4, 2 and 1 lane options. But we need to look at burst error behavior. MAC/RS 100GBASE-R PCS PMA (20:10) CAUI PMA (10:20) RS FEC PMA (4:10) PMD CAUI PMA (10:4) MDI Medium 9

10 How applicable is the RS-FEC to Optics? Some presentations have shown significant increase in distance assuming the RS-FEC for SR4 optics The RS-FEC sublayer could be leveraged as is for optics Issues to solve: When to enable FEC, for instance is it always on for a 100m SR4 PMD? It is unclear if SR4 optics will have the same MTTFPA issues with sending 64B/66B encoded data as we had with copper interfaces (what are the correlated error properties?) Tradeoffs between latency (~100ns) and operational simplicity? How does the 20m PMD fit into this discussion? Impact on form factor and power? Or is there some mechanism (AN?) to turn it on only when it is needed (fiber is long enough to require FEC)? Current linecard designs won t support it, so they can t benefit from the increase in reach Common form factors between copper and optical imply that if FEC is used we should choose the same FEC as defined in 802.3bj 10

11 Summary The low latency RS FEC defined in P802.3bj can be re-used for 4- lane PMDs We would need to answer some of the questions surrounding when to enable FEC for optics 11

12 Thanks! 12