| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Thank you Marek! (for those who don’t know, we benefit from Marek (and Glen) having familiarity with this technique which was originally done in connection with EPON channels) Hopefully I got the description correct below regarding lane swaps – which I think clause 143 is immune to because the lane combining information is kept logical (in the envelopes with the data) rather than attached to physical wires.
For this reason, having a lane ID might be helpful because you might actually not know there was a lane swap at all on the wires… From: mxhajduczenia@xxxxxxxxx <mxhajduczenia@xxxxxxxxx>
I will be happy to answer any questions regarding Clause 143 material and I am also CCing Glen so that he is aware this discussion is taking place Marek From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
I have this action item on the laning, and rather than take you through a presentation, I’ll save presentation time by going to the reflector. I believe that last time we talked about laning to produce 50G and 100G links, we concluded that the laning should be at the RS layer, and the likely model was Clause 143 which lanes 25 G chunks into a higher rate stream.
https://grouper.ieee.org/groups/802/3/cy/public/adhoc/zimmerman_3cy_01_05_18_21.pdf While the method in clause 143 is very complex, we would use something simpler. This has the advantage that each 25 G PCS/PMA is its own phy, independent of the others.
Regardless of whether we directly follow clause 143, the laning preference was at the RS. Because we lane at the RS layer, we have one OAM per lane – just like we have one PCS (w/FEC) and one PMA per lane. Based on the straw polls in May, that seems a clear preference, and it allows us to define PCS, FEC, PMA, and the OAM roughly
independently of the laning. (see
https://www.ieee802.org/3/cy/public/may21/May2021_straw_poll_with_responses.pdf ) At the May meeting people wanted this, but also wanted to correct lane swaps. To do that, you need to know the PHY’s part in the laning – I think that clause 143 takes care of this, but I suggest having a lane ID in the OAM so that your
management system can be aware at a lower level. It isn’t clear whether people wanted a downshift specified should a lane fail, but that is possible in the RS without messing with the OAM – clause 143 can dynamically adapt. If you want to know more about this, I suggest you review either
clause 143 in the currently circulating 802.3dc revision draft, or in the published IEEE Std 802.3ca. SO I think all this means is that we have a lane-identifier in the OAM. Let the higher-layer-management and clause 143 put the rest together. If you have the space in the OAM field, you might also want to put a field in the OAM that says
whether the device thinks it is a lane of a higher-rate phy… that should be the only effect on OAM that I can think of, otherwise, all OAMs operate as though the 25G link was the only thing in existence. If you have a field for the lane identifier and the
number of lanes, you can then handle swaps, or even rate downshifts – even without clause 143, so we are safe. AND, this would be completely in line with the straw polls and my presentation from the May meeting, which (I think) is the last time we talked
about this. -george George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications To unsubscribe from the STDS-802-3-B10GAUTO list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B10GAUTO&A=1 To unsubscribe from the STDS-802-3-B10GAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B10GAUTO&A=1 |