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
a) There is plenty of padding left in a message. If we don’t use it for any fields, we just send zeroes anyway.
b) All fields are even, so the frame can be parsed on word boundary instead of byte boundary.
c) 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