RE: Proposal for accomodating 10.0000 and 9.58464 line rates
> Mick,
> Was it Socrates or Confucius that taught us that any function can be
> architected into IEEE 802 with an additional sub-layer?
While Socrates was a very intelligent guy, he really should have checked
up before choosing the hemlock... "Nobody TOLD ME that hemlock was poison!"
> Now seriously, neither scheme has an impact on the 802.1D forwarding
> implementation. The variable rate IPG is a lowly counter or two doing
> its thing at a very low level, as invisible to the forwarding function
> as the deferral process of 802.3.
How does the MAC know whether to implement the VR-IPG? Does it use this
for every PHY? If so, aren't we going to limit the throughput of a link
that COULD run at a full 10.0000 by this method?
And how do we implement it? Do we set it to ensure that the efficiency
of the PHY is totally accounted for in the various scenarios where there
are a lot of small packets to a single destination vs a lot of small
packets to multiple destinations, vs large packets?
I am not fully aware of the requirements of an OC-192 framer and how much
latency will be involved in processing header information for various
packet types, destinations, etc.
> The choice of spec'ing this at the MAC Client level is a convenience
> derived from the fact that the MAC layer has no queuing. We have
> already exploited that convenience for 802.3x, for example, to avoid
> having to source/sink XOFF frames at the heart of the MAC layer. I
> believe that Brad and Shimon will drive this subtlety again
> at the next
> meeting with the appropriate audiovisuals, and hopefully convince the
> group. (If that doesn't do it, we'll hire a couple of
> bouncers to drive
> the point beyond audiovisuals :) ).
>
>
> Jumping back to implementation, the HOLD signal presents two long term
> headaches:
>
> 1) The most scarce resource is pins, not gates. Do we really want to
> increase the number of per port pins?
We are talking about 1 pin. I agree that pins are valuable, but usually this
is an impact for multi-port designs where the number of ports is high and
cost
per port is sensitive to the $.01/port levels.
> 2) As soon as technology permits, implementations integrate the PCS
> coding layer, and eventually the clock recovery and transceiver. The
> MII ceases to be an exposed interface. For the mainstream MII
> functions
> like COLLISION (R.I.P.) and CARRIER SENSE, the event/encoding that
> defines the function is well defined at the PCS layer and there is no
> loss of functionality.
>
> How do I preserve the HOLD functionality for a hypothetical 10GbE
> MAC-PCS ASIC (with no MII) that I'll buy three years from now?
If your ASIC incorporates an OC-192 PHY, you will incorporate the flow
control inside your ASIC. In GbE, there is a different PCS for 1000BT than
for LX, SX or CX. If we end up with multiple PHYs, some of which run at
10.0000 and others that run at 9.58464, it is VERY unlikely that you will
want to integrate down to the PCS level any more than the likelihood that
we will be integrating 1000BT PCS into our MAC ASICs on GbE.
With all of this said, I am not really very religious about the METHOD
we use to support multiple PHY speeds. I proposed the "hold" signal as
a compromise proposal to move the standard forward and allow support for
10.0000 MAC/PLS interface with OC-192 compatible PHYs.
It appears that we have multiple methods for doing this available to us
now. Can we at least agree that a 10.0000 MAC/PLS has concensus now?
Thanks,
Dan Dove