| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hello Frank,
> I just got to say, Whoa! Who knew that topic of PCS turns you on so much. Whoa, indeed!! J
> From what I remember, your project is supposed to be defining a system based on 10GE-PON. I think the Super-PON Study Group was careful enough to not make a premature decision on which PCS to use. I don’t see any constraints on the choice of PCS either in the PAR or the objectives.
> Why in the world would you not use the PCS from that speed? Keep in mind that practical implementations will use silicon that is already in the market, and that speaks the 10GE-PON protocol. If you adopt the 25G PCS, that will require people to redevelop a 10G EPON chip that speaks 25G PCS. There are no EPON implementations with 2.5 Gb/s upstream. It has to be a new silicon development with either PCS. Even the MPCPDU frame format has to change.
> I appreciate that the 25GE-PON protocol looks so sleek, because it basically does away with the pretenses of looking like Ethernet. 25G-EPON looks so sleek because it relied on improved and efficient features that define modern Ethernet. There is nothing in 802.3ca spec that does not already have a precedent in earlier 802.3 amendments. 802.3ca just took the best from many existing clauses and put at all together for 25G- and 50G-EPON.
> But consider this: all of the new functionality of the 25GE-PON protocol was driven by the multi-lane nature of that system, where packets are striped across several PONs and need careful reassembly. But, in SuperPON you just don’t have any of that. So you don’t need the fancy system. The multilane architecture of 50G-EPON was not the only or the main driver for the 802.3ca transmission protocol. Efficiency of burst-mode transmission, support for increased number of users, and a stronger FEC to relax the optical requirements were the main drivers. The 25/25G-EPON and 25/10G-EPON architectures do not use multi-lane transport, but still benefit from the above enhancements.
There are many reasons to use 802.3ca PCS. Despite the extra 2 dB of gain that LDPC provides over the RS FEC, the transmission channel in 25G-EPON overall is slightly more efficient than 10G-EPON (84.452% vs. 84.446%), so there is no reason to not use it, even if the 2.5G upstream does not require the extra gain. Considering the reorganization of logical links into control links, management links, and user links, the scheduling and control message overhead has also reduced significantly. So, for Super-PON to go back to 802.3av-based transmission format and protocol would be undoing all the Ethernet advances and lessons learned from the field for the past 10 years.
> So, I would humbly suggest that you focus on using the 10GE-PON PCS. Keep it simple, that is always the best advice. That may be a good advice, but let’s not confuse simple with familiar. 10G-EPON is more familiar, but no more simple than the 802.3ca. I have observed multiple times by now how as a new developer becomes familiar with the 802.3ca spec and sees the logic behind various technical decisions, the spec becomes as simple as the earlier version.
Also, given the Super-PON project approval in ITU-T SG15/Q2 last month, I question how the IEEE Super-PON would be any different from ITU-T Super-PON. The ITU-T Super-PON will be based on NG-PON2 or XGS-PON, which would have exactly the same performance characteristics as a Super-PON based on 10G-EPON. But is it not the same or “converged” spec – PON transmission format would be very different, management would be very different, everything except PMD would be very different. I’d say we should define IEEE Super-PON based on 802.3ca PCS. We can call it Superior-PON J
Best Regards, Glen
From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Well, it is simple IMHO – do not define two PCSes. Pick the higher performing one and move on with it. By the time you’re going into WG ballot, .3ca PCS should be well vetted and through the balloting process.
I understand you’re trying to hedge bets here, but it will backfire in actual deployments.
Marek
From: Claudio DeSanti <00000b528d17fa95-dmarc-request@xxxxxxxx>
Marek,
yes, that is exactly the problem we are facing.. Can we define a solution? Thank you!
Claudio.
On Thu, Aug 22, 2019 at 5:37 PM <mxhaj79@xxxxxxxxx> wrote:
To unsubscribe from the STDS-802-3-SUPER-PON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SUPER-PON&A=1 To unsubscribe from the STDS-802-3-SUPER-PON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SUPER-PON&A=1 To unsubscribe from the STDS-802-3-SUPER-PON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SUPER-PON&A=1 To unsubscribe from the STDS-802-3-SUPER-PON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SUPER-PON&A=1 |