RE: [EFM] RE: OAM Transport Proposal
Hi David,
Few in line comments, if help keep building unison. :)
Thanks,
Sanjeev
At 08:10 PM 05/06/2002 +0100, David Law wrote:
>
>
>Hi Sanjeev,
>
>As ever, thanks for you response, a few comments in line below. Hopefully they
>builds on the unison or at least don't remove any we already had ;-)
>
>Regards,
> David Law
>>>>>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.
>>
>
>DL:-I'm not too sure about the two clock approach since the 50MHz device may
>misinterpret the data intended for the 2.5MHz device it will clock off the
>shared MDIO. Maybe we could have the clocks gated so that one was off while data
>for the other speed device was present on the MDIO. Of course the two clocks,
>and the second separate MDC/MDIO, gets us back to having a system that is a
>special for EFM.
SM:-Passing comment on this.
>Hence I fundamentally see this as three choices, either define
>a new high speed MDC/MDIO for EFM only and base the response time specification
>on that, stick with the Clause 22 and Clause 45 MDC/MDIO and base the response
>time specification on them, or modify the various 100/1000Mb/s sublayer
>interfaces to pass the required information up to the RS in real time. The
>latter seems to be what is now proposed.
>
SM:-I agree with your categorization.
>In the IEEE P802.3ae 10Gb/s project a new MDC/MDIO (Clause 45) has been defined
>to expand the address space as the existing space was becoming exhausted.
>Despite this being a new Clause there was no increase in speed and the new
>MDC/MDIO defined by the 10Gb/s project is still specified to have a maximum
>operating speed of 2.5MHz.
SM:-My previous comment was just to point out that this interface is not keeping up
with rest of the system clocking (but can be argued as long as 10Mbps Ethernet lives).
>Fundamentally I believe that accessing information real-time is not what
>MDC/MDIO is really intended for as the software response time may be very slow
>regardless of the MDC/MDIO speed.
SM:-You have been pointing out good point regarding the software being bottle-neck
to process and respond to real-time physical link information to maintain healthy link.
And 802.3 like other physical link-level protocols is also not software/hardware blind.
>For example, as Rich mentioned in a recent
>e-mail, Local Fault in 10Gb/s is communicated through the symbol encoding on
>XAUI/XGMII to the RS, not through the MDC/MDIO. This ensure the LF/RF State
>Machine in the RS responds to the Local Fault in a timely fashion. Further
>information, such as which sublayer is generating the Local Fault, can be
>diagnosed at the software's leisure through the MDC/MDIO. I think this encoding
>analogous to the proposal to now modify the various 100/1000Mb/s sublayer
>interfaces to pass information up to the RS.
>
>>>
>>>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>
>>>>
>