item 1... It makes me a little nervous when you say that the EFM
transceiver costs the same as the FSAN compliant one... isn't that exactly
what we're trying to avoid? Economics is one of EPON's
claims to fame.
we can learn from FSAN in that we should avoid putting aggressive requirements
on the optics and end up with a costly solution that no one can afford. We
should be able to come up with a simple solution that works effectively with
-----Original Message----- From: David Levi
[mailto:david@xxxxxxxxxxxxxx] Sent: Monday, February 11, 2002 3:18
AM To: email@example.com; firstname.lastname@example.org;
email@example.com Subject: RE: [EFM-P2MP] MPCP: Report
I just want to clear
things concerning to Burst mode transceivers.
1. FSAN compliant 1.25Gbps D/S
and U/S transceiver with 3 or 12 bytes(several nsec) overhead cost the same as
transceiver with (10 usec? overhead or 1 usec). This is because Laser Driver ASIC that can handle
short turn on delay cost the same as continues Laser Driver (LD), where
probably the same LD that support continues mode will support burst mode with
several nsec turn on delay.
transceiver cost the same as 802.3ah transceiver. The transceiver costs lies
on the optic (BIDI, Laser Diode, PIN ), and
definitely not on the Laser Driver ASIC, where 802.3ah transceiver uses the
same optical components (two or three port bidi)as
3. 8 bytes overhead, which
represents turn on delay of several nsecs provides almost 150Mbps bandwidth more over
the link than 1usec turn on delay. Turn on /off of 1usec is 156byets times 64
for TDM voice per ONU resulting in 10000 bytes + 64* 156 for DBA + 70 ( for 1500buts per slot)*156 = 31000 bytes. 31000 bytes in
1 msec is around 200Mbps. 8 OH bytes only eat 64Mbps.
price for end to end 8 bytes OH cost the same as 156 bytes
[mailto:firstname.lastname@example.org]On Behalf Of
Friday, February 08,
[EFM-P2MP] MPCP: Report message
I'd like to follow up
on some of the discussions re: scheduling and REPORTs.
So far we have
identified two approaches to assigning timeslots:
Static timeslot assignments -- no REPORTs are
generated by ONUs for BW
The OLT sets up astatic
timeslot scheduling plan, and generates GATEs
for each ONU
Each ONU receives a grant for a fixed timeslot at a time,
Each ONU recieves a grant for multiple fixed
timeslots for a period of
time (multi-cycle grant)
A TDM scheme is best
implemented through this approach.For jitter/delay
sensitive TDM traffic, some of us
strongly believe multi-cycle granting is
the best way to go.
Dynamic timeslot assignments --REPORTs may be used to provide the DBA
The OLT now dynamically schedules timeslots, and generates GATEs for each
Each ONU receives a grant for a fixed timeslot at a time.It may
optionally communicate it's BW
needs to the OLT via REPORTs.
Notice that DBA
designs are proprietary, and may desire a wide range of
parameters in the feedback
loop.Fortunately this is
(and should remain)
out of our scope.However, even in its simplest form,
the upstream BW
efficiency is negativelyaffected in order to support REPORTs upstream.
Here is an example
(assuming 64-Byte REPORTs).
to have ONUs responsive with a granularity of 1ms,
overhead for a 64-split is
64x64B/(0.001s) = 32.8 Mbps + timeslot framing
overhead.As Bob pointed out, the latter
can easily be in the order of
usec = 600% overhead on a 64Byte (0.512 usec) frame.
*very* conservatively we can easily eat up> 20% of the
just to make DBA work.
would be > 60% BW overhead if the framing overhead was 10
numbers may look slightly better (statistically) with upstream
piggybacking of REPORTs in the case of higher upstream traffic loads.
The tendency will be
to reduce these numbers by putting tighter constraints
on the lasers and clock recovery
mechanisms a la FSAN.This
equates to more
Now consider a
solution, based on DBA, that includes TDM services...
now hasto dothe following:
wait for a GATE poll
send a REPORT (requesting TDM BW)
wait for a GATE (w/details of Timeslot to transmit TDM data)
wait for actual time to send its data...
and repeat this for EVERY TIMESLOT.
The actual overhead
needed to manage this mechanism is significant to say
Fortunately, today we
are faced with a 'glut' of bandwidth and the
need/requirement for dynamic
bandwidth provisioning is unnecessary.
the upstream bandwidth with a constant request for
bandwidth is not warranted.
We have the
opportunity to introduce a more cost effective approach.That
translates to a solution that
will win acceptance in the marketplace, and
that is good for all of us.
Static mapping of
upstream bandwidth is sufficient, and TDM traffic can be
transported expediently.It means a less complex OLT and
The nature of the
optics will limit the number of ONUs to 64.Once again,
this isn't a 2000-modem DOCSIS
system,nor does it exhibit the
a cellular phone system, so the
standard Aloha-based algorithms are not
required.This is not to say that they
should be dismissed,but it is
important that multiple methods
of bandwidth scheduling should be allowed in
From: Horne, David M
Wednesday, February 06,
[EFM-P2MP] MPCP: Report message
re: Especially if the intention
is to have the OLT be responsive to ONU
in near real-time,...
Can you define "near
real time?" Could be 6000-7000 timestamps elapse just
from transit delay. How would we
put a bound on processing and scheduling
delay at OLT if we are not
specifying scheduling algorithm?
There are many ways to
address the provision of upstream bandwidth requests,
but no one wants any level of
complexity or contention slots. That pretty
much means waste is a given. This
isn't necessarily a bad thing if it saves
complexity and doesn't encroach
on needed bandwidth. Have to show
quantitatively that the waste is
too excessive. It will be hard to do that,
given that unused reservations
don't follow any regular pattern.