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

RE: [EFM] RE: OAM Transport Proposal




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