| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Marek, Thanks for your msg. * The motivations mentioned in
the CC for the use of MAC Control include a) MAC Control is intended for
realtime control, while eOAM is intended for management, and sleep control
seems to belong to the realm of “realtime” b) MAC Control
includes a broadcast channel, whereas eOAM currently does not. On first
CC there was a request to delay the decision on eOAM vs. MAC Control in order
to study the matter further. * Simplicity is very
important as you say. As Rick has stated, there is at least one
situation where the ONU needs to prompt for sleep mode entry (ie. power failure).
I also want to encourage people to look at signaling overhead. Jeff From: Marek Hajduczenia
[mailto:marek.hajduczenia@xxxxxxxxx] Hi Jeff, Is the meeting at
midnight sharp or 1 AM ? That 0001 GMT looks weird :P Regarding the topics
for discussion: -
I think we need to define what the terms dozing, cyclic
sleep and deep sleep mean for us. Do we use G.sup45 definitions or modify
something in here ? -
I would like to understand as well what the advantage of
the MAC Control over OAM channel is for sleep signalling. 1.
Given the configurability of the OAM frame rate (it is
not up to the operator to decide how many frames per second are to be
generated), I am not sure where the advantages of the MAC Control lie. 2.
Additionally, something that is a strong argument against
MAC Control, it is not backward compatible with 1G-EPON hardware. Unless we
expect to force silicon respin for SIEPON compatible hardware, we should use
signalling solutions which are available in legacy equipment and which can be
adapted to our needs through firmware upgrade. 10G-EPON is less of a problem
but the solutions SIEPON WG produces MUST be by definition, applicable to both
1G-EPON and 10G-EPON. Otherwise we would be going against our own PAR. 3.
That said, I would like to move that we use eOAM as the
control channel for power saving mechanism. 4.
I also understand you will be distributing some slides on
Monday. Do they address comparison between these solutions or there are other
proposals on the table that I am not yet aware of? -
OLT-initiated versus ONU-initiated sleep: 1.
in my opinion, the ONU in EPON has always been considered
a slave device with limited processing capabilities. I would like to see it
remain that way. We have an example of alternative specifications which pack
many functions onto the ONU leading to both device complexity, added cost and
what’s more important – device interop problems. 2.
The fewer the functions on the ONU, the simpler it is to
interoperate with the OLT. I am strongly in favour of the OLT driven approach.
The ONU is told what to do and not what it feels like doing. OLT is never more
than 200 us away from knowing that the ONU is running without any traffic,
which should be sufficient to guarantee very reasonable efficiency of the
protocol. Hope to see some
discussion on the reflector (it has been awfully quiet in here recently) Regards Marek Hajduczenia From: Jeff Mandin
[mailto:Jeff_Mandin@xxxxxxxxxxxxxx] The date was incorrect in the
previous announcement. Please see corrected
announcement below: Dear all, 1.
The next CC of the powersaving
adhoc is scheduled for Wednesday Sept 29, at
0001 GMT (that’s Tuesday Sept 28 in
the US) 2.
Access Numbers: US/Canada: 800-747-5150 Japan: 00531001555 China: 800-8190299 Israel: 1-809-458705 Korea: 00308140429 Portugal: 800-780604 Meeting code: 8276114 3. Topics for discussion: * Options for control protocol
(I will distribute these slides by Monday) * ONU-initiated wakeup (Seiji
Kozaki/Ryan Hirth) * Answers to outstanding
questions on Deep Sleep (Duane Remein) - Deep
sleep questions included: Is it just longer sleep times or is there
something else required for support? What is the benefit over
deregistering and reregistering? 4. Scheduling: 0000 GMT and 0400 GMT are times which
work well for the US West Coast and for Asia. We will be alternating
between these two times. Thanks and Best Regards, Jeff Mandin PMC-Sierra |