Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] [EFM-OAM] OAM Transport Proposal


> > > An implementer can do the same with the 108 bytes of the frame payload that
> > > Hiroshi's presentation did with the EOC, or the ITU-T xDSL standards do
> > > with the EOC.  There is absolutely nothing that can be done with OAMiP that
> > > can not be done with OAMiF.
> >
> >Agreed. However, OAMinP does it at the right level, in hardware,
> >efficiently, with no impact on customer bandwidth (wasn't this one of
> >your more prominent platforms recently).
> Doing it in hardware is good thing if it the return on investment is worth
> it.  Adding new hardware is not always cost effective.  In today's market,
> and for the next few years, keeping it cost effective is the name of the
> game.  The time response delta between OAMiP and OAMiF is minimal since
> both can react with alarm information faster than 125us.

[RT] Agreed again. However, other factors such as new process
technology, higher levels of component integration, other EFM changes,
feature support for new applications (i.e. Ethernet access) will likely
provide the ROI most component vendors are looking for. OAMinF can only
provide ballpark performance to OAMinP if it's in hardware. However,
this violates your "change" rule and makes the hardware unnecessarily
complex (e.g. 128-byte frames to send a bit of fault/alarm information). 

Best Regards,
Richard Taborek Sr.                     Intel Corporation
XAUI Sherpa                    Intel Communications Group
3101 Jay Street, Suite 110    Optical Strategic Marketing
Santa Clara, CA 95054           Santa Clara Design Center
408-496-3423                                     JAY1-101
Cell: 408-832-3957          mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783