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

["Ben Brown" <bbrown@xxxxxxxx>]

Vipul,

Thanks for the info. When you're performing this calculation,
don't forget the Clause 36 sync machine takes something more
than 0 time to sync up to the K28.5 commas.

Also, this PHY doesn't want to report a failed link status
every time it switches between ONUs. There needs to be a timeout
value or something that only reports a failed link if it doesn't
resync for an enabled ONU. This affects how the OAM Remote Fault
is reported. We'll need to stay in touch with this discussion.

Regards,
Ben

Vipul Bhatt wrote:
> 
> 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
> > -----------------------------------------


-- 
-----------------------------------------
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
-----------------------------------------