Re: Data rate standards vs internal switching standards
Ariel,
Thank you very much for your response. I knew that some of what I was
writing was not altogether correct, but I wanted to bring the
questions out. You have corrected my some of my assertions and set some
discernable boundaries between preferences and standards.
I would like an additional clarification. In recognizing that the data
clocking standards are at the exposed interface of the data link, does
this mean that the standard applies to the MII between the MAC layer
and the PHY or does it apply more to the PHY?
On the question of how vendors move data from one port to another within
a switch, I was thinking more of the issue of bus and inter-port data
clocking. Having designed several systems in years past, I recognize
the difference between aggregating data by a factor of ten instead
of 2. I thank you for clarifying the fact that a modulo 10 reference
is not the optimal, making a it mute issue, except from a marketing view
point.
You agree that current 802.3 technology is very much moving away from
shared segment processes. This means that the shared segment aggregation
paradigm based on modulo 10 can also be re-examined. What ever the
results, from working on data systems within the common carrier industry,
I think that it is a great opportunity for 802.3 to "blink", instead
of waiting for "Moore's Law".
As for the OC rate standard, there are several standards for mapping
data into SONET/SDH transports. From an 802.3 view point, the
SONET/SDH standards can be treated as layer 1 functional processes.
From the other side of that argument, the current packet over SONET
(POS) standard for mapping required an additional standard for
inserting a layer 2 functionality between the layer 3 IP protocol and
the layer 1 SONET protocol. 802.3 does not have that requirement for
an additional functionality. In many ways it is more of a question of
how much of the SONET/SDH standards would not used for 10GbE,
depending on the implementation of the interfaces.
I thank you very much for your response. I think that people such
as yourself will help all of us to find the proper "middle ground"
on this issue of moving 802.3 into expanded markets.
Thank you,
Roy Bynum
MCI WorldCom
Date: Mon Aug 02, 1999 2:54 pm CST
Source-Date: Mon, 02 Aug 1999 13:53:25 -0700 (PDT)
From: Ariel Hendel
EMS: INTERNET / MCI ID: 376-5414
MBX: Ariel.Hendel@xxxxxxxxxxx
TO: stds-802-3-hssg
EMS: INTERNET / MCI ID: 376-5414
MBX: stds-802-3-hssg@xxxxxxxx
TO: * ROY BYNUM / MCI ID: 424-5935
Subject: Re: Data rate standards vs internal switching standards
Message-Id: 99080220541950/INTERNETGWDN2IG
Source-Msg-Id: <199908022053.NAA16480@xxxxxxxxxxxxxxxxx>
U-X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc
U-Content-MD5: s1ie+y5ySKUTlpCpBUVtNA==
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
>
>