RE: [EFM] RE: OAM Transport Proposal
Hi David,
Thank you for your response. I guess mostly we are in unison, for
which we are not, my thinking is in line comments.
Thanks,
Sanjeev
At 12:46 PM 05/06/2002 +0100, David Law wrote:
>>>Hi Sanjeev,
>>>
>>>I would just like to point out that I would be concerned with simply
>increasing
>>>the clock speed of MDC/MDIO interface on EFM PHYs to 50MHz, or more, as this
>>>would make this new MDC/MDIO interface incompatible with the existing Clause
>22
>>>and Clause 45 MDC/MDIO interfaces. Of course that will be fine if all the
>>>devices on the MDC/MDIO interface were EFM PHYs with this new high speed
>>>MDC/MDIO interface. However if the system also supported existing PHYs there
>may
>>>be an issue if the implementer wanted to have just a single MDC/MDIO master.
>>>
>>
>>SM:-I could understand your concern and this concerns is good one. But may I
>ask
>>you, are the Clauses are written to create technology or technology is created
>to
>>serve Clauses. This is because if anything I bump into this compatibility with
>>Clauses is put on my face. How hard it is for MDIO master to say use the 2.5
>Mhz
>>clock if it is accessing a slower MDIO space device and use 25Mhz/50Mhz
>>(or whatever) if it is accessing faster MDIO space devices. Here the
>specification
>>is for the MDIO interface not for MDIO master. Just specify the higher speed
>>MDIO, let the MDIO master designers to solve this accessing slower and faster
>>devices problem. Don't we do something like this with changing the clocks for
>>10/100/1000Mbps MII/GMII interface. Same device three different speeds.
>>
>
>DL:- If I understand correctly, what you are proposing here is that when the
>Station Management Entity (STA) accesses a 2.5MHz capable device it would clock
>the Management Data Clock (MDC) at 2.5MHz and when the STA accesses a 50MHz
>capable device it would clock MDC at 50MHz. Now as I am sure you are aware MDC
>is a multidrop bus connected to all the PHYs (For others that are interested see
>http://www.ieee802.org/3/efm/public/sep01/turner_1_0901.pdf : Slide 5) and
>sourced by the STA. Hence I believe that this approach would clock a 2.5MHz
>devices with a 50MHz clock while an access to a 50MHz device was occurring. Now
>a device determines if it is or is not being accessed by monitoring the start of
>frame (ST) and address (PHYADR, DEVTYPE) bits presented on the Management Data
>Input/Output (MDIO) clocked by MDC so even when not being accessed the 2.5MHz
>device still has to decode the MDIO signal correctly based on the MDC clock.
>Hence I would personally be unhappy with such an approach as it requires a
>device specified for operation at a maximum clock rate of 2.5MHz to be clocked
>at 50MHz and still behave correctly. I believe that this issue doesn't occur on
>10/100/1000Mbps MII/GMII interfaces are they are point to point interfaces and
>not a multidrop bus as the MDC/MDIO interface is.
SM:-Yes, I guess even first time around this is what you had meant. First of all MDIO
interface is in one's box, so it is "in box" design issue only not an exposed interface
compatibility issue that makes it a bit easier. Now since it is in box, one knows
what MDIO interface devices it is going to use. Lets say one that runs at 2.5Mhz
and other could go upto 50Mhz. Solution one, it could have two clock signals and
one MDIO signal. Both 50Mhz and 2.5Mhz come from same source and are in
same phase. Connect 50Mhz clock to faster MDIO device and 2.5Mhz to slower device.
If you are still unhappy with this then the MDIO master could have separate MDIO/MDC
connections externally and combine internal to master device to make it as one interface.
And this is till every PHY moves to higher speed which would happen very fast.
>
>As far as Clause compatibility is concerned my opinion was that it would be
>desirable for EFM to maintain some level of compatibility with the existing
>MDC/MDIO specifications and that others may also have that desire. Of course
>that was all it was, just my opinion, the consensus of the group (without
>getting into project scope issues) may or may not be the same.
>
SM:-I understand the compatability issues and if reasonable then it is very good thing.
But think about in a 10G system you have got a 312 mhz clock. Now either
source a separate 2.5Mhz clock or keep dividing 312Mhz till you get 2.5mz
(a long division). And one does all this for what? To get a slower access to
PHY devices in a systen that almost runs at Ghz. I would also prefer to avoid
these "scope issues" and not get in them and let people decide. So is just my
humble opinion.
>
>>>Now I guess we could provide the option whereby the devices on the MDC/MDIO
>bus
>>>could be polled to see what MDC/MDIO speeds they supported, then run the
>>>MDC/MDIO interface at the lowest speed reported. The issue with that would of
>>>course be that the response time specifications would have to be based on the
>>>worse case situation which is when the slowest device was a legacy device -
>and
>>>then we would end up back where we started.
>>>
>>
>>SM:-This is one of the solutions and could be better solutions to deal with it
>>so that we don't get where we started.
>>
>>>Regardless, I think the biggest issue with response time and the MDC/MDIO
>>>interface is not its speed of operation of the MDC/MDIO interface, but the
>delay
>>>that we would have to allocate in the response time specification for the
>>>Management Entity software response time. The software has to poll the
>>>information from the PHY through the MDC/MDIO interface then write it into the
>>>RS - and there may be other task of higher priority for this software to
>>>perform.
>>
>>Regarding the response time, specify it within some bound and let the system
>>designer decide and prioritize its task that what is important for it. Yes, the
>MDIO
>>speed does play role in the total time required to respond to an event (time
>required
>>to poll + time required to process + time required to get back to the PHY
>device if
>>need be).
>>
>
>DL:- Totally agree with you analysis, my only concern was that once the group
>comes to a consensus worse case value for the software response time it will
>become a large value. We however seem to be agreeing that a viable alternative
>is changes to the service interfaces (see recent e-mail chain between Rich and
>Brad).
>
>
>>>I therefore think a better alternative to this would be the changes to
>>>the service interfaces to provide fault and alarm conditions as recently
>>>mentioned by Rich.
>>>
>>>
>>>SM:-I am not averse to viable alternatives.
>>
>>
>>>Regards,
>>> David Law
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>Sanjeev Mahalawat <sanjeev@xxxxxxxxx> on 03/05/2002 02:38:09
>>
>>Sent by: Sanjeev Mahalawat <sanjeev@xxxxxxxxx>
>>
>>
>>To: "Booth, Bradley" <bradley.booth@intel.com>, "'stds-802-3-efm @ieee.org'"
>> <stds-802-3-efm@ieee.org>
>>cc: (David Law/GB/3Com)
>>Subject: RE: [EFM] RE: OAM Transport Proposal
>>
>>
>>
>>
>>
>>Comment are in line...
>>
>>Thanks,
>>Sanjeev
>>
>>At 02:54 PM 05/02/2002 -0700, Booth, Bradley wrote:
>>>
>>>Sanjeev,
>>>
>>>I'd recommend you look at the diagrams in 802.3 again.
>>>There is a distinct
>>>line from the top of the RS that indicates that it is considered part of the
>>>PHY.
>>
>>SM:-With your recommendation if I look at the diagrams, it reminds me
>>those fine print adds and when I bump into those the provider
>>of those adds recommends me to look at them. :)
>>Anyway, if I look at these figures there are two parallel stacks with
>>one with OSI Reference on top and the other with LAN CSMA/CD
>>Layers on top. The last box of OSI stack called "Physical" has
>>very fine dotted lines covering RS. But when I look at the LAN CSMA/CD
>>stack there is word "PHY" that with solid line brace includes only
>>PCS, PMA and PMD layers and does not include RS. What do you believe?
>>"Physical" with fine dotted lines or "PHY" with solid line brace? OK, one could
>>say if you mention OSI believe "Physical" and if you mention LAN CSMA/CD
>>believe "PHY".
>>I had thought all along the discussion is about "PHY" (abbreviation for
>>Physical Layer Device) not "Physical" because "PHY" the word everyone
>>is referring including current exchanges. And also this is under LAN CSMA/CD
>>layer stack and so that is more relevant here. Therefore, I still think that
>>purpose of
>>RS is not to be with "PHY" but be with MAC in order for MAC to connect to
>>different "PHY"s with different standard interconnects in LAN CSMA/CD stack.
>>And make MAC behave in media independent way.
>>
>>>In the past, the RS has been transparent (state-less) with the only
>>>function of mapping from the media independent interface to the MAC serial
>>>bit streams.
>>
>>SM:-But there is no restriction to make it stateful. Is there any?
>>
>>>By the way, the MAC service interface is at the top of the
>>>MAC, not at the bottom.
>>>
>>
>>SM:-I am not sure what are you referring here. If you are infereing from
>>my reference of interface between RS and MAC then I guess you
>>mis-interpreted it. Here what I meant was the service primitive between
>>MAC and RS which RS uses to service the MAC.
>>
>>>Correct, preamble is a relic of our past. And in the past, we abused
>>>preamble and wrote the standard to permit shortening preamble, etc. You'd
>>>have to completely change how preamble is treated to make it something we
>>>can use reliably.
>>
>>SM:-I am not sure if it needs to be completely changed but yes, modifications
>>needs
>>to be made and could be made.
>>
>>>Are you proposing defining a new 100BASE-TX-like or 1000BASE-X-like PHY that
>>>is compatible with what is currently written in the 802.3? If you are, then
>>>your assumption about being "tasked to define new PHYs" is completely
>>>off-base.
>>
>>SM:-You completely mis-interpreted what I said. Let me say little explicitly,
>>802.3ah is most probably developing new copper and fiber PHYs those
>>will not be compatible with the existing PHYs those run at the same
>>speed for the corresponding medium. Is it not the case? If it is, then
>>those could be specified to guarantee the passing the whole preamble
>>to RS.
>>
>>>802.3 prefers not having nearly identical PHYs with slightly
>>>different variations depending on OAMinP functionality. That just won't
>>>fly. If you want to be able to use existing PHYs, you have to be prepared
>>>to modify them in such a manner that you don't break how they currently work
>>>while adding in your required features.
>>
>>SM:-This was not my intent but since you have mentioned I would comment little
>>explicitly that changing current relevant PHYs like 1000Base-X (which is more
>>relevant here) to not change the preamble size does not break neither
>>implementations
>>nor specifications. I would ask for a favour to point me out in standard which
>>says
>>in 1000Base-X the PCS at TX should shrink the preamble to meet even-odd
>>alignment.
>>This is not for rhetoric, I have not come across this in the spec therefore
>>asking.
>>The 8-byte preamble is sub-set of a functionality that could handle shrinked
>>preambles would surely could handle full 8-byte preamble, later is the easier
>>case.
>>There is nothing here I want to make fly.
>>
>>>By how to specify a reaction time, I meant that if you have to rely on using
>>>a management interface such as MDIO/MDC, you have no control over the time
>>>limit.
>>
>>SM:-There are two components of this whole fast link management. One is fast
>>notification to destination and fast action on these notification at
>destination
>>to repair the problem and minimize the damage.
>>Once acted/repaired on these notification the second part is to report to the
>>management
>>entity about it. The first part is time critical the second part is not so.
>>
>>SM:-But I have to say that this MDC/MDIO is a good shot in the arms of the
>>people those
>>want to use it when needed. :). As the link speeds are testing the physical
>>limits
>>but the management entity interface speed of these links some how manages to be
>>in previous
>>century. :)
>>
>>>Clause 28 and 37 use triggers to indicate when registers have been
>>>updated for next page exchanges because we don't know how long it will take
>>>the management entity to respond.
>>
>>SM:-Give you an example, increase the clock speed of MDC/MDIO interface
>>to 50Mhz if not more. It will decrease the latency and specify that management
>>entity polls this register within 10ms and acts upon within 20ms.
>>
>>
>>>We need to figure out how to specify and
>>>where to specify OAMinP, because it is can cause a lot of problems if not
>>>done correctly.
>>
>>SM:-Yes, it is important to make sure that things are done correctly specially
>>when one is dealing with specification like 802.3.
>>
>>>OAMinF is much simpler in this manner as it doesn't change
>>>the fundamental way Ethernet works, but OAMinP does, so it needs to be
>>>better defined so we don't break the existing standard.
>>>
>>
>>SM:-There no contest to this comment of yours that if something could be
>>solved in simple manner sure no need to make it complex. But what is
>>simple is also the one of points of the debate. Each coin has two sides.
>>
>>SM:-Not that not shrinking preamble necessarily breaks anything,
>>I do not believe all these statements like "doing in frames does not
>>break existing standard". I wish the frame world is that simple slam dunk.
>>
>>
>>>
>>>Brad Booth
>>>IEEE P802.3ae Editor-in-Chief
>>>bradley.booth@xxxxxxxxx <mailto:bradley.booth@xxxxxxxxx>
>>>
>>> -----Original Message-----
>>> From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
>>> Sent: Thursday, May 02, 2002 3:44 PM
>>> To: Booth, Bradley; 'stds-802-3-efm@ieee.org'
>>> Subject: RE: [EFM] RE: OAM Transport Proposal
>>>
>>>
>>> If one looks at the 802.3 ISO Open Systems Interconnection
>>> (OSI) reference model specification RS is not seem to be
>>>part of PHY.
>>> RS is specified to be always a layer between MAC and PHY
>>>adapting
>>> to different PHY interfaces and mapping these various PHYs
>>>(which are
>>> completely different depending upon the underlying medium)
>>>interfaces
>>> (MII/GMII/XGMII/...) to MAC service interface. And these
>>>media independent
>>> interfaces are the only defined interconnects between PHYs
>>>and RS; there is
>>> no electrical interconnect defined between RS and MAC. RS
>>>serves MAC
>>> only through a service interface. Therefore, it may not be
>>>correct to say that
>>> RS is part of PHY.
>>>
>>> I agree with that not all current PHYs guarantee to pass all
>>>the preamble bytes
>>> to RS, because all the PHYs are optimally designed for a
>>>particular medium therefore used
>>> preamble for its own purpose because it was "unused" for
>>>their application and they could
>>> made use of it (1000Base-X for even-odd alignment at TX,
>>>1000Base-T for two SOPs,
>>> 100Base-T4 SOSA, SOSB, so on..). All these usage are
>>>deviation from the original
>>> purpose of the 010101.. sequence preamble designed to use
>>>for clock synchronization
>>> needed for mediums which have no carrier when there is no
>>>frame data. So, after all
>>> preamble is not so sacred.
>>>
>>> Since 802.3ah is tasked to define new PHYs so I do not see
>>>why a PHY can not be defined
>>> to guarantee to pass a complete preamble to RS and don't see
>>>why specifying so for a PHY
>>> would break 802.3 spec. Correct me if I am wrong, it is not
>>>expected for 802.3ah 1000Mbps
>>> PHY to be compatible with 1000Base-X PHY or 100Mbps copper
>>>PHY to be compatible
>>> with 100Base-T PHY. So, if that is not the case what is the
>>>big issue here?
>>>
>>> True that the action and reaction for OAM is not defined
>>>(regardless of transport mechanism),
>>> and needs to be defined once it gets to its destination. But
>>>how to specify is not seem to be
>>> a correct question to pose. Is it that difficult to say that
>>>if in 10ms if RS gets more than 4 RFIs
>>> disable the transmit and set register x.x.x bit y.
>>>
>>> Though having said all above if introducing a new sub-layer
>>>for OAM in PHY makes it easy to
>>> make implementations flexible, standard and inter operable
>>>it could be a good approach too.
>>> Although having it in RS could control the MAC operation
>>>quicker, if need be.
>>>
>>> Thanks,
>>> Sanjeev
>>>
>>> At 08:31 AM 05/02/2002 -0700, Booth, Bradley wrote:
>>> >
>>> >Comments below.
>>> >
>>> >Thanks,
>>> >Brad
>>> >
>>> > -----Original Message-----
>>> > From: Sanjeev Mahalawat
>>>[mailto:sanjeev@xxxxxxxxx]
>>> > Sent: Wednesday, May 01, 2002 5:16 PM
>>> > To: Booth, Bradley;
>>>'stds-802-3-efm@ieee.org'
>>> > Subject: 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.
>>> >
>>> >BJB> The TBI is specified between the PMA and PCS, and is
>>>an optional
>>> >instantiation of the PMA service interface. The standard
>>>only specifies a
>>> >management interface (MDIO/MDC) for the PHY. In this case,
>>>the PCS and AN
>>> >(auto-negotiation) portions of the PHY are the only
>>>sublayers that require
>>> >management interaction. The problem is you keep mentioning
>>>ways that this
>>> >can be implemented. I fully understand all the possible
>>>ways to implement
>>> >this, but the standard is written with specific boundaries
>>>and interactions
>>> >across those boundaries to permit a wide range of
>>>implementations. Yes,
>>> >when all things are integrated, a common management
>>>interface could be used,
>>> >but that is assuming that all things are integrated. You
>>>may choose to do
>>> >it that way; whereas, someone else may not. We cannot
>>>write the standard
>>> >based on your implementation or someone else's, we can only
>>>write it in a
>>> >way that permits everyone to implement it however they
>>>wish, as long as they
>>> >are compliant with the standard.
>>> >
>>> >
>>> > 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.
>>> >
>>> >BJB> The pointer to the fact that AN is in the PHY is not
>>>in Clause 37. It
>>> >is in Clause 34 (34.1.2, third paragraph to be exact).
>>> >
>>> > >
>>> > >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.
>>> >
>>> >BJB> By the OSI reference model that we use throughout
>>>802.3, the RS is part
>>> >of the PHY.
>>> >
>>> >
>>> > >
>>> > >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).
>>> >
>>> >BJB> I mistyped and the "and" should have an "or". Yes,
>>>the RS can
>>> >communicate with the management entity, and this is a
>>>viable way of having
>>> >the management handle alarms, etc. There are a couple of
>>>issues related to
>>> >getting the full preamble passed to the RS (as this is not
>>>required in
>>> >802.3) and with the fact that we cannot assume that the
>>>interface to the RS
>>> >is any better or faster than the management interface (via
>>>MDIO/MDC) to the
>>> >PHY. In other words, how do you get the preamble to the RS
>>>and how do you
>>> >specify a reaction time?
>>> >
>>> > > 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.
>>> >
>>> >BJB> In 10GbE, the PHY doesn't give reasons for the RF as
>>>it is the remote
>>> >terminals problem and needs to be solved by the remote
>>>terminal.
>>> >
>>> > >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.
>>> >
>>> >BJB> There are a number of issues that need to be
>>>addressed. Some are
>>> >easier than others. Things that require modifications to
>>>the current
>>> >behaviour of 802.3, I would consider very major changes. I
>>>know that the
>>> >original proposal had the handling of OAMinP in the RS, but
>>>the passing of
>>> >preamble to the RS is not guaranteed. If the OAMinP is
>>>handled in the PHY
>>> >like AN, then the proposal has to specify how that new
>>>sublayer would react
>>> >to alarms and indications so that interaction with the
>>>management entity
>>> >would be minimized. I believe that these details are very
>>>important to iron
>>> >out because they will help us specify something that can be
>>>implemented by
>>> >everyone and that can be interoperable.
>>> >
>>> > 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
>>> > > >
>>> > >
>>> >
>>>
>>
>