| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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----- 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 Regards, Glen ________________________________________ From: 植松 澄/Kiyoshi Uematsu
[mailto:uematsu903@oki.com] Sent: Friday, April 04, 2008 5:22 AM To: Cc: 'Jeff Mandin'; 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 Regards, kiyoshi Uematsu -----Original Message----- From: 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 - 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 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, _______________________ Chair, IEEE P802.3av "10GEPON" Task Force |