RE: [EFM] Re: [EFM-OAM] New update on EFM OAM Work Item #3

[Vipul Bhatt <Vipul_Bhatt@xxxxxxxx>]

Ben,

A short answer to your question is yes, OLT PMA is expected to lose
sync between bursts, and regain it at the beginning of each new
burst. The real lacuna is that we are expecting legacy PMA devices
to sync quickly.

In the optics track meeting in Vancouver, we touched on this topic.
See slide 7, "Report of the Optical PMD STF", at
http://www.ieee802.org/3/efm/public/jul02/optics/index.html

Shawn Rogers (s-rogers@xxxxxx) has kindly agreed to coordinate more
work on this topic for the next meeting. I expect more discussions
on this topic on the P2P reflector soon.

We phrased the question differently: What is the sync acquisition
time of an OLT-end PMA, as it receives a new burst from an ONU? The
absence of light (guard band) following the previous burst will
cause OLT PMA to lose sync. So how soon will it reacquire sync?

Well, that depends on the PMA design, of course. This brings up the
first twist of this plot. Will a P2MP switch likely use a new PMA
design or will it likely use legacy PMA devices? Someone suggested
that for legacy devices, the lock acquisition time is of the order
of 1 microsecond (1024 bits).

That's too much! For ~90% efficiency, our entire burst mode timing
budget is ~1 microsecond. That needs to be divided between laser
turn-on and turn-off time, optical receiver recovery time, OLT PMA
sync acquisition time and some margin. (To be fair to PMA designers,
P2P links never had a design goal of quick sync. In fact, to reduce
cost, many adopted a digital implementation which trades sync time
for other benefits.)

The second twist of this plot may come if we agree that indeed,
legacy devices take too long to acquire sync, and that we will have
to specify an improved sync time parameter. Sigh, this would mean
revisiting clause 36.

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 Ben Brown
> Sent: Tuesday, July 23, 2002 11:33 AM
> To: Vipul_Bhatt@xxxxxxxx
> Cc: Hugh Barrass; Kevin Daines; stds-802-3-efm-oam@ieee.org;
> ambraga@xxxxxxxxxxx; tjackson@xxxxxxxxxxxx; dromasca@xxxxxxxxx;
> don.alderrou@xxxxxxxxx; arnoldb@xxxxxxxxx; fkaudel@xxxxxxxxxxxxxx;
> David_Law@xxxxxxxxxxxx; robert.muir@xxxxxxxxx;
> bob.barrett@xxxxxxxxxxxxxxxxxx; hkaplan@xxxxxxxxx;
> stds-802-3-efm@ieee.org
> Subject: [EFM] Re: [EFM-OAM] New update on EFM OAM Work Item #3
>
>
>
>
> Vipul,
>
> This question is slightly off topic. This is why I've opened it up
> to the wider EFM audience.
>
> In EPON, there are multiple ONU's sending data up to a
> 1000BASE-X OLT.
> Each ONU transmits for a few microseconds each. Is there
> a guarantee
> that the OLT won't lose sync with the 8B/10B commas when
> ONU's switch
> in and out? Is it expected that the OLT will lose and
> regain sync with
> each ONU switch over?
>
> Perhaps this is well understood and you can simply point me to a
> presentation that describes this process.
>
> Regards,
> Ben
>
> Vipul Bhatt wrote:
> >
> > Ben,
> >
> > I am sure MAC Control at OLT end knows at each moment
> which ONU is
> > talking. But I am worried that if it has just one PCS
> error counter
> > to read from, it won't be able to discern useful
> information from
> > it. Error rates need averaging over several seconds to become a
> > stable value. With ONUs taking turns to transmit, each
> one for a few
> > microseconds, it will be difficult to get a reliable
> indication of
> > error rate of an individual link.
> >
> > I will request some P2MP colleagues to answer your
> questions better.
> > Like Hugh, I am tempted to crawl back to my photonic cave...
> >
> > Vipul
> >
> > ================
> >
> > > -----Original Message-----
> > > From: owner-stds-802-3-efm-oam@majordomo.ieee.org
> > > [mailto:owner-stds-802-3-efm-oam@majordomo.ieee.org]On
> > > Behalf Of Ben
> > > Brown
> > > Sent: Tuesday, July 23, 2002 7:24 AM
> > > To: Hugh Barrass
> > > Cc: Vipul_Bhatt@xxxxxxxx; Kevin Daines;
> > > stds-802-3-efm-oam@ieee.org;
> > > ambraga@xxxxxxxxxxx; tjackson@xxxxxxxxxxxx;
> dromasca@xxxxxxxxx;
> > > don.alderrou@xxxxxxxxx; arnoldb@xxxxxxxxx;
> fkaudel@xxxxxxxxxxxxxx;
> > > David_Law@xxxxxxxxxxxx; robert.muir@xxxxxxxxx;
> > > bob.barrett@xxxxxxxxxxxxxxxxxx; hkaplan@xxxxxxxxx
> > > Subject: Re: [EFM-OAM] New update on EFM OAM Work Item #3
> > >
> > >
> > >
> > >
> > > Hugh, Vipul,
> > >
> > > Is there information at that layer in the OLT to know when
> > > data is coming from a particular ONU? This would be necessary
> > > to keep separate counters. If this is the case, what is the
> > > purpose of the LLID? If the physical layer knows which ONU
> > > is providing the information, doesn't the MAC layer also know?
> > >
> > > Regards,
> > > Ben
> > >
> > > Hugh Barrass wrote:
> > > >
> > > > Vipul,
> > > >
> > > > I hate to say this, but the complex option may be required:
> > > >
> > > > If we assume that the FEC is implemented, it will be
> > > important to have FEC
> > > > corrected (and uncorrected) error counts at the OLT for
> > > each ONU. This will
> > > > allow an operator to debug problems with ONU lasers or
> > > fiber - either common or
> > > > separate sections.
> > > >
> > > > I think this will map to the virtual point-to-point concept.
> > > >
> > > > Hugh.
> > > >
> > > > Vipul Bhatt wrote:
> > > >
> > > > > Ben,
> > > > >
> > > > > Perhaps you or others have thought about this, and
> > > can comment.
> > > > >
> > > > > In a PON (1000BASE-PX), the medium is shared. The
> > > link quality may
> > > > > differ from ONU to ONU, but the OLT receiver will be
> > > common. So will
> > > > > we need multiple counters per OLT PMD?
> > > > >
> > > > > If yes, then it will be tricky to implement such
> > > counters because
> > > > > each "link" is established only for a few
> > > microseconds.  If not,
> > > > > then it raises a question of how useful such an
> > > overall counter is.
> > > > > I agree it is better than nothing.
> > > > >
> > > > > Also, I wonder if it is appropriate to call the
> > > 1000BASE-X proposed
> > > > > counter as "coding violation counter" if we adopt an
> > > FEC option.
> > > > > (Maybe it is a legitimate black box view - the
> > > PMD/PMA will see an
> > > > > error rate of 10^-4, the FEC will clean it up to
> > > 10^-12, and then
> > > > > whichever bit it misses to correct will lead to, by
> > > definition, a
> > > > > code violation error.)
> > > > >
> > > > > And finally, if we do insert an FEC sublayer below
> > > PCS, we will be
> > > > > one level removed from the original intention behind
> > > counting code
> > > > > violation errors - to monitor the health of the
> > > optical link. If we
> > > > > want to monitor the status of an optical link, we may
> > > need another
> > > > > counter that reports errors at the FEC-PMA interface.
> > > Updating this
> > > > > counter can be the responsibility of the (optional) FEC
> > > > > implementation.
> > > > >
> > > > > Regards,
> > > > > Vipul
> > > > >
> > > > > ===================
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-stds-802-3-efm-oam@majordomo.ieee.org
> > > > > > [mailto:owner-stds-802-3-efm-oam@majordomo.ieee.org]On
> > > > > > Behalf Of Ben
> > > > > > Brown
> > > > > > Sent: Monday, July 22, 2002 1:04 PM
> > > > > > To: Kevin Daines
> > > > > > Cc: stds-802-3-efm-oam@ieee.org; ambraga@iol.unh.edu;
> > > > > > tjackson@xxxxxxxxxxxx; dromasca@xxxxxxxxx;
> > > don.alderrou@xxxxxxxxx;
> > > > > > arnoldb@xxxxxxxxx; fkaudel@xxxxxxxxxxxxxx;
> > > David_Law@xxxxxxxxxxxx;
> > > > > > robert.muir@xxxxxxxxx; bob.barrett@xxxxxxxxxxxxxxxxxx;
> > > > > > hkaplan@xxxxxxxxx
> > > > > > Subject: [EFM-OAM] New update on EFM OAM Work Item #3
> > > > > >
> > > > > >
> > > > > >
> > > > > > All,
> > > > > >
> > > > > > Attached is an updated presentation regarding work
> > > item #3. Please
> > > > > > review and provide comments.
> > > > > >
> > > > > > David,
> > > > > >
> > > > > > Let me know what I need to do for the MAU attribute
> > > that you said
> > > > > > we need.
> > > > > >
> > > > > > Regards,
> > > > > > Ben
> > > > > >
> > > > > > --
> > > > > > -----------------------------------------
> > > > > > Benjamin Brown
> > > > > > AMCC
> > > > > > 2 Commerce Park West
> > > > > > Suite 104
> > > > > > Bedford NH 03110
> > > > > > 603-641-9837 - Work
> > > > > > 603-491-0296 - Cell
> > > > > > 603-626-7455 - Fax
> > > > > > 603-798-4115 - Home Office
> > > > > > bbrown@xxxxxxxx
> > > > > > -----------------------------------------
> > >
> > >
> > > --
> > > -----------------------------------------
> > > Benjamin Brown
> > > AMCC
> > > 2 Commerce Park West
> > > Suite 104
> > > Bedford NH 03110
> > > 603-641-9837 - Work
> > > 603-491-0296 - Cell
> > > 603-626-7455 - Fax
> > > 603-798-4115 - Home Office
> > > bbrown@xxxxxxxx
> > > -----------------------------------------
>
>
> --
> -----------------------------------------
> Benjamin Brown
> AMCC
> 2 Commerce Park West
> Suite 104
> Bedford NH 03110
> 603-641-9837 - Work
> 603-491-0296 - Cell
> 603-626-7455 - Fax
> 603-798-4115 - Home Office
> bbrown@xxxxxxxx
> -----------------------------------------