Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

I am with Marek on this. And we did have this discussion on one of the calls.

Actual ONU's laser on/off times are not configurable. They are determined by characteristics of lasers and laser drivers. 
The OLT may never allocate less time for laser on/off than what is required by the ONU optics. But it may decide to allocate more time, for example, to use a single worst case value across the entire EPON, instead of different ONU-specific values.  Watever the values OLT uses, it only affects the Start Times of the grants. These values do not affect ONU at all.

In 10G-EPON, ONUs needed to subtract these numbers form the *gross* grant size, so the OLT had to communicate these values to the ONUs.
In .3ca, the OLT only grants the *net* grant size (without any overhead). The ONU doesn't need to subtract any overhead form it, so it doesn't need the OLT to tell it which values of laser on/off to use. 

There are no constants or variables in PCS/MPRS/MPCP state diagrams that include laser on/off times prescribed by the OLT. 


Glen

On Wed, Jun 20, 2018 at 5:30 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx> wrote:

Duane,

 

It might be a good topic to go through over at the upcoming call. Personally, I see the need for the OLT to know ONU laser on/off parameters (the announcement of which was not removed) but it escapes me why we would need to let the OLT set the on/off times at the ONU … when the OLT uses ONU provided numbers, there is no discrepancy or differences in expectations on both sides of the link

 

Thanks

 

Marek

 

From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Sent: Tuesday, June 19, 2018 5:44 PM
To: mxhajduczenia@xxxxxxxxx; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Cc: Duane Remein <Duane.Remein@xxxxxxxxxx>
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Marek,

Please review kramer_3ca_2a_0518 slide 4 for the reason I express this opinion.

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@gmail.com]
Sent: Tuesday, June 19, 2018 4:00 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

I believe we all agreed already that the ONU only gets start time and duration of the burst and does not have to verify or even question the OLT calculations. You seem to argue in the opposite direction, i.e., ONU needs to have all necessary parameters to confirm the OLT did the math right.

 

From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Sent: Tuesday, June 19, 2018 1:55 PM
To: mxhajduczenia@xxxxxxxxx; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Cc: Duane Remein <Duane.Remein@xxxxxxxxxx>
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Marek,

What if the OLT sends the ONU an invalid envelope?  For example two envelopes with non-equal start times (i.e., two bursts) but with insufficient inter-envelope time because of FEC misalignment between OLT calculations and ONU placement of FEC.  Should it blindly send it or should it ignore it?

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@gmail.com]
Sent: Tuesday, June 19, 2018 3:18 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Why would the ONU need to know that at all? It is the OLT that does scheduling for the PON as the whole, and has visibility into all ONUs.

 

From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Sent: Tuesday, June 19, 2018 1:14 PM
To: mxhajduczenia@xxxxxxxxx; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Cc: Duane Remein <Duane.Remein@xxxxxxxxxx>
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Marek,

I don’t recall the discussion to which you refer.  How would an ONU know what the worst case is for the entire PON?  This is really what is important, not what an ONU is capable of.  Certainly the ONUI doesn’t need this to adjust its own on/off times but how does it calculate the minimum inter-burst time if it has no idea what the worst case is?

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@gmail.com]
Sent: Tuesday, June 19, 2018 2:22 PM
To: Duane Remein <Duane.Remein@xxxxxxxxxx>; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Duane,

 

Page numbers were added.

 

As far as the laser on/off discussion goes, I do recall we had a rather lengthy discussion at the last meeting with conclusion that we would not need the OLT “confirm” ONU laser on/off capabilities, but rather let the ONU announce them in the REGISTER_REQ MPCPDU and OLT take them as they are. After all, the ONU knows what it can do and would not (likely) announce larger values than absolutely needed only to have the OLT trim these down in the REGISTER MPCPDU

 

Marek

 

From: Duane Remein <Duane.Remein@xxxxxxxxxx>
Sent: Tuesday, June 19, 2018 11:58 AM
To: mxhajduczenia@xxxxxxxxx; STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Cc: Duane Remein <Duane.Remein@xxxxxxxxxx>
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Marek,

On slide 11 (please add slide numbers) you indicate that the laser_on/off times are no longer needed but I think if you look at the new MPCP strategy these will still need to be communicated.  

The MPCP needs these to determine if a burst can be concatenated into one burst or needs to be split into two bursts.  The PCS determines the end of a burst by looking for an empty INPUT_FIFO.  This condition occurs when the MPCP does not issue a new envelope to the MPRS for a given amount of time equal to the minimum inter-burst time.  The minimum inter-burst time is determine by end of burst time, laser on time, and laser off time.  This also determines the size of the INPUT_FIFO.

Please reinstate laser_on time and laser_off time.

Best Regards

Duane

 

From: Marek Hajduczenia [mailto:mxhajduczenia@gmail.com]
Sent: Tuesday, June 19, 2018 12:38 PM
To: STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: Re: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Here is the updated version of the deck + associated set of changes for Clause 144 – note that all changes are tracked for simpler verification. I tried included only changes needed to address the delimiter announcement, excluding any other editorial changes (I will be submitting a number of comments on D1.1 to address other naming discrepancies, etc., in Clause 144).

 

Regards

 

Marek

 

From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Monday, June 18, 2018 11:42 AM
To: 'Curtis Knittle' <C.Knittle@xxxxxxxxxxxxx>; 'STDS-802-3-NGEPON@LISTSERV.IEEE.ORG' <STDS-802-3-NGEPON@LISTSERV.IEEE.ORG>
Subject: RE: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

Curtis, et al.,

 

I would like to revisit the delimiter announcement, with the specific focus on recording any corner cases and specific scenarios that need to be addressed to make it viable for adoption at the next meeting.

 

Thank you

 

Marek

 

From: Curtis Knittle <C.Knittle@xxxxxxxxxxxxx>
Sent: Monday, June 18, 2018 10:45 AM
To: STDS-802-3-NGEPON@LISTSERV.IEEE.ORG
Subject: [802.3_NGEPON] Call for agenda - 802.3ca (100G-EPON) consensus building meeting

 

 

Dear Colleagues,

 

We have an 802.3ca consensus-building meeting this Thursday, June 21, 11:30 am MST. Please let me know by 5:00 pm MST Wednesday if you have any contributions for this meeting.

 

Curtis

 

 

 

 

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