RE: [EFM] Minutes from PON Optics Telephone Conference - 25th October
Hugh,
I don't want to go too far down the decision tree too soon, but here
are some quick answers: We will have to use our informed judgment to
select startup values for these parameters. These values will be
documented in the standard, perhaps as part of P2MP clause. Per
figures 56-26 and 56-27, we have defined 2-byte registers for these
parameters. As long as the registered value is less than the startup
value, the implementation will be compliant. So the range limits are
0 to startup_value. Yes, as before, we will need a test procedure to
measure the registered values of timing parameters. To ensure
interchangeability, we have to choose small enough startup values so
a fully configured system using highest permissible registered
values (i.e., equal to startup values) will still continue to
function robustly. Of course, if higher efficiency is desired,
implementers are free to choose PMD and PMA devices that do much
better. The proposal here is to leave that cost-efficiency tradeoff
to the implementers. The subtle effect of this proposal is that by
deleting entries of these parameters from Clause 58, and by adding
suitable notes in Clauses 56 and 58, we can underscore a decision
that we wanted the post-standard market situation to decide the
optimum tradeoff between cost and efficiency of EFM.
I am thinking I should proceed in a top down fashion on this issue.
First, I will give a presentation to the task force on this topic,
probably on November 14th. I will present the members of the TF
three options: (A) select tight parameters, (B) select loose
parameters, or (C) leave it to implementers. Depending on the
outcome of the ensuing discussion and straw poll, we will know our
next course of action.
I admit this is a difficult decision. If we don't like the
consequences of C, we'd better choose A or B!
Regards,
Vipul
=============
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Hugh
> Barrass
> Sent: Friday, October 25, 2002 1:04 PM
> To: Vipul_Bhatt@xxxxxxxx
> Cc: stds-802-3-efm@ieee.org
> Subject: 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
> > >
> > >
> > >
> > >
>