| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Glen, The presentation does not only point
out what kind of modifications or changes to the dart required for the implementation of proposal#1
and #2. It would rather point out what kind of regulation to the draft get required in order to avoid
the implementation which cause latency increase and unnecessary report transmission for Power
Saving achievement. As for the specific items you would addressed, please refer to my comment
in line below. Regards, Kiyoshi Uematsu :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. As you commented above, GATE with force
report can be issued ether value, 0 or 1, by MACR. If venders implementation select GATE
with force report = 1 frequently during 50ms, ONU has to send REPORT with no limitation of number
of transmission. That is because I recommend usually set GATE with force report =0 with some
exception though we have not found proper remedy text to the draft yet. :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. As you see, GATE message send to ONU
in any time by decision of MACR. In order to avoid this, I think that regulation to the
draft such as grant is regularly provided by GATE MPCPDU is necessary. :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. In current draft, REPORT can be sent
even if ONU does no have the upstream traffic or receive GATE message (refer to example1 and 2).
So in order to avoid this I propose the new behavior above. :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. Your comment may be right, I do not have
strong preference for timer value itself now. What I would like intend is to specify the constant value
of timer, not valuable in order to reduce the number of transmission. :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. Yes, your comment is right. This is just
an error. :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 : -----Original Message----- 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: 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: 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 Regards, Glen ________________________________________ From: 植松 澄/Kiyoshi Uematsu
[mailto:uematsu903@oki.com] Sent: Friday, April 04, 2008 5:22 AM To: 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 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 |