Re: [EFM] [EFM-OAM] OAM Transport Proposal
Roy,
> > > 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,
Rich
---------------------------------------------------------
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 http://www.intel.com