Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Proposal for accomodating 10.0000 and 9.58464 line rates

This is a good idea. I take back suggestion of COL signal. CRS is much more
for this purpose.


At 01:05 PM 7/23/99 -0700, you 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
>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
>		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