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

Re: [EFM] RE: OAM Transport Proposal




Sanjeev,

non-EFM Ethernet is happy with its management/service interfaces as OAM
support is not required. This includes support of 1000BASE-X AN and
10GBASE RF/LF. Therefore, I'd say that non-EFM Ethernet is not broken.

EFM is different. EFM includes an objective to support OAM (see
objectives_1_0302.pdf). EFM needs to provide SONET OAM functional
equivalence as appropriate to Ethernet access applications (Roy, are you
OK with this wording?). The OAM Baseline proposal provides the OAM
transport. I agree with Brad that OAM requires additional management
service interface definitions and recommend their addition to the OAM
Baseline proposal.

Best Regards,
Rich
            
--

Sanjeev Mahalawat wrote:
> 
> Hi Brad,
> 
> For instance, what is the management/service interface defined in
> 1000Base-X when PCS/Auto-Negotiation part of PHY is not
> implemented in PHY but is with MAC. What is the management/service
> interface defined for RF/LF sequence terminating in RS?
> Is it broken within the context of Ethernet?
> 
> Thanks,
> Sanjeev
> 
> At 02:11 AM 05/01/2002 -0700, 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