Proposal for accomodating 10.0000 and 9.58464 line rates
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