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

["Ben Brown" <bbrown@xxxxxxxx>]

Jonathan,

Yes, you have exposed nearly all of the dangerous pitfalls that I
can think of for this protocol. Essentially, in a short period of
time, you are changing link partners. If the PMA knew when to
expect a change it might be able to take control of signal_detect
and force it off as soon as one ONU is done transmitting. This
helps get the PCS out of sync as soon as possible.

The turn on for the next ONU is the harder part. It works okay if
the next ONU is really there and sending a signal. Yes, the PMA
has its work cut out for it resyncing to the incoming signal in
a reasonable amount of time but let's assume this can be done.
If the next ONU isn't there for some reason but the PMD's
signal_detect is still hanging around and the PMA syncs up on
the crosstalk from the transmit side, we're going to get some
very bogus data.

I'm thinking that this will be a very interesting thread...

Regards,
Ben

Jonathan Thatcher wrote:
> 
> Ben, (removed OAM from distribution; seems general to P2MP, FEC, PMA and PMD)
> 
> Actually, this gets a little more interesting when FEC is added to the mix. Presuming that FEC does not muck with anything that will affect the K28.5 usage, there is still an issue regarding operation under a high BER environment.
> 
> Your point about time taken for the sync machine is interesting. This will have to be done at each ONU transition. The twist is that we may need to turn off auto-alignment on the PMA during the ONU transmission, to make sure that there is no accidental autoalignment (discussions also on-going about 7 bit vs. 10 bit detection, etc).  This means that there needs to be a state machine intelligent enough to tell the PMA when to turn alignment on and off efficiently.
> 
> The most efficient way that I can think of would be for a ONU to transmit a specific code-set at the end of its transmission, but prior to any possible collision with the next ONU. This would simultaneously kick the synchronization state machine into LOSS_OF_SYNC. Arguably, cgbad should take care of this. I just don't know how to know. Either way, I don't know of any logical connection between the SYNC states and EN_CEDT, which is not even a functionally required signal.
> 
> During the time that the bits are not coming down the wire, the SERDES will, most likely, still be generating data of dubious nature. It is unlikely that the PMDs will respond to the Signal_Detect in anything approximating real time. Or, there may be no way to detect this problem.
> 
> I don't know if there would be an issue with cross talk from the transmit side of the OLT confusing or faking out the PMA alignment or the PCS synchronization prior to the arrival of the next real signal from an ONU. This will require some thinking. Generally, this would not be an issue. Yet, there may be some corner cases that are problematic (example: ONU drops off creating a long gap on the OLT's incoming stream sufficient to actually have the OLT Rx lock onto the Tx, but still not long enough to be detected by the PMD's signal_detect. The probability of this is greater with an optic that transmits higher power and has significantly higher receive sensitivity).
> 
> Fun, eh?
> 
> jonathan
> 
> | -----Original Message-----
> | From: Ben Brown [mailto:bbrown@xxxxxxxx]
> | Sent: Tuesday, July 23, 2002 2:08 PM
> | 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: Re: [EFM] Re: [EFM-OAM] New update on EFM OAM Work Item #3
> |
> |
> |
> |
> | 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
> | -----------------------------------------
> |


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