RE: Proposal for accomodating 10.0000 and 9.58464 line rates
Mick,
Was it Socrates or Confucius that taught us that any function can be
architected into IEEE 802 with an additional sub-layer?
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.
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?
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?
Ariel Hendel
Sun Microsystems
>
> As someone who is deeply involved in standardizing one kind of MAC
> Client (the forwarding function of an 802.1D bridge/ switch) I don't see how
> the 'pacing function' gets put in the 'client' without a massive revision of
> architecture, MAC service interface, definition of what a MAC is etc. From
> my vantage point the HOLD solution is much the simplest, and the most
> general. If this is to go in the direction of 'pacing mechanisms' I would
> suggest that this whole speed matching area gets split off so that the
> campus benefits of 10G can be enjoyed while the historic discussions of
> pacing are replayed.
>
>
> Mick
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Booth, Brad
> Sent: Wednesday, August 18, 1999 1:00 PM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: RE: Proposal for accomodating 10.0000 and 9.58464 line rates
>
>
>
> I think I'd prefer to have a pacing mechanism either in the MAC or in
> the MAC Client. This would keep the rate control at a higher layer in the
> stack, and also keep it located with the current rate control function. The
> MAC already performs a rate control by inserting IPG between packets. A
> pacing mechanism could be added to this IPG insertion, which would result in
> a change in the standard. Or, the pacing mechanism could be implemented in
> the MAC Client (Ariel Hendel's proposal), which would not result in a change
> to the standard other than maybe an addition of an informative annex.
>
> This would eliminate the need for the HOLD signal, and leave the
> pacing mechanism (and its granularity) up to the implementer. J
>
> Thanks,
> Brad
>
> -----Original Message-----
> From: pbottorf@xxxxxxxxxxxxxxxxxx [SMTP:pbottorf@xxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, August 18, 1999 12:17 PM
> To: Booth, Brad; stds-802-3-hssg@xxxxxxxx
> Subject: RE: Proposal for accomodating 10.0000 and 9.58464 line
> rates
>
> Brad, Dan:
>
> I agree with Dan. The HOLD solution is the simplest and most general.
> If the PHY doesn't rate control the MAC then the MAC will need a pacing
> mechanism.
>
> Paul
>
>
>
>