Bill,
The current text is as follows
PON with the nominal bit rate of 25 Gb/s in the downstream direction and 10 Gb/s in the upstream direction (25/10G-EPON), 25 Gb/s in both the downstream and upstream directions (25/25G-EPON), 50 Gb/s in the downstream direction and 10 Gb/s in the upstream direction (50/10G-EPON), 50 Gb/s in the downstream direction and 25 Gb/s in the upstream direction (50/25G-EPON), and 50 Gb/s in both the downstream and upstream directions (50/50G-EPON), shared amongst the population of ONUs attached to the P2MP topology, and collectively referred to as Nx25G-EPON. The P2MP PHYs for the Nx25G-EPON use the Nx25GBASE-PQ PCS and PMA (see Clause 142), irrespective of the operating bit rate in the downstream and/or upstream directions (10, 25, or 50 Gb/s). Nx25G-EPONs using the nominal bit rate of 10, 25, or 50 Gb/s use a mandatory FEC function defined in Clause 142 in any direction.
and would be like this with your proposed change
PON with the nominal bit rate of 25 Gb/s in the downstream direction and 10 Gb/s in the upstream direction (25/10G-EPON), 25 Gb/s in both the downstream and upstream directions (25/25G-EPON), 50 Gb/s in the downstream direction and 10 Gb/s in the upstream direction (50/10G-EPON), 50 Gb/s in the downstream direction and 25 Gb/s in the upstream direction (50/25G-EPON), and 50 Gb/s in both the downstream and upstream directions (50/50G-EPON), shared amongst the population of ONUs attached to the P2MP topology, and collectively referred to as Nx25G-EPON. The P2MP PHYs for the Nx25G-EPON use the Nx25GBASE-PQ PCS and PMA (see Clause 142), irrespective of the operating bit rate in the downstream and/or upstream directions (10, 25, or 50 Gb/s). Nx25G-EPONs using the 802.3ca upstream bit rates of 10, 25, or 50 Gb/s, and nominal downstream bit rates of 25 & 50 Gb/s use a mandatory FEC function defined in Clause 142 in any direction.
My feedback on this would be as follows:
- I do not think we should reference project name in definition (“802.3ca”) since it is going to go away and reference will become meaningless
- We already specify all nominal data rates in the same para before, more clearly so I am not sure what the added value of repeating the same rate information is …
I believe my current text addresses all combinations in a more generic but technically correct manner, without unnecessary repetition.
Marek
From: Bill Powell <bill.powell@xxxxxxxxx>
Sent: Thursday, May 31, 2018 12:50 PM
To: Hajduczenia, Marek <Marek.Hajduczenia@xxxxxxxxxxx>
Cc: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Marek,
So back to my original comment below on Duane's item (1) from his email yesterday:
1) Pg 1/35 line 53 “Nx25G-EPONs using the nominal bit rate of 10, 25, or 25 Gb/s use a mandatory FEC function defined in Clause 142 in any direction.” Probably not for 10G and the 2nd “25” should be “50” I suspect.
and my comment from yesterday on this:
Relative to the comments on Item 1 below, wouldn't the mandatory FEC function still be defined in CL 142 for the "802.3ca" 10G rate that could share the "first" 25G US wavelength in a TDM manner that we're defining as part of this standard? i.e. - not the standard 10G EPON rate or upstream wavelength.
Taking both comments above into account, seems like pg. 1/35 of your contribution, line 53 should read something like this:
"Nx25G-EPONs using the nominal 802.3ca upstream bit rates of 10, 25, or 50 Gb/s, and nominal downstream bit rates of 25 & 50 Gb/s use a mandatory FEC function defined in Clause 142."
Regards,
Bill
-------- Forwarded Message --------
Subject: | Re: [802.3_NGEPON] Proposed set of changes to Clause 56 |
Date: | Thu, 31 May 2018 10:50:17 -0700 |
From: | Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxx> |
Reply-To: | Glen Kramer <glen.kramer@xxxxxxxxxxxx> |
To: |
Frank,
Good points about the sensitivity, since the dual-rate receiver is expected to be optimized for 25G.
On the FEC itself, it is true that RS FEC in .3av had lower overhead (12.90% vs 15.15% in .3ca). But 256b/257b line code provides 2.73% improvement over 64b/66b in .3av. Overall, .3ca comes ahead in transmission efficiency. Upstream in .3ca additionally benefits from its ability to shorten the last codeword in a burst, which offsets a portion of the optical burst overhead.
Thank you,
-Glen
From: frank effenberger [mailto:frank.effenberger@xxxxxxxxxx]
Sent: Thursday, May 31, 2018 10:27 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Just chipping in my 2 cents: I think using the same FEC has a lot going for it.
In particular, the 10G mode might need the extra help because this is going to be a dual-rate receiver.
Dual rate usually hurts the receiver sensitivity of the lower rate, sometimes by a lot.
Another factor, although not part of the .3ca project, is the hope to eventually reach PR40 specs (or at least get closer to them).
If the weaker FEC was more efficient, then one might argue for using it. But the code rates are not that different, so there is not much payoff.
So, I think what we are all converging to is to use the same PCS for 10G as with 25G.
Sincerely,
Frank E.
From: Glen Kramer [mailto:000006d1020766de-dmarc-request@xxxxxxxx]
Sent: Thursday, May 31, 2018 1:06 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Marek, I also agree with you. But I don’t think Duane proposes the reuse the existing .3av PCS. It is not compatible with the .3ca MPRS. The .3av PCS does not understand the new codes that MPRS generates (Inter-Envelope Idles, Inter-Burst Idles, RATE_ADJ_EQ, etc.) It cannot handle fragments and will invalidate the entire frame that doesn’t have normal start and terminate characters. A great many other issues would make it a very entertaining proposal, should anyone attempt to suggest reusing .3av PCS.
I think what Duane proposes is a new, third type of PCS, that can handle and understand the envelopes, but uses a different FEC engine.
Thank you,
-Glen
From: John Johnson [mailto:000007ff7d378f43-dmarc-request@xxxxxxxx]
Sent: Thursday, May 31, 2018 9:10 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Marek,
I totally agree. It was without a shadow of a doubt the intent of the TF to use the full .3ca protocol for 10G upstream. This is spelled out explicitly in harstead_3ca_3_0318 which was the source of Motion #5.
Regards,
John
On Thu, May 31, 2018 at 11:44 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx> wrote:
Duane,
This is argument that leads really nowhere - if we by any chance want to use "new" MPCP and new MPRS with "old" PCS from .3av, it will create a very large mess - .3av PCS operates on completely different principles, and has different expectations from MPCP than what we are doing right now for .3ca project. This is the most complex problem I can imagine; we tried to reuse combine "new" and "old" MPCP operation together and it was causing a lot of problems that were deemed unresolvable. Now, trying to complicate it even further, by trying to combine MPCP and PCS that do not understand each other (due to different assumptions) will certainly lead us nowhere.
Am I the only one seeing that it is a bad idea to even spend time debating it?
Marek
On Thu, May 31, 2018 at 9:28 AM Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:
John,
That motion (Motion # 5 from Rosemont meeting) only addresses the PMD (see tables in harstead_3ca_4a_0318 which makes no mention of anything in the PCS or PMA, only PMD parameters). I do not believe Motion #8 from New Orleans addressed FEC “The upstream channel format of the asymmetric 25/10G ONU shall be identical to the upstream channel format of the 25/25G ONU with the exception of line rate which shall be 10.3125 GBd.“
Mind you if we want to decide that the US 10G does use the same FEC as the 25G channels we can discuss that. My point is that we have not yet specified much of anything for 10G US but have focused on 25G channels.
If you can find any motion that clearly associate 10G and FEC please let me know.
Best Regards
Duane
From: John Johnson [mailto:000007ff7d378f43-dmarc-request@xxxxxxxx]
Sent: Thursday, May 31, 2018 10:41 AM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Duane,
I agree with Marek. The motion points to the PMD tables in Ed's contribution which specify all of the RX parameters are the same as .3av except RX sensitivity is defined at BER=1E-2 with a footnote that is intended to point to the .3ca FEC clause.
Regards,
John
On Thu, May 31, 2018 at 9:53 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx> wrote:
This is where technical decisions (and comments against the draft) will help resolve such broad motions and associated doubts. My understanding was driven by what I recall from the discussion - rand new 10G for the upstream, reusing 25G channel definition (MPCP, MPRS, PCS, etc.) with the only similarity to the existing .3av definition being the line rate.
On Thu, May 31, 2018 at 7:51 AM Duane Remein <Duane.Remein@xxxxxxxxxx> wrote:
Best Regards
Duane
From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Sent: Wednesday, May 30, 2018 7:26 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Perhaps my recollections are lacking, but my understanding was that 10G upstream gets redefined to use Nx25G-EPON PCS structure, FEC included. That was supposed to remove all the problems of "new MPCP" working with "old MPCP", which we could not find a reasonable way of doing
Marek
On Wed, May 30, 2018 at 4:30 PM Bill Powell <bill.powell@xxxxxxxxx> wrote:
Duane,
I would tend to agree, but it seems that we would need at least the equivalent optical gain from the 10G EPON RS FEC to meet the PR30 29 dB power budget. I don't recall that we've talked yet about how this would fit into an EQ-based MAC structure.Regards,
Bill
-------- Forwarded Message --------
Subject:
RE: [802.3_NGEPON] Proposed set of changes to Clause 56
Date:
Wed, 30 May 2018 21:49:30 +0000
From:
Duane Remein <Duane.Remein@xxxxxxxxxx>
To:
Bill Powell <bill.powell@xxxxxxxxx>, Marek Hajduczenia <Marek.Hajduczenia@xxxxxxxxxxx>
CC:
STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx <STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx>, Duane Remein <Duane.Remein@xxxxxxxxxx>
Bill,
Personally I don’t think the 10G US will need that much of a boost. Hopefully we can reference much of the current spec for 10G US.
Best Regards
Duane
From: Bill Powell [mailto:bill.powell@xxxxxxxxx]
Sent: Wednesday, May 30, 2018 5:40 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>; Marek Hajduczenia <Marek.Hajduczenia@xxxxxxxxxxx>
Cc: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Duane, Marek,
Relative to the comments on Item 1 below, wouldn't the mandatory FEC function still be defined in CL 142 for the "802.3ca" 10G rate that could share the "first" 25G US wavelength in a TDM manner that we're defining as part of this standard? i.e. - not the standard 10G EPON rate or upstream wavelength.Regards,
Bill
-------- Forwarded Message --------
Subject:
Re: [802.3_NGEPON] Proposed set of changes to Clause 56
Date:
Wed, 30 May 2018 14:46:18 -0600
From:
Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Reply-To:
To:
Thank you, Duane
Item 1) will be fixed and it was clearly a mistake on my end.
As far as item 2) goes, this change will affect all new clauses as well – I think it would be better to have a comment on this topic against D1.1 to make sure it gets addressed correctly.
Marek
From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Sent: Wednesday, May 30, 2018 2:40 PM
To: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>; STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Cc: Duane Remein <Duane.Remein@xxxxxxxxxx>
Subject: RE: [802.3_NGEPON] Proposed set of changes to Clause 56
Marek,
Only noticed two items of importance:
1) Pg 1/35 line 53 “Nx25G-EPONs using the nominal bit rate of 10, 25, or 25 Gb/s use a mandatory FEC function defined in Clause 142 in any direction.” Probably not for 10G and the 2nd “25” should be “50” I suspect.
2) For Fig 56-5a pg 2/36 We should add a note to these figures that 10G US will not use 25GMII but 10GMII in US. Let me know if this needs to be a separate comment.
Best Regards
Duane
From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Sent: Sunday, May 27, 2018 10:29 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: [802.3_NGEPON] Proposed set of changes to Clause 56
Dear colleagues,
Attached please find the proposed changes against Clause 56 to accommodate Nx25G-EPON in the EFM architecture. All changes to Clause 56 material (where needed) are tracked in terms of additions and deletion. Material that does not need to be modified is NOT included in this contribution.
I plan to submit a comment against draft D1.1 (once published) including this material as a contribution towards the draft. Please review and provide feedback. Your review is more than welcome.
regards
Marek
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1
To unsubscribe from the STDS-802-3-NGEPON list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGEPON&A=1