| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
George and all,  I will be happy to help as well. Regarding you statement below that â??â?¦ the method in clause 143 is very complex â?¦â?? I find that in most cases when people say that something is too complex, they really mean â??I am not familiar with it and donâ??t know how it worksâ??. I am certainly guilty of such miss-statements myself. But in almost all cases, when I familiarize myself with such â??complexâ?? technology, suddenly it becomes quite simple and elegant. Sometimes I even start liking it J  Now, notwithstanding the above, the C143 solves a few problems that .3cy does not have. For example, it supports multiple MAC instances on top of the Multi-Channel Reconciliation Sublayer (MCRS), and each MAC can be dynamically scheduled into any combinations of lanes below MCRS. (MCRS itself doesnâ??t do any scheduling, it just takes a directive/primitive from a higher-layer entity.)  Also, as you stated, the C143 does not address lane swap. For 802.3ca, lanes are mapped to wavelengths on the same fiber, so lane swap is not possible. But fixing this is extremely simple by adding a lane id to the existing envelope headers.  I must admit I know very little about the .3cy (so it seems awfully complex to me). But here are the MCRS features that I think may be useful to .3y: -         C143 is defined in a generic way, with M MAC interfaces above and L lane interfaces (25GMII) below. Other clauses would specify what M and L numbers are. -         MCRS is tolerant of lane skew. Internal buffer is defined to remove such skew, together with any jitter added in transmission channel, including all the sublayers below MCRS (i.e., jitter added by PCS/FEC). The skew between wavelengths in EPON is proportional to fiber length. When separate conductors are used, it can be much larger. But the internal de-skewing buffer in MCRS is designed to be scaled according to the maximum expected skew. -         MCRS can automatically steer around a failed lane. Total throughput gracefully degrades from Lx25G to (L-1)x25G. -         During low demand intervals, some lanes can be shut down to save power.  I am not sure if the concept of multiple MACs sitting above MCRS is of interest to .3cy. I think such architecture may have advantages in automotive applications, where some MACs can provide low latency services, regardless of the load generated by other MAC instances. This concept is similar to .3br, but instead of just two MAC instances (express and preemptable), there can be M instances, each given a different priority.  Regards, Glen   From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>  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 |
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature