Re: [8023-10GEPON] March minutes and presentations are online
Dear Uematsu-san,
First, I want to mention that this discussion is not an acknowledgement on my part that adding power saving features to MPCP is in our scope. This should be a separate TF (and WG) discussion (if we agree that the proposed method would need any changes to the draft).
But currently, I still don’t see any changes that would be required to support method shown on slide 4.
Let me address the specific items you highlighted in slide 6 (I'll use C64 for reference):
1) OLT Force Report flag
NEW BEHAVIOR: GATES have Force Report flag = 0
Current behavior: Decided by MAC Control Client through the use of MA_CONTROL.request primitive. MAC Control client is outside the scope of 802.3.
COMMENT: Implementation that wants to use the proposed power saving scheme is free to issue GATEs with force_report=0. The standard does not preclude it and no changes required to the draft.
2) OLT Grant generation:
NEW BEHAVIOR: GRANT is regularly provided by GATE MPCPDU.
CURRENT BEHAVIOR: Please, see 64.3.4: "Reports shall be generated periodically, even when no request for bandwidth is being made. This keeps a watchdog timer in the OLT from expiring and deregistering the ONU. For proper operation of this mechanism the OLT shall grant the ONU periodically." and 64.3.5: "In order to maintain the watchdog timer at the ONU, grants are periodically generated. For this purpose empty GATE messages may be issued periodically."
COMMENT: Current specification already requires periodic grants issues for each ONU. The exact period is limited by 1 sec (mpcp_timeout constant), but the actual value is decided by MAC Control client, which is outside the scope of 802.3.
3) Generation of REPORT by ONU
NEW BEHAVIOR:
(a) A REPORT MPCPDU #1 (Periodic Transmission) with maximum interval if ONU requires no upstream traffic.
(b) A REPORT MPCPDU #2 (Transmission by MACR) if ONU requires upstream traffic.
CURRENT BEHAVIOR: If GATE with force_report=0 is received, the MAC Control client is still allowed to issue a REPORT. There is an additional watchdog mechanism that will generate a REPORT in MAC Control, if MAC Control client does not generate it in time. The report_timeout is set to 50ms (see figure 64-25).
COMMENT: Current specification allows both MPCPDU #1 and #2 to be issued by MAC Control Client, or #1 by MPCP and #2 by MAC Control client. Implementation that wants to use the proposed power saving scheme is free to issue REPORTS when it receives force_report=0. The standard does not preclude it and no changes required to the draft.
4) ONU report_periodic_timer
NEW BEHAVIOR: 50 ms
CURRENT BEHAVIOR: less than 50 ms
COMMENT: The report_periodic_timer controls maximum time between generation of REPORT frames (actual transmission time depends on when the next grant will be available.) In some cases, the period between REPORTS maybe smaller than 50 ms. It is not clear if in the proposed schemes it is critical that the period is exactly 50 ms, and not say, 49.5 ms Please, elaborate.
5) Reception of force_report=1 at ONU
NEW BEHAVIOR: A REPORT frame should be issued
CURRENT BEHAVIOR: A REPORT frame should be issued
COMMENT: Behavior is identical to current spec. The field should not be highlighted.
I currently do not see any need to change MPCP to support the proposed solution #1. All the needed behavior is determined by functions confined to MAC Control Client. I apologize if I am still misunderstanding anything in you proposal. In this case, please, point to specific parts of the existing clause 64 or clause 93 that need to be changed.
Regards,
Glen
________________________________________
From: 植松 澄/Kiyoshi Uematsu [mailto:uematsu903@oki.com]
Sent: Monday, April 07, 2008 1:29 AM
To: Glen Kramer; STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: RE: [8023-10GEPON] March minutes and presentations are online
Dear Glen,
Thanks for your quick comment.
I think that your understanding for the report processing specified in CL64.3.4 and/or CL93.3.5 is correct. However, what you are missing from the presentation are:
- Current CL64 and /or 93 allows the examples of implementation shown in slide 2 and 3,
which cause increased latency or unnecessary REPORT transmission.
- In order to realize both reduction of REPORT transmission and minimum latency, two solutions such as proposal#1 and 2 shown in slide 4 and 5 are proposed.
- For the proposal#1 and #2, several modifications for CL64 and/ or CL93, part of yellow highlighted in the table on slide 6, are necessary such as constant value of report_periodic_timer.
Regards,
Kiyoshi Uematsu
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@TEKNOVUS.COM]
Sent: Saturday, April 05, 2008 2:28 AM
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: Re: [8023-10GEPON] March minutes and presentations are online
Dear Uematsu-san,
The decision whether to generate REPORT or not is done at a higher layer (DBA agent) which is outside the scope of the standard. According to the existing standard (clause 64) or to the current draft of clause 93, the higher layer is expected to generate a REPORT when it receives an indication of a grant with force_report=1. But there is no requirement that a REPORT cannot be sent in a grant with force_report=0. Please, note what the draft says:
93.3.4.5 Messages
MA_CONTROL.request(DA, REPORT, report_number, report_list)
This service primitive is used by a MAC Control client to request the Report Process at the ONU to transmit a queue status report. This primitive may be called at variable intervals, independently of the granting process, in order to reflect the time varying aspect of the network.
Similarly, nothing in state machine in Figure 93-25 will stop a REPORT, when it is generated by a higher layer. It will go out at the first transmission opportunity that the ONU has.
In case, when grants arrive with force_report=0, and data waiting in the queue, it is perfectly OK, and quite reasonable for the ONU to generate an unsolicited REPORT, as you state in the proposal #1.
Thus, I will repeat the comment I made in Orlando that what you propose as a solution #1 (on slide 4) is already possible and no additional changes are required to the draft. If I missed something, please let me know what specific changes to the draft are needed in your opinion.
Regards,
Glen
________________________________________
From: 植松 澄/Kiyoshi Uematsu [mailto:uematsu903@oki.com]
Sent: Friday, April 04, 2008 5:22 AM
To: Glen Kramer; STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Cc: 'Jeff Mandin'; 'Yasuyuki Kuroda'
Subject: RE: [8023-10GEPON] March minutes and presentations are online
Dear 10G-EPON TF members,
Apology for late action, but here is outline of issues to be solved for
the Power Saving. I would like ask Forks to make comment for this.
1. Reduction of numbers of Report frame transmit
An attached is two ideas which describe how to realize the reduction
of numbers of Report frame transmission and summary of study items
to be discussed in TF. As conclusion of our study, in order to obtain
merits of the Power Saving, current CL93 have to be modified or specified
with additional condition though it looks like small modification.
<Requirement for Common>
-GRANT needs to be regularly provided by GATE MPCPDU.
-Maximize report_periodic_timer from less than 50ms to 50ms.
<Requirement for Proposal 1>
- Usually, set GATE MPCPDU which has Force Report flag =0.
(It is allows that OLT sends GATE MPCPDU which has Force Report flag=1.)
- Specify that the ONU report processing state diagram which allows transmission of
A REPORT MPCPDU (Periodic Transmission) with maximum interval if ONU requires
no upstream traffic.
< Requirement for Proposal 2>
- Ignore for force report flag at ONU.
2. Study of Suggested Remedy for CL93
Still on going. It would be more than welcome if someone can join in
this task.
3. Other ideas for Power Saving
Kuroda san proposed the reduction of numbers of Report frame transmission,
but if there may be other ideas, please issue and discuss on reflector and
upcoming Tokyo meeting
Regards,
kiyoshi Uematsu
-----Original Message-----
From: Glen Kramer [mailto:glen.kramer@TEKNOVUS.COM]
Sent: Thursday, March 27, 2008 5:20 AM
To: STDS-802-3-10GEPON@LISTSERV.IEEE.ORG
Subject: [8023-10GEPON] March minutes and presentations are online
Dear Colleagues,
March meeting minutes and presentation materials have been posted on the web at http://www.ieee802.org/3/av/public/2008_03/index.html.
In Orlando we have reviewed 323 comments against D1.1
- Resolved: 304 (E and ER were processed in bulk)
- Withdrawn: 9
- Deferred: 10
The resolved comment report will be posted by the end of this week.
Our next meeting will take place in Tokyo on April 13-14, hosted by NTT. Below is our schedule in preparation for April meeting:
March 28: Draft 1.2 is posted
March 29 - April 4: Commenting period
April 5: All comments are published
April 11: Comments with proposed responses published
April 13-14: Comment resolution during April Interim meeting
In addition to commenting on draft 1.2, we identified the following big ticket items:
1) Damage threshold values ad hoc - Frank Effenberger
2) Mathematical analysis of impact of FEC codeword invalidation
- Expected post-FEC BER - Seiji Kozaki
- Probability of receiving a corrupted frame - Raymond Leung (tentative)
3) Analysis of Tx and Rx PCS delay - Eric Lynskey
- Impact of IDLE insertion
4) Clause 64 ad hoc - Marek Hajduczenia
5) Jitter ad hoc - Ryan Hirth
6) FEC test vectors - Jeff Mandin
7) Power saving proposal - Kiyoshi Uematsu
The ad hoc leaders listed above will make separate announcements on the reflector, outlining the issues to be solved and plan of work. If you are interested in participation in one or more of these discussions, please contact corresponding ad hoc leader listed above.
Detailed information about April meeting can be found here: http://www.ansl.ntt.co.jp/Interim_Meeting/index.html
Please note that registration is required to attend the meeting. Registration deadline is April 10th, 2008.
Regards,
_______________________
Glen Kramer
Chair, IEEE P802.3av "10GEPON" Task Force
glen.kramer@ieee.org