| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Rick Comments inline with [mh0925]
tags Regards Marek Hajduczenia 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. >>>Rick: my understanding
is that MAC control extension may be treated with higher priority than OAM (I
am not sure if standard specified the relative priority between MPCP and OAM
messages). As such, critical signalling messages such as protection switch and
power saving sleep message may use MAC control. However, since OAM message is
already specified with high priority, this is probably a moot point. I would personally prefer a single
signalling mechanism for power saving signalling (and perhaps also protection
switching). eOAM would be the preferred approach since it’s backward
compatible with existing hardware. Ideally, the equipment would be able
to transport both types of messages, allowing service providers to choose. [Marek Hajduczenia]
[mh0925] we cannot design something that throw away all the existing
‘pre-SIEPON’ gear away…that is why I argumented (and will
argument) against MAC Control EXTENSION frame. It is a nice mechanism for
something that would be needed in 10G-EPON only but we all know I think very
well that it is hard to expect someone with existing implementation to go and
change it because support for a new MAC Control frame is needed. I think eOAM
can do its job in here, especially now that we have no frame rate limit on the
horizon. Also, the priority argument is kind of moot for me as well. OAM is
high priority traffic and whether you give it more priority than MAC Control or
not … well, that is implementation. 802.3 says nothing on the priority
levels, especially since both frames go into different data paths and are
handled by different clients. I would urge us not to use
two solutions and focus on OAM mechanism. 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. >>>Rick: -
We agreed (I think) in
the past two sessions that ONU will have a role in participating the decision
making if the ONU will sleep or not after receiving the ‘sleep’
command from OLT, regardless the initiation is OLT or ONU. This is because the
ONU possesses specific knowledge about its own real-time condition (such as
environmental condition like local battery level, main power supply) and
upstream traffic status, and IPTV subscriber membership etc. -
The initiator (this can be
OLT central controlled or ONU self-initiated) performs initial eligibility
check – note this merely qualifies an ONU to be considered for a
particular sleep cycle, but not final decision. The OLT
can naturally be the initiator for downstream eligibility checking criteria
– then the ONU will perform subsequent local additional check to make
final decision. Similarly, the ONU can
naturally be the initiator for upstream eligibility checking criteria –
then the OLT will perform subsequent additional check to make final decision.
One particular example where ONU may serve as the initiator is where an ONU has
lost main power supply and fall back to backup battery. Under such condition,
the ONU may prefer to enter as many sleep cycles as possible, except when it is
handling certain emergency services such as voice. If OLT is the sole
initiator, the OLT may rule that the ONU is not eligible for power saving at
all since it has significant Internet traffic for example. -
My point here is that if
we want OLT to be the sole initiator for power saving (which I also support),
the OLT may need to have the knowledge of additional ONU conditions of all the
ONUs on that PON interface – such condition may include, for example,
ONU’s upstream traffic status (not yet reported via MPCP report),
environment conditions, IGMP memberships (OLT does have this though its
snooping/proxy). [Marek Hajduczenia]
[mh0925] OLT is never more than 200us away from knowing the status of ONU
queues. The central OLT based traffic scheduling works fine right now and we
know for the fact that very high efficiency of scheduling is achievable which
is a clear indication that the OLT is controlling the ONU in real-time and
reliably. Oo IGMP – I think
that the OLT is notified on any changes to multicast membership –
otherwise, how would it know when to stop sending some of the multicast
streams? Also, we are entering into the world of implementation
differentiation. Hope to see some discussion on
the reflector (it has been awfully quiet in here recently) >>>Rick: I am contributing. 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 |