RE: [EFM] RE: HEADLINE: Oscar Wilde resolves EFM PON timing issues!!!

["Gerry Pesavento" <gerry.pesavento@xxxxxxxxxxxx>]

Tom, Frank,

I have a few comments on the Option A vs Option D discussion. 

(1) The one-time transfer of timing parameters (Option D) is built into
the MPCP protocol, and communicated in the order below, when an ONU is
initialized. 
	
	GATE (Discovery)	
		AGC Settling Time
		CDR Lock Time
	REGISTER_REQ
		Turn-on delay
		Turn-off delay
	REGISTER
		AGC Settling Time
		CDR Lock Time
		Echoed turn-on delay
		Echoed turn-off delay
	REGISTER_ACK
		Echoed AGC settling time
		Echoed CDR lock time

(2) There is now delay variability built into the protocol of 64 ns at
each node (32ns x 2 for OLT, plus 32ns x 2 for ONU, total 128 ns round
trip) that will be added to Draft 1.2.  This is a significantly large
number considering the 16ns and 50ns Option A numbers being proposed.


(3) The discussion of the hard-wire reset also comes in to play.  I have
a question - with Option A, will the OLT hard-wire reset have to be
added to the specification to achieve the tight 50ns numbers?  I think
with Option D, we can avoid having to deal with reset.  The reset signal
(because the OLT would need to be smart enough to know when to reset)
changes the OLT requirements.

So after hearing the issues last week, I lean toward option D, but not
overwhelmingly.  My reasons are that (1) the parameter initialization is
already built in to the protocol, (2) there is high delay variability in
the specification which makes tight timing parameters unnecessary, and
(3) I am concerned about the hardwire reset requirement that comes with
Option A and its implications to the protocol.    
__________________________

Gerry P
__________________________
 

> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-
> efm@xxxxxxxxxxxxxxxxxx] On Behalf Of FEffenberger@xxxxxxxxxxxxxxxxx
> Sent: Wednesday, November 20, 2002 8:29 AM
> To: Thomas.Murphy@infineon.com; stds-802-3-efm@ieee.org;
> Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx; FEffenberger@xxxxxxxxxxxxxxxxx;
> KIM_AJUNG/sait_breakthrough_stars_grp13@xxxxxxxxxxxxx; Meir@xxxxxxxx;
> wsoto@xxxxxxxxx; eyal@xxxxxxxxxxxxxxxxxxxxxx; raanan@xxxxxxxxxxxxxxx;
> francois.fredricx@xxxxxxxxxx; BDeri@xxxxxxxxxxxx; s-rogers@xxxxxx;
> maurice.reintjes@xxxxxxxxxxxxx
> Subject: [EFM] RE: HEADLINE: Oscar Wilde resolves EFM PON timing
issues!!!
> 
> 
> Dear Tom,
> 
> On the contrary, I, and the majority of recipients of your Email,
> believe that alternative A is the best choice.  I plan to continue
> to support this alternative, and prepare a presentation to this
> effect for the Vancouver meeting.
> 
> Regards,
> Frank Effenberger.
> 
> 
> -----Original Message-----
> From: Thomas.Murphy@xxxxxxxxxxxx [mailto:Thomas.Murphy@xxxxxxxxxxxx]
> Sent: Wednesday, November 20, 2002 11:26 AM
> To: stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org; wdiab@cisco.com;
> FEffenberger@xxxxxxxxxxxxxxxxx;
> KIM_AJUNG/sait_breakthrough_stars_grp13@xxxxxxxxxxxxx; Meir@xxxxxxxx;
> wsoto@xxxxxxxxx; eyal@xxxxxxxxxxxxxxxxxxxxxx; raanan@xxxxxxxxxxxxxxx;
> francois.fredricx@xxxxxxxxxx; BDeri@xxxxxxxxxxxx; s-rogers@xxxxxx;
> maurice.reintjes@xxxxxxxxxxxxx
> Subject: HEADLINE: Oscar Wilde resolves EFM PON timing issues!!!
> 
> 
> Wilde once said, "The Irish know the cost of everything and the value
of
> nothing"
> 
> I think for the case at hand, he meant the opposite for me in that I
can't
> put an exact cost on
> the various options for the burst-mode TRx's but I do know the value
of
> resolving this issue
> and proceeding. This is prio #1 for me now
> 
> For those of you not at the last meeting, a brief summary of the
timing
> discussions follow:
> 
> Summary
> 
> The timing question was presented to a joint session of the optics and
P2MP
> group.
> Of the four choices, (see
>
http://grouper.ieee.org/groups/802/3/efm/public/nov02/optics/bhatt_gener
al_1
> _1102.pdf)
> the group narrowed down to a choice between A and D, that is FSAN
values - A
> and leaving the values
> open to implementation - D. In all votes, D had the majority, greater
than
> 75% among all people present, but
> failing 75% among 802.3 members.  The same choice was presented to the
whole
> 802.3 group with the
> majority again in favour of D, but not 75%.
> 
> It is my opinion that option D would have achieved a majority but
people
> were afraid
> of voting for something with no values. There was also the fear that
> choosing this option would imply
> that certain services would possibly no longer work two 'in-spec'
> transceivers were swapped.
> 
> How to Proceed
> 
> First off, a lot of people abstained at all votes.  Please inform me
if
> there are open technical issues that need
> to be addressed before you say yea/nay. Lets reduce number of A's!!!
> 
> Based on the voting of the last meeting, I think the best way to
proceed is
> to elaborate on
> option D.  For me this implies the following:
> 
> *	Agree on a value that would appear in option D for a maximum
start
> up time.
> This value should be agreed upon by a number of PMD vendors and may
> be the sum of Tx and Rx values, or split between the two. This needs
to be
> decided.
> *	An agreed value would be also be presented as the resulting
> efficiency of this guardband.
> *	Ensure that the protocol and architecture that he system is
future
> proof and that
> transceivers with faster response times can be dropped seamlessly into
the
> link.
> In this way, show that all people get what they want at the end of the
day.
> 
> I thank all of you who contributed for the last presentation. Please
keep
> this
> up and lets close on values at the Vancouver meeting
> 
> Regards
> 
> Tom