Re: [EFM] Minutes from PON Optics Telephone Conference - 25th October
Vipul,
I apologize in advance for weighing in on someone else's subject, but I want to
raise two questions:
1. How would compliance be tested? Would it simply be a matter of proving that
your burst mode parameters match what you say they are? Would there be limits to
the range (I hope so)?
2. How does this effect interchangeability? If one manufacturer has very tight
parameters, an installation may be working fine until a component is swapped out
for another with looser parameters and, suddenly, applications stop working.
That doesn't sound very "Ethernet-like" to me.
I fear that end customers would end up having to check these timing parameters
for each vendor's equipment, or else would have to compile lists of "compatible"
vendors - instead of just looking for the 1000BASE-nnn port type.
Hugh.
Vipul Bhatt wrote:
> 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
> >
> >
> >
> >