Re: [EFM] RE: OAM Transport Proposal
Brad,
Great! One issue solved. As for where it resides. The implementation is
clear, the documentation of architecture in order not to restrict
implementations should not be too difficult. If clear documentation is
our biggest concern, then we're over the hump already.
Best Regards,
Rich
--
"Booth, Bradley" wrote:
>
> Rich,
>
> Something like that. If a service interface is required for OAMinF, then it
> should be clearly stated and specified in the baseline proposal. The same
> would apply for OAMinP. My concern with OAMinP is where it resides and what
> level of changes to 802.3 are required.
>
> Thanks,
> Brad
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Thursday, May 02, 2002 7:38 PM
> Cc: 'stds-802-3-efm@ieee.org'
> Subject: Re: [EFM] RE: OAM Transport Proposal
>
> Brad,
>
> I agree that a service interface is probably required for
> fault and
> alarm conditions. This is covered under the following EFM
> objectives:
>
> Support far-end OAM for subscriber access networks:
> o Remote Failure Indication
> o Link Monitoring
>
> This objective, and the service interface is applicable to
> OAM in
> general and not specific to the transport (i.e. preamble or
> frame).
>
> I take it that you're requesting that this be clearly
> specified in the
> OAM Baseline for Edinburgh?
>
> Best Regards,
> Rich
>
> --
>
> "Booth, Bradley" wrote:
> >
> > Rich,
> >
> > This is the sticking point. 802.3 specifies service
> interfaces and a PHY
> > management interface. To assume that EFM is going to do
> any management of
> > the link without using either of these interfaces implies
> that the OAM must
> > be handled inside the PHY. If OAMinP is not handling its
> OAM messages
> > either in the PHY or via a service interface or PHY
> management interface,
> > then I think this is "broken" within the context of
> Ethernet.
> >
> > Cheers,
> > Brad
> >
> > -----Original Message-----
> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> > Sent: Tuesday, April 30, 2002 10:29 PM
> > Cc: 'stds-802-3-efm@ieee.org'
> > Subject: Re: [EFM] RE: OAM Transport Proposal
> >
> > Brad,
> >
> > The simple Fault and Alarm conditions that are
> expeditiously transported
> > via OAMinP should not utilize the relatively slow MDIO/MDC
> mechanisms.
> > The management entity for OAMinP is not significantly
> different than
> > that which carriers are used to for SONET OAM for handling
> the same
> > conditions. I believe that the specific management
> interface is out of
> > IEEE P802.3ah scope.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > "Booth, Bradley" wrote:
> > >
> > > Matt,
> > >
> > > A management frame I described is that defined in Clause
> 22 as a MDIO/MDC
> > > communication. If the preamble is filtered by the PHY,
> then there has to
> > be
> > > some way to pass this preamble OAM information to the
> management entity.
> > In
> > > 802.3, this is done via MDIO/MDC (or management frames).
> A management
> > frame
> > > takes over 25 us to be passed across the MDIO/MDC
> interface. Unless the
> > > intention is to have the PHY handle all OAM in preamble
> without management
> > > entity intervention, then the response to the OAM in
> preamble will be
> > > hampered by the MDIO/MDC interface.
> > >
> > > Cheers,
> > > Brad
---------------------------------------------------------
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