RE: [EFM] RE: OAM Transport Proposal
In 1000BASE-X, the PCS/Auto-negotiation is always part of the PHY. If you
implement it in a MAC device, then that portion of the PHY logic is in the
MAC device. You cannot assume that everyone will implement the management
and service interfaces in the same manner. 802.3 does not specify
implementations; 802.3 specifies what characteristics must be exhibited by a
conformant device. How that conformant device is build and sublayers are
partitioned is implementation specific.
As for RF/LF, those only exist in 10GbE which uses ordered sets inserted
into the IPG. The RF is generated based upon LF input, but the
determination of the cause of LF must be determined via the management
interface to the PHY sublayers.
You're misinterpreting "broken". Broken is having OAMinP that either has no
way of acting on alarms or indications, and has no way of communicating with
a management entity to perform these functions. RF/LF uses a state diagram
to react to incoming LFs and generate RFs. Because this is performed in the
RS, the function is considered to have pervasive communication with the
management entity. If the management entity wishes to diagnose the cause of
the LF, it uses the management interface to the PHY to perform this
function. These functions have no time dependence on their occurrence.
Auto-negotiation works in almost a similar way, the parameters are passed to
the PHY, the auto-negotiation state machine handles the communication and
exchange of data (sometimes with management entity involvement), and when
it's done, makes the information available to the management entity. I
don't see this level of detail being provided for OAMinP while also
addressing the other concerns related to using preamble. Can this be done?
Sure, but the current OAMinP proposal needs a lot of modifications to make
it viable for specifying in 802.3.
Cheers,
Brad
-----Original Message-----
From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
Sent: Wednesday, May 01, 2002 11:47 AM
To: Booth, Bradley; 'stds-802-3-efm@ieee.org'
Subject: RE: [EFM] RE: OAM Transport Proposal
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
>