RE: Proposal for accomodating 10.0000 and 9.58464 line rates
Dan:
I agree that it is possible to reduce the a 10.0000 G clock down to a
9.584640 G data rate using a variety of techniques.
Just to summarize I believe the solutions for achieving the 9.584640 G data
rate using a 10.0000 G clock so far discussed are:
1)802.3x used to stretching the IFGs
The 802.3x solution does not scale. It only works in a world where Ethernet
fails to command a significant portion of the WAN market and is therefore
limited to short links. I believe we can not choose this solution if we are
going to make Ethernet a real success in the WAN.
2)an IPG stretching shim located between the MAC and the MAC-Control layers
IPG shim solution has the problem that a WAN style PHY layer has no easy
way to control it since it is isolated from the PHY by the MAC.
3)IPG gap stretching based on the differing signal at the MAC/PLS boundary
Differing signal solution relies on CSMA/CD functions which are being
dropping from 10GigE.
4)an IPG HOLD signal at the MAC/PLS boundary
IPG HOLD solution provides an interface which does allow direct PHY control
of the data rate. This solution requires a PHY to buffer data while it
transmits 721 overhead bytes. The IPG being generated under the control of
the PHY is immediately removed once the data is received over the MAC/PLS
interface to create a 9.584640 data stream for packing into a 10.0 Gbaud
stream having 721 overhead bytes followed by 16,640 data bytes (includes
IPG and preambles).
5)a word-by-word HOLD signal at the MAC/PLS boundary
Word-by-word HOLD solution provides the PHY with the greatest generality
since it allows time insertion not only at the GAP time, but anytime in the
packet. This is the most natural mode for a WAN interface which would like
to insert 721 overhead bytes for every 16,640 data bytes. The overhead
bytes can be encoded using frame pointer logic for the scrambler encoding
solutions or can be encoded using special symbols for block coded links.
Paul
At 08:58 AM 8/19/99 -0600, DOVE,DANIEL J (HP-Roseville,ex1) wrote:
>
>> 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
>
>
Paul A. Bottorff, Director Switching Architecture
Enterprise Solutions Technology Center
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx