Re: Data rate standards vs internal switching standards
Roy,
I have attempted to answer several of the concerns you expressed
in your message. See my comments bellow.
Ariel Hendel
Sun Microsystems
> Date: Mon, 02 Aug 1999 11:05:59 -0400 (EDT)
> From: Roy Bynum <RBYNUM/0004245935@xxxxxxxxxxx>
> Subject: Data rate standards vs internal switching standards
> To: IEEE HSSG <stds-802-3-hssg@xxxxxxxx>
> Content-transfer-encoding: 7BIT
> X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
> X-Listname: stds-802-3-hssg
> X-Info: [Un]Subscribe requests to majordomo@xxxxxxxxxxxxxxxxxx
> X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
>
>
> I have been to reading objections to using something other
> than the traditional modulo 10 MAC data rate. I have begun to realize
> that a lot of the objections are based on some unknown "standard" of
> switching data between ports. As far as I know, there are no standards
> within 802 that define how a vendor switches data from one port to
> another.
This is part of the MAC Relay Entity of 802.1D defining the behavior of a
bridge (aka switch) forwarding function.
> As far as I know there are no standards of how vendors clock
> data, or even maintain data integrity within a switch.
The clocking of data is covered by 802 standards wherever there is an
exposed interface (e.g. MII in Chapter 22 of 802.3). The MAC Relay
Entity of 802.1d does not deal with any exposed interfaces, therefore
it rightfully describes externally observable behavior rather than
clocks or implementation.
> As far as I
> know there are no standards on how a vendor will clock data from a
> framing buffer into the MAC interface only the rate that it is done
> at.
>
If by framing buffer you are referring to the south (cable) side of the
MAC, then there are standards. For exposed interfaces they are very
clear down to volts and nanoseconds. Even for non-exposed MAC
interfaces the 802.3 standard is based on key semantics that are
visible to the MAC state machine. These semantics are:
- Envelope based packet delineation (e.g. Carrier Sense for receive).
- Absence of reliable byte count (delineation/CRC checking do not rely on byte count).
- Absence of non-data characters (the MAC code space is just octets, with
preamble/flag being regular octets as well).
> Some one should be able to verify that other than specified MAC and
> signaling clock rate of the 802.3 interfaces, there are no clocking
> or data rate standards of how data is handled within a switch.
>
> If I am correct, there are no standards for how the data is clocked
> within a switch. All objections based on linking older interface data
> rate standards would only apply to a switch that is fully loaded, actually
> overloaded. Relative to that reality, overloading an output MAC at
> one data rate is no different from overloading one at another rate.
>
If I had any success, I was trying to highlight the fact that all
clocking related arguments are limited to datalink standards like
802.3, and by the layered nature of the standards they do not deal with
switches, just the datalink. The 802.1 level of abstraction should and
does not discuss clocking issues.
Does that mean that any clock rate is equivalent? Probably not.
For the designer it is best to have integer ratios between the clocks used
at different ports, this is not so much to derive one from the other,
but more to simplify the service weights for scheduling access to shared
resources like central search engines and shared buffers, for example.
Traditionally designers also prefer ratios in powers of 2 increments,
and have systematically lost at 802.3.
The factor of 10 ratio seems to have more appeal in the marketing and
network planning space than the factor of 8, and all indications are
that from the longevity point of view it was the right choice. Is this
the time for 802.3 to blink, or should we let Moore's law blink first?
> As such, all objections to something other than the traditional modulo
> 10 are based on an assumed standard that does not exist or they are
> based on an operational implementation inadequacy. The other side of
> that issue is the leveraging of technology that already exists and has
> several years of operational experience using a data rate at something
> other than the traditional modulo 10.
>
> The real problem is in realizing that 802.3 is no longer limited to a
> shared segment environment. Many will say that they know that 802.3
> has not been limited to a shared segment for years. For some reason,
> they are still writing as if 10GbE will using shared hubs and segments.
>
Roy, I do not see any basis for such a claim.
First, 802.1D was published back in 1990. Second, I have personally
witnessed the effort of hundreds of colleagues during the last four
years developing and writing 802.3x, 802.1Q, 802.1P, and 802.3z. None
of these is hub centric, in fact all of these standards only make sense
for switched networks.
> 802.3 has been progressing more an more away from the original concept
> of a LAN for many years. The very concept of a LAN has changed from 20
> years ago. The boundary have been blurring more and more over time.
>
> With full duplex, optical, GbE, the 802.3 WG sanctioned, by default,
> the entry of 802.3 into the long distance data environment. Long
> distance data has traditionally been considered WAN services. The 802.3
> WG ignored the operational support distinctions between traditional
> LAN and WAN environments. With 10GbE that operational support
> distinction can no longer be ignored. The existing transport and
> support infrastructure for long distance data as well as that
> technology should also not be ignored.
>
> I have yet to see a valid, standards based, objection to a non-modulo
> 10 MAC data rate. I have seen several valid advocations of a
> MAC rate other than modulo 10 that are based on long distance data
> technology standards.
>
I have seen some calls for matching the payload rate between 10GbE and
one particular flavor of Ethernet encapsulation over OC-192 links. Not
only this encapsulation is not standardized either, also matching the
payload rate does not necessarily mean a non-modulo 10 data rate.
As I mentioned previously to others, virtualy all MACs have programmable
IPG parameters. All it takes is to program the IPG register to the value
you want. Increasing the IPG value has no interoperability ramifications
for the link in question. The MII lineage of interfaces already includes
a management interface that you can use to determine the identity and needs
of you PHY.
I know that a surgeon will recommend surgery every time, but what is
wrong with this aspirin?
> Thank you,
> Roy Bynum
> MCI WorldCom
>
>