Duane, et al., Attached is the revised deck which I hope addresses some of your concerns. You will notice the maximum values were removed from repeat count fields for individual sync patterns and they will not be present in Frame file either. If there are additional restrictions we need to place on the values, my recommendation would be to add these in PCS clause, where we define pattern values, and describe how individual sync pattern zones work. These restrictions should be transparent to MPCP clause definitions, since MPCP does not care what the actual value is carried in the message, as long as it fits into the prepared field in it. Further comments are welcome. Given the changes in the deck, I would like to go over the deck again on the next call and emphasize changes done Regards Marek From: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxx>
Sent: Thursday, April 19, 2018 1:43 PM
To: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes Duane, In 10G-EPON, just like in 25G, laser_on time and burst preamble (AGC and CDR) were all variable quantities. We have only maximum limits specified for Ton, Treceiver_settling, and Tcdr. The actual values were implementation dependent and they were announced to the ONU. The delay line in 10G-EPON ONU Data Detector was not fixed to any value. The ONU needed to set it based on SyncTime parameter it received first in the DISCOVERY GATE, then again (and possibly a different value) in the REGISTER message. Marek's proposal follows the same idea, only instead of a single SyncTime parameter, we now split it in 3 values to allow different patterns.
So, as I said earlier, if .3ca sets maximum permissible values for Ton, Tsettling, and Tcdr, that will implicitly set the maximum limit for the DD delay line (again, as it was done in 10G-EPON). Glen (Sent from Samsung Galaxy far, far away, where typos are normal) Glen, Perhaps you missed my first comment. I copy it here for your convenience (empheis added). In 10G-EPON we incorporated the Data Detector mechanism to determine when the beginning of the burst should occur. The mechanism depended on a delay line that essentially matched the duration of burst preamble, burst delimiter and laser on time (i.e., sync time). In 10G-EPON this was a fixed duration. We have now made that duration variable and of arbitrary size through the setting of SP1, SP2 and SP3 and any repeats. What will the ONU be expected to accommodate with respect to maximum delay needed? Without placing a bound on this total time I don’t see how we can claim technical feasibility. If some OLT vendor decides a very long sync time is OK per the standard and an ONU cannot accommodate that long time interoperability is not achieved, neither device is non-compliant and we have not achieved our goals. Duane, First, a suggestion to reduce the field size. Then limiting the total of SP1, SP2, and SP3. It is clear you are trying to solve some problem, but it is not clear what that problem is. Can you explain it first? For the SP1, SP2, and SP3 lengths, we must have individual limits. The limit on the total size will naturally follow from that. I suggest we limit the aggregate of SP1 + SP2 + SP3 to 2.5 us. This is over twice what Glen suggested (and what was considered easy to accomplish in 2002 where the default was ~850 ns). All the points Glen is bringing up are very valid. Just to add, should any value range restriction be needed, we can set the range in the field definition on the draft, and be done with it. However with pad still available, there is very little reason to skimp on field size. Marek Because There is plenty of padding left in a message. If we don’t use it for any fields, we just send zeroes anyway. All fields are even, so the frame can be parsed on word boundary instead of byte boundary. Vendors/developers can use the values exceeding the spec limit for system bring-up/debugging (assuming both ends of the link can handle this). What would be the reasons to reduce these fields to 1 byte? Glen, I would be happy with these values, at least for starters. But then my question become why do you need 16 bits to express a number that can be easily expressed in 7 bits? I am not sure what the issue is. The bound comes from the definitions of Ton, Treceiver_settling, and Tcdr. I am sure we will have a separate discussion on that. The bound does not come from the MPCPDU field size. In 10G-EPON, SyncTime field was 2 bytes, but the maximum allowed value was 76 TQ (800 ns Treceiver_settling, 400 ns Tcdr, and 16 ns Burst Delimiter). The only thing that needs to change in Marek’s presentation is that it should not say that the entire range from 0 to 2^16 is allowed. It does say it now. Marek, The point is not that the OLT has to use both bytes, the point is it legally can and the ONU is duty bound to accommodate that. Without some upper bound that can come to over 2 seconds of delay. Clearly this is excessive. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx]
Sent: Wednesday, April 18, 2018 1:53 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>
Cc: STDS-802-3-NGEPON@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGEPON] 4/12/18 802.3ca (100G-EPON) consensus building meeting notes Duane, What would be then "reasonable"? It is not like OLT has to use all 2 octets provided for specific values. On Wed, Apr 18, 2018 at 11:51 AM, Duane Remein <Duane.Remein@xxxxxxxxxx> wrote: Marek, I previously commented on the 2 byte repeat parameter in the SP messages and, at the time, it was suggested that this really didn’t matter. However, I have to disagree with that opinion. In 10G-EPON we incorporated the Data Detector mechanism to determine when the beginning of the burst should occur. The mechanism depended on a delay line that essentially matched the duration of burst preamble, burst delimiter and laser on time (i.e., sync time). In 10G-EPON this was a fixed duration. We have now made that duration variable and of arbitrary size through the setting of SP1, SP2 and SP3 and any repeats. What will the ONU be expected to accommodate with respect to maximum delay needed? Without placing a bound on this total time I don’t see how we can claim technical feasibility. If some OLT vendor decides a very long sync time is OK per the standard and an ONU cannot accommodate that long time interoperability is not achieved, neither device is non-compliant and we have not achieved our goals. I suggest we place a reasonable limit on the total sync time in the standard and size the repeat parameters accordingly. Dear colleagues, Attached please find the updated version of the general presentation and detailed changes to MPCP Clause, modified following the feedback on the call today. All and any comments on the content are welcome Marek All, Please let me know if I need to revise or add to the following notes: 4/12/2018 IEEE 802.3ca 100G-EPON Task Force Work Items and Socialization ad hoc conference call · Review of Patent Policy. o Curtis Knittle read the Call for Potentially Essential Patents – no response to call. · MPCP Changes (M. Hajduczenia) · Deadlines: o Contribution deadline for requesting time on the agenda and draft PDF files: Monday, May 14, 2018 AoE § See http://www.ieee802.org/3/ca/3ca_presentproc.shtml for details on submissions o Draft 1.0 Comment deadline is May 7. For details, please see http://www.ieee802.org/3/ca/email/msg00766.html · Action Items: o Name | Employer/Affiliation | Alan Brown | Adtran, Inc. | Allard van der Horst | Semtech | Alexander Umnov | Corning | Andre Lessard | CommScope | Bill Powell | Nokia | Bruce Chow | Corning | Barry Colella | Source Photonics | Claudio Desanti | Google | Curtis Knittle | CableLabs | Dave Baran | Arris | David Claussen | Charter | David Law | HPE | Dekun Liu | Huawei | Derrick Cassidy | BT | Dora Van Veen | Nokia | Doug Jones | Comcast | Duane Remein | Huawei | Earl Parsons | CommScope | Ed Harstead | Nokia | Ed Walter | AT&T | Fernando Villarruel | Cisco | Francois Menard | Aeponyx | Frank Effenberger | Huawei | Glen Kramer | Broadcom | Greg LeCheminant | Keysight | Hal Roberts | Calix | Hesham ElBakoury | Huawei | Jesus Cotano | Telefonica | Jean-Christophe Marion | Tibit Communications | Jeff Finkelstein | Cox | Joe Jensen | Buckeye Communications | John D’Ambrosia | Futurewei subsidiary of Huawei | John Johnson | Broadcom | Jorge Salinger | Comcast | Junwen Zhang | ZTE | Kenneth Jackson | Sumitomo | Kevin Bourg | Corning | Kevin Noll | Tibit Communications | Lilin Yi | Fiberhome | Marek Hajduczenia | Charter | Mark Laubach | Broadcom | Matt Sheppard | Virgin Mobile | Michael Peters | Sumitomo | Mike Darling | Shaw | Mike Emmendorfer | Arris | Moiz Lokhandwala | Charter | Moon Park | OE Solutions America | Pete Pondillo | Corning | Phil Miguelez | Comcast | Philip Oakley | Virgin Media | Qing Xu | Belden | Richard Zhou | Charter | Roger Stafford | Charter | Ryan Hirth | Broadcom | Ryan Tucker | Charter | Saif Rahman | Comcast | Sebnem Ozer | Comcast | Sergio Prieto | Telefonica | Shan Wey | ZTE | Shawn Esser | Finisar | Victor Hou | Broadcom | Vincent Houtsma | Nokia | Wang Suyi | Fiberhome | Xiang Liu | Huawei | Yong Kim | | Zhou Zhen | Fiberhome | | |
Curtis Knittle VP Wired Technologies – R&D CableLabs desk: +1-303-661-3851 mobile: +1-303-589-6869 c.knittle@xxxxxxxxxxxxx Stay up to date with CableLabs: Read the blog and follow us on Twitter
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 |