RE: [EFM] RE: OAM Transport Proposal
At 12:01 PM 05/01/2002 -0700, Booth, Bradley wrote:
>
>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.
There is nothing implementation specific here and is all standard.
There is Ten Bit Interface specified between PMD part of the PHY
and PCS. The PCS implementation could be with MAC (embedded GMII)
or outside MAC (exposed GMII). There is management interface for
all the sub-layers MAC, RS, PCS and PMD. But when things are
integrated common management interfaces could be used. As in case
PCS and Auto-negotiation are integrated with MAC they share the MAC
management interface. So, is when RS and MAC are integrated they
share the same management interface.
By the way I could not find anywhere in Clause 37 that specifically
says Auto-negotiation must be in PHY, I must be missing something here.
>
>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.
>
I dont think local PHY has any idea about why a RF came from the remote station.
It has no idea that the receive side laser of the remote partner is broken and
I dont think PHY interprets RFs. Only RS interprets and terminates RFs.
Correct me if I am wrong. And this is being brought only to draw a parallel, though
RF/LF are 10GE specific.
>
>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.
I disagree with that there is no way for RS to communicate with management entity.
As far as acting on alarms is concerned it could be as simple as disable the
transmit to just pass the information to management entity and both are possible
(could be more complicated if wished).
> 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.
PHY could give reasons for LF but can not for RFs.
>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.
>h
Agree here and more work needs to be done and presented.
But the level of details for OAM, its bits and behavior, its state-machines etc..
are not specific to how they are transported. In my opinion, these could be separate
issues but you may be right here. Like Auto-negotiation state-machines (which could be
impelmented in PHY as well as in management entity) where these are implemented could be
argued.
Thanks,
Sanjeev
>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
> >
>