RE: [EFM] RE: OAM Transport Proposal
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 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.
>
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. 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.
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.
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. 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>
>>>