| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Duane, For the OLT buffering
requirement, I assume it is needed regardless it’s service aware or
service-unaware. The question is what types of buffering is needed: For
synchronized or coordinated sleep where all sleeping ONUs will enter the same
cycle (perhaps at a slight different times) and exit at the same time (after
optics power-on time adjustment), per ONU buffering is needed as well as
broadcast traffic buffering (unless we replicate the broadcast packets onto
unicast LLIDs). For
uncoordinated sleep or ONU initiated sleep (I am not suggesting that this
should will be included), I would think per ONU buffering is also a must while
broadcast traffic buffering is not possible – because it will need to be
buffered all the time (for example, the ONUs enter sleep in staggered fashion)
or broadcast traffic is simply discarded (if we can accept this). Keeping
ONU Rx always on would definitely help ‘service aware sleep’. My
proposal on ‘service aware’ is to include, in the sleep OAM, a
bitmapped byte to indicate what types of service traffics are being buffered at
OLT in downstream or at ONU in upstream. Such information can then be taken
into the decision making process – though the decision algorithm is
totally out of scope. Best,
Rick From: Duane Remein
[mailto:dremein@xxxxxxxxx] Rick, Duane, In addition to the length of the
sleep time - that tells the ONU ‘how sound and how deep the ONU
should be sleeping’, I think it may also make sense to include the type
of ‘sleep’: In-service
sleep: this type has the objectives of both power saving AND service quality
retention Out-of-service
sleep: this type has the primary objective to preserve power consumption (long
sleep by ignoring certain types of services) If we want to further, we can
include a set of services that are to be maintained and another set of services
which can be subject to disruption during a particular sleep cycle. This would support something
that can be coined as “service aware power saving or service aware
sleep cycle”. Best, Rick From: Duane Remein [mailto:dremein@xxxxxxxxx] All, Marek, Jeff, I agree we should have clear
definition on the terminologies. Please see my comments in line. Best, Rick 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. 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. 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. That said, I would like to move that we use
eOAM as the control channel for power saving mechanism. 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: 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. 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). 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, The next CC of the
powersaving adhoc is scheduled for Wednesday Sept 29,
at 0001 GMT (that’s Tuesday Sept 28 in the US) Access Numbers: US/Canada: 800-747-5150 Japan: 00531001555 China: 800-8190299 Israel: 1-809-458705 Korea: 00308140429 Portugal: 800-780604 Meeting code: 8276114 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? 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 |