Re: Proposal for accommodating 10.0000 and 9.58464 line rates
Steve:
Though I'm interested in Dan's proposal, I have not made the jump to
believing that 10 GigE has more than a single encoding system. For some of
the proposed 10 GigE encoding systems the device at the demarcation point
between an OC-192 DWDM network and an Ethernet network will be forced to
perform a code translation, for others no code translation will be
required. If a translation is required (which depends on what the task
force chooses as the encoding system), it is probably not part of the
10GigE standard, though some considerations in the standard need to be
based on an understanding of how the transformation takes place.
I thought we were talking about a byte-by-byte pacing mechanism. The
"differing" mechanism as I understand it is a frame-by-frame mechanism.
Byte-by-byte is desirable for some of the proposed encoding systems.
The line baud rate will depend on the encoding system. Of the proposed
encoding systems only Martin Nuss's proposal might result in a line rate
equal to 9.584640 G for a 9.584640 G data rate. The line rate for OC-192 is
9.953280 Gbps.
Paul
At 01:05 PM 7/23/99 -0700, Steve Haddock wrote:
>
>
>Judging by the reflector traffic, it seems that there is quite a bit of
>support for the proposal made by Dan Dove and Kevin Daines for defining a
>MAC/PLS interface that runs at 10.0000 Mb/s but has a flow control mechanism
>that allows the effective payload rate to be matched to 9.58464 Mb/s. This
>would allow the specification of a 10.0000 Mb/s PHY and a 9.58464 Mb/s PHY
>that interfaced to the MAC using the same 10.0000 Mb/s MAC/PLS interface.
>At the Montreal meeting I suggested that the MAC already had such a flow
>control mechanism, called "deference", which could potentially be used for
>this purpose. After reviewing the MAC spec, I believe that this is very
>straight-forward.
>
>For those new to 802.3, the core MAC functionality is specified in PASCAL
>code in clause 4 of the standard. Within this code there is a process call
>"deference" which generates a variable called "deferring". When deferring
>is true, the MAC transmitter will not initiate a new frame transmission. In
>the traditional CSMA/CD half-duplex operation, this variable was asserted in
>response to CarrierSense to prevent the transmitter from initiating a
>transmission when the medium was already busy. In full-duplex operation the
>variable is used simply to time interFrameSpacing (aka inter packet gaps).
>The CarrierSense input to the deference process is currently not used in
>full duplex operation. I propose that we define the use of CarrierSense in
>full duplex to be conceptually the same as its use in half duplex: to
>inhibit the initiation of new transmission.
>
>In practical terms this means that we either define a new signal "Hold" (as
>suggested by Dan), or use the "CRS" signal, at the MAC/PLS interface that
>drives the carrierSense input to the deference process. A PHY could then
>use this signal in full duplex mode to control the spacing between
>transmitted frames. This would allow a PHY with a transmit line rate of
>9.58464 to connect to a MAC/PLS interface running at 10.0000 Mb/s without
>loss of data. It would require the PHY to have some nominal buffering to
>prevent overrunning the transmit channel during a maximum size frame (max
>frame of 1522 bytes * 9.58464 / 10.0000 requires a 64 byte FIFO).
>
>The simplest way to implement this in the MAC PASCAL is to add a single line
>to the deference process. The deference process is divided into a
>half-duplex loop and a full-duplex loop. The full-duplex loop, with the new
>line in bold, would become:
> else cycle {full-duplex loop}
> while not transmitting do nothing; {wait for the start of a
>transmission}
> deferring := true; {inhibit future transmissions}
> while transmitting do nothing; {wait for the end of the
>current transmission}
> StartRealTimeDelay; {time out an interframe gap}
> while RealTimeDelay(interFrameSpacing) do nothing;
> while carrierSense do nothing; {wait for deassertion of
>carrier sense}
> deferring := false {don't inhibit transmission}
> end {full-duplex loop}
>
>Notice that this means the MAC will only sample carrierSense at the end of
>an interframe gap immediately following a transmission. This is sufficient
>if the goal is to control interframe spacing. If we want the MAC to defer
>to carrierSense even if it has not recently transmitted, then the PASCAL
>modifications get slightly more complex but are still contained within this
>"full-duplex loop". The biggest complication in trying to get the MAC to
>defer to carrierSense at any time rather than just following a transmission
>is that we will have to tightly define the latency from when a PHY asserts
>CRS to when the MAC responds.
>
>There is also a backwards compatibility issue to resolve if we choose to use
>CRS as opposed to defining a new signal. Currently the MAC/PLS interface
>says CRS is undefined for full-duplex operation. We would need to word the
>specification such that we accomplish what we desire for 10Gbps operation,
>but without making existing 10/100/1000 Mbps implementations non-compliant
>if they happen to assert CRS in response to receive activity even in full
>duplex mode.
>
>Steve Haddock
>Extreme Networks
>
>
Paul A. Bottorff, Director Switching Architecture
Bay Architecture Laboratory
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