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