| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Jeff, I agree with you on the
interpretation of the target function of MAC Control versus OAM. However, if we
go into MAC Control channel for this, we will effectively prevent any existing
equipment from using this feature because changes to MAC Control will in most
cases require silicon respin. If we do not care about legacy, it is fine but I
think then we are going against our initial assumptions of providing
definitions for both existing and future deployed devices … On the prompting feature – that is
an early wake-up time, which does not invalidate the principle of centrally
driven sleep process. The OLT may (at the discretion of the operator’s
configuration) send grants to the ONU knowing it might not get anything back.
If the ONU happens to need one of these, the transmission opportunity might be accepted
and the dying gasp might be sent. How does that require any additional logic
from the ONU? Regards Marek Hajduczenia From: Jeff Mandin
[mailto:Jeff_Mandin@xxxxxxxxxxxxxx] 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 |