Re: [EFM] [EFM-OAM] OAM Transport Proposal
Rich,
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.
At the bit times rate of GbE, it would only take ~1.5us for a frame to send
out bit level alarms, so that argument is null and void. Channelization of
the P2P data stream is out of scope of 802.3ah, so that argument is null
and void. Managment of intermediate NEs can be done through the MCC/EOC in
the OAMiF payload, so that argument is null and void. OAMiP is inside the
Ethernet PHY encoding just like OAMiF so neither proposal will support
leased circuit Private Line standards, so that argument is null and void.
Thank you,
Roy Bynum
At 11:14 AM 5/2/2002 -0700, Rich Taborek wrote:
>Roy,
>
>Please elucidate your claim below. It makes absolutely sense to me so
>I'll have to discard it as baseless.
>
>Best Regards,
>Rich
>
>--
>
>Roy Bynum wrote:
> >
> > Sergiu,
> >
> > The use of OAMiF as a transport for an EOC per ITU-T standards will provide
> > support intermediate optical converters even better than OAMiP can. Please
> > take a look at the ITU xDSL standards files on the EFM web site.
> >
> > Thank you,
> > Roy Bynum
> >
> > At 04:33 PM 4/23/2002 -0700, Sergiu Rotenstein wrote:
> >
> > >All,
> > >
> > >I am sorry I am responding so late. I assume from the exchange of
> e-mails up
> > >to this date
> > >that my oppinions will be in minority.
> > >
> > >What I do not see in this proposal is the compromise.
> > >The main idea of the Suzuki preamble proposal was the support for non-MAC
> > >based
> > >optical ethernet termination units - sometimes called converters. These
> > >units
> > >are the most inexpensive form of deploying Ethernet based FTTH or Optical
> > >Ethernet.
> > >The intention of the preamble proposal was to support the link management
> > >for these
> > >type of units. These are widely deployed worldwide, and especially in
> Japan.
> > >And also
> > >this type of basic optical ethernet termination makes sense as a starting
> > >deployment
> > >point.
> > >
> > >As I see in slide 5, in order to determine the capabilities of each
> end unit
> > >a frame
> > >exchange needs to take place. If the CPE side is a converter, that
> normally
> > >does not
> > >have frame/MAC support, than there is no link management.
> > >
> > >I assume that this is what the customers - the service providers - had in
> > >mind.
> > >
> > >This is the essence of the proposal. The rest can be agreed through enough
> > >work and
> > >intelligence. But, by eliminating the basic idea of the Suzuki preamble
> > >proposal,
> > >we also eliminated the basic link management capabilities of a simple non
> > >MAC type
> > >Optical Ethernet Termination... To correct this, we can add a simple
> > >auto-sense capability
> > >based on preamble information transmission that will affect the link only
> > >when the
> > >link goes from down to up.
> > >
> > >Too bad that this is not on the agenda...
> > >
> > >Sergiu Rotenstein
> > >
> > > >>-----Original Message-----
> > > >>From: Kevin Daines [mailto:Kevin.Daines@xxxxxxxxxxxxxxxxxxxx]
> > > >>Sent: Friday, April 19, 2002 2:01 PM
> > > >>To: stds-802-3-efm@ieee.org
> > > >>Subject: [EFM] [EFM-OAM] OAM Transport Proposal
> > > >>
> > > >>
> > > >>All,
> > > >>
> > > >>A number of individuals have worked since the St. Louis
> > > >>Meeting in March on a compromise OAM Transport proposal. We
> > > >>are posting the proposal for review/comment from the larger
> > > >>802.3ah Task Force.
> > > >>
> > > >>
> > > >>
> > > >>Kevin Daines
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
> > >The information contained in this electronic mail is privileged and
> > >confidential, intended only for the use of the individual or entity named
> > >above. If the reader of this message is not the intended recipient,
> you are
> > >hereby notified that any dissemination, distribution, or copying of this
> > >communication is strictly prohibited. If you receive this communication in
> > >error, please immediately notify Disclaimer@xxxxxxxxxx Thank you.
>
>--
>
>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