RE: [EFM] Minutes from PON Optics Telephone Conference - 25th October
Thomas,
Thank you for organizing this call. If I may, I would like to
elaborate on my proposal. Feedback welcome.
We are unable to agree on burst mode timing parameters (turn on/off
delay, AGC settling time, CDR lock time) because there are two
schools of thought on this subject. One school says these values
need to be close to those of FSAN, while the other school says that
much larger values are perfectly fine for EFM. Both schools insist
that their values permit cost-effective PMDs.
Perhaps there is a win-win solution possible. The idea is to leave
these values unspecified, leaving them to implementers. During
startup, the system will use some (TBD) startup values of these
parameters. This allows the system to go through discovery and
registration. After registration, OLT and ONU use registered values,
which are less than or equal to the startup values. In 802.3ah
document, we don't have to specify these registered values; the plan
now would be to delete these entries from Clause 58. This allows
users of both slow and fast PMDs to implement systems their way.
Eventually, the market will decide where the sweet spot of
cost-effective PMD/PMA parameters is. The point of this idea is to
enable the market to decide that later, and enable us to move
forward now.
If we agree to this idea in principle, we can move our focus to two
work items, where consensus is more likely to happen: (1) How does a
PMD communicate its parameters to ONU and OLT? We can mandate
MDC/MDIO, or again, leave it to an understanding between a system
vendor and PMD supplier. We need some ideas here. (2) What should be
the startup values? They can and should be large enough that most
PMD/PMA vendors can achieve it, because these values will be used
for only a few milliseconds. The system will then move to using
registered values, which will be whatever the competition and market
decides. There is no need to fear that registered values will be
"unreasonably" high, because they will be subject to competition
among PMD vendors. The only risk we are taking is the assumption of
this competition.
Regards,
Vipul
vipul_bhatt@xxxxxxxx
408-857-1973
===========
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of
> Thomas.Murphy@xxxxxxxxxxxx
> Sent: Friday, October 25, 2002 9:33 AM
> To: stds-802-3-efm@ieee.org; piers_dawe@agilent.com;
> Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx;
> FEffenberger@xxxxxxxxxxxxxxxxx;
> lior.khermosh@xxxxxxxxxxx
> Subject: [EFM] Minutes from PON Optics Telephone Conference - 25th
> October
>
>
>
> Attendees
> ----------------------------------
>
> Lior Khermosk
> Vipul Bhatt
> Piers Dawe
> Meir Bartur
> Trement Miao
> Richard Michalowski
> Tom Murphy (hope I spelled all names correctly!)
>
> Action Items
> ----------------------------------
>
> Vipul to formulate comment
> Tom to communicate with Frank regarding status of GPON
> document liaison and
> his presentation
> Tom to communicate with Shawn Rogers regarding CDR sensitivity to
> synchronous non-synchronous systems
> Tom to communicate with Howard regarding policy for PICS
> Tom to work on insertion loss tables, co-ordinate with
> Piers and others
> Lior to work on testing
>
> PON Timing
> ----------------------------------
>
> There has been very little feedback from PMD vendors
> regarding burst mode
> parameters. Because of this, Vipul suggested that the
> following solution for
> moving forward:
>
> Define a very generous upper limit for Tx on/off and Rx
> recovery. This
> value
> is either obtained via MDC/MDIO or negotiated. (These
> upper limits could be
> discussed at the
> next meeting but would be of the order of micro-seconds.)
> A slow Rx working
> with fast Tx's would
> fill out the preambles. Tx times of 16 ns etc are still
> allowed; is an
> implementers issue.
> There would be no PMD values listed in Clause 58, the values would
> be limited by the protocol and listed at this section in
> the standard. A
> reference
> in the PMD section would point to these limits with a
> statement that
> faster times are of course compatible.
>
> Almost all of the group were in agreement that this is a
> good way to move
> forward
> with one person wanting to think about it before the next meeting.
>
> Misc
> ----------------------------------
>
> What is the effect on CDR operation with different timing
> schemes. For
> example, are the
> assumptions of 1 micro-sec based on syn system?
>
> Next Meeting
> ----------------------------------
>
> Next Thursday 31st October. Probably at 09:30 Pacific,
> but I need to
> confirm this with the 100M group
>
> All the best
>
> Tom
>
>
>
>