RE: Proposal for accomodating 10.0000 and 9.58464 line rates
Steve and Dan:
Pleas enlighten me a little bit with your proposal.
Questions:
1. Do we still need buffer, or not with the flow-control you are proposing.
2. This flow-control only deals speed-conversion issue; therefore, we still
need a framer to convert different codes. Unless you are proposing one
coding for both.
Ed Chang
Unisys Corporation
Edward.Chang@xxxxxxxxxx
-----Original Message-----
From: Dan Dove [mailto:dan_dove@xxxxxx]
Sent: Tuesday, August 03, 1999 12:59 PM
Cc: stds-802-3-hssg@xxxxxxxx
Subject: Re: Proposal for accomodating 10.0000 and 9.58464 line rates
Steve,
Thanks for your valuable insights on this concept. I recommend using a
"Hold" signal primarily because I believe that using "CRS" to indicate
that a PHY is unable to absorb data violates the original intent of that
signal (to indicate that carrier is present) and might be confusing to
implementors.
The addition of such a signal to the XGMII seems to be a minor price to
pay in order to add support for OC-192 links of up to 40km.
I would like to re-iterate my concerns about the latency of the interface
and how that impacts the assertion of the "Hold" signal, but I believe it
can be dealt with by requiring the PHY to assert it within the first 64
bytes of a frame to indicate that the next IPG should be extended.
Thanks again,
Dan Dove
--
___________ _________________________________________________________
_________ _/ ___________ Daniel Dove Principal Engineer __
_______ _/ ________ dan_dove@xxxxxx LAN PHY Technology __
_____ _/ ______ Hewlett-Packard Company __
____ _/_/_/ _/_/_/ _____ Workgroup Networks Division __
____ _/ _/ _/ _/ _____ 8000 Foothills Blvd. MS 5555 __
_____ _/ _/ _/_/_/ ______ Roseville, CA 95747-5555 __
______ _/ ________ Phone: 916 785 4187 __
_______ _/ _________ Fax : 916 785 1815 __
__________ _/ __________________________________________________________
shaddock@xxxxxxxxxxxxxxxxxxx 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