| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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> Marek, Please review kramer_3ca_2a_0518 slide 4 for the reason I express this opinion. Best Regards Duane From: Marek Hajduczenia [mailto:mxhajduczenia@xxxxxxxxx] 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> 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@xxxxxxxxx] 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> 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@xxxxxxxxx] 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> 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@xxxxxxxxx] 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> 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> 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 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 |