RE: 9.584640
Rich,
This is an attempt to get real data instead of assertions. I believe
the following are true.
1. A rate of 9.58460 Gbps allows a LAN to (WDM) WAN transponder to be
simpler because it may not require an Ethernet chip set (or just a single
chip). The raw bits can simply be packed into a SONET frame. This however
still requires the SONET chip set and of course the WAN O/E. The cost of the
latter probably makes the cost of an Ethernet chip set insignificant.
2. Use of Ethernet flow control is certainly possible but would again
require an Ethernet chip set. If #1 is true then this is no big deal either.
I assume that the Ethernet chip set could have enough on-board buffer such
that the flow control mechanism will work adequately without require
off-chip storage. That is undesirable because it tends to increase costs
more significantly because you need additional pins to connect a memory and
of course you need the memory itself.
3. Requiring an additional clock for the 10 Gb/s side would still not be a
very significant cost compared to the rest of a 1/10 Gb/s Ethernet switch.
Drew
---------------------------------------------------------
CIENA Corporation Email: ddp@xxxxxxxxx
Core Switching Division Tel: 408-865-6202
10201 Bubb Road Fax: 408-865-6291
Cupertino, CA 95014 Cell/Pager: 408-829-8298
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxxxxx]
Sent: Friday, July 23, 1999 10:48 AM
To: Perkins, Drew; HSSG
Subject: Re: 9.584640
Drew,
I realized this morning that I responded to your rebuttal to my assertion
about
multiple clocks very poorly. I fell into the trap of ignoring the root issue
of this
thread and arguing a point with relatively little significance to core
thread.
Please allow me to take another stab at it:
The multiple clock issue that I responded to is a fourth order thread to the
first
order issue of 10.0 vs. 9.58460 Gbps as a MAC/PLS issue.
The second order thread I asserted in my note is that not a single shred of
architectural proof has been presented to the HSSG, via meetings or
reflector
discussion, as to why 10.0 Gbps will not work in an Ethernet environment
which
provides either WAN access or is directly used for MAN/WAN transport. I am
very
interested, as are many other HSSG members, in understanding the
architectural
reasons, if any, why the HSSG MAC/PLS rate should be 9.584640 Gbps?
802.3 architecture already supports simple and efficient flow control. The
simple
question of: "What is the problem with using a flow-control mechanism to
throttle 10
Gbps Ethernet speed to 9.584 Gbps for SONET???" has already been posed to
this
reflector with no response? I, for one, would like to see some responses to
this
issue in terms of "real credible data" rather than "emphatic assertions" as
you so
bluntly, but also eloquently, put it.
For historical reasons, the third order thread was one of listing several
reasons
why 10 GbE product implementation would be made more expensive if 9.58460
Gbps was
selected as the MAC/PLS data rate. This was a counter to core technical
assertions
about why 9.58460 Gbps was better the 10.0 Gbps as a HSSG objective. As I
understand
it, the only reasoning provided thus far is that this rate make the
IMPLEMENTATION
of Ethernet to SONET equipment easier at the expense of making the
IMPLEMENTATION of
lower to higher speed Ethernet more expensive.
Completing the cycle, I cited multiple clocks due the requirement to support
data
rates which are not integer multiples of each other as adding expense to the
implementation of Ethernet products. This is not an assertion. This is a
fact.
However, I'd like to focus on the core thread of this issue.
Best Regards,
Rich
--
Rich Taborek wrote:
> Drew,
>
> The complexity I mentioned is relative. For example, an 1/10 GbE product
such as
> a switch may be implemetable with a single clock if the MAC/PLS data rate
is set
> to 10 Gbps since the MAC Tx (local) clock may well be 125 MHz. The same
would
> not be possible for the same 1/9.584640 product. The point being that a
MAC/PLS
> data rate of 9.584640 simply complicates the life of an Ethernet product
> designer, especially one that needs to develop products which support
multiple
> Ethernet rates.
>
> --
>
> "Perkins, Drew" wrote:
>
> > Rich,
> > I find your assertions about the complexity of clocks with a
> > 9.584640 rate untrue. In fact I assert that a 9.584640 rate does NOT
make
> > this more difficult. I don't think that having this clock, or having the
> > rate not be a multiple of 1.00000, will be a problem. This was not a
problem
> > in any of the many switches that I have worked on.
> >
> > In the end though, argument by emphatic assertion is a waste of time.
Real
> > proof with credible data is required.
> >
> > Drew
> > ---------------------------------------------------------
> > CIENA Corporation Email: ddp@xxxxxxxxx
> > Core Switching Division Tel: 408-865-6202
> > 10201 Bubb Road Fax: 408-865-6291
> > Cupertino, CA 95014 Cell/Pager: 408-829-8298
> >
> > -----Original Message-----
> > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Rich
> > Taborek
> > Sent: Monday, July 19, 1999 10:17 AM
> > To: rabynum@xxxxxxxxxxx; HSSG
> > Subject: Re: 9.584640
> >
> > Roy,
> >
> > This one's pretty simple. The MAC/PLS clock for 10 Mbps Ethernet is
based on
> > the
> > transport of bits. At 100 Mbps, it's nibbles (4 bits). At 1 Gbps, it's
> > octets. At 10
> > Gbps, several proposals suggest 8, 16 and 32 bit chunks. The local clock
for
> > Ethernet
> > equipment which performs speed matching is easily derived from MAC/PLS
clock
> > of the
> > slowest interface supported. Deriving a 9.584640 is not so
straightforward.
> > Reverse
> > deriving lower speed clocks is also not so straightforward. The simplest
> > solution is
> > to use two clocks. This solution increases implementation cost and will
> > significantly
> > complicate clocking design.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > Roy Bynum wrote:
> >
> > > Rich,
> > >
> > > I hear much about the single system clock issue. In the past, the
data
> > transport
> > > signal clock and the data system bus and processing clock were
separate.
> > For many
> > > systems the data processing would exceed the transport signal in order
to
> > maintain
> > > control. If that is the case, then your argument about a single clock
> > does not
> > > hold. I could be wrong. Would one of the system implementation
people
> > please
> > > define how a data signal clock is derived in today's systems. Is
internal
> > 802.3
> > > frame processing done at a higher rate than the transport signal rates
in
> > today's
> > > GbE L2 switches? Is there a real issue with a separate transport
signal
> > rate or
> > > even a separate transport data rate?
> > >
> > > Thank you,
> > > Roy Bynum
> > > MCI WorldCom
> > >
> > > Rich Taborek wrote:
> > >
> > > > Hon Wah,
> > > >
> > > > Thanks for kicking this issue off again!
> > > >
> > > > Hon Wah Chin wrote:
> > > >
> > > > > Perhaps a difficult number to remember, but with the +- 100ppm
> > tolerance
> > > > > and a bit rate that needs only to fit within about 200ppm of the
> > nominal
> > > > > SONET number we should be able to choose a round number with 4
digits
> > in it.
> > > > >
> > > > > ---
> > > > >
> > > > > As I understand the presentations in Montreal on speed,
> > > > > a strong advantage of choosing this OC-192 payload rate is
> > > > > to transport the signal over SONET OC-192 equipment. This would
> > > > > be from a "10Gb/s Ethernet" port out to SONET gear, which is
really
> > > > > a PMD external interface rather than a definition for the MAC/PLS
> > interface
> > > > > and data rate.
> > > >
> > > > In my conversations with several folks on both sides of the issue
during
> > the
> > > > Montreal meetings, I've come to the conclusion that the root reasons
to
> > select
> > > > either a 10 or 9.584640 Gbps are purely ease-of implementation based
and
> > have no
> > > > architectural basis whatsoever. I believe this to be true on both
sides
> > of the
> > > > argument with the choice of one over the other, rendering the
> > implementation
> > > > (i.e. product cost) of the losing side only slightly more difficult.
> > Please
> > > > allow me to explain the basis of this contention:
> > > >
> > > > 1) SONET, and specifically synchronous transport, is legacy in the
MAN
> > and WAN,
> > > > will never be replaced by Ethernet completely or even quickly.
Ethernet
> > will
> > > > make inroads into "green-field" applications, but SONET will be king
for
> > some
> > > > time to come;
> > > >
> > > > 2) Ethernet, and specifically packet-based transport, is legacy in
the
> > LAN, is
> > > > growing in its dominance in the LAN, and will likely gain market
share
> > in the
> > > > LAN as well as encroach on other non-traditional Ethernet transports
> > including
> > > > MAN, SAN, and some WAN. I don't include WAN access in WAN. Instead I
> > include WAN
> > > > access in LAN or MAN;
> > > >
> > > > 3) The existing WAN infrastructure does a great job of transporting
> > Ethernet
> > > > packets end-to-end today. However, much protocol conversion and
> > equipment to map
> > > > between packets and TDM bits exists in mapping Ethernet to the WAN
at
> > each end.
> > > > Considerable savings can be realized by architecting a more seamless
> > Ethernet to
> > > > SONET connection. This issue seems to be at the root of the 10 vs.
> > 9.584640 Gbps
> > > > issue.
> > > >
> > > > 4) There seems to be no intent by either side to consider any other
> > changes but
> > > > speed as a HSSG objective. Therefore, Ethernet will remain a simple,
> > general
> > > > purpose, packet-based transport, and SONET will remain a specific
> > purpose
> > > > (MAN/WAN), synchronous transport no matter which way the decision
goes.
> > > >
> > > > 5) Consider a Ethernet to OC-192 line card (feeding a fiber or
> > wavelength) in
> > > > operation. Assume that receive and transmit paths are separate on
the
> > SONET side
> > > > and related (i.e. full duplex) on the Ethernet side:
> > > > a) Ethernet -> SONET @ 9.584640 Gbps: The Ethernet side can
> > continuously feed
> > > > the SONET link with no flow control required.
> > > > b) Ethernet -> SONET @ 10 Gbps: The Ethernet side must be flow
> > controlled to
> > > > prevent over-feeding the SONET link
> > > > c) SONET -> Ethernet @ 9.584640 or 10 Gbps: The Ethernet side can
> > continuously
> > > > source SONET data but will flow control or drop packets downstream
> > whenever the
> > > > network is congested.
> > > >
> > > > Therefore, the issue boils down to one of implementation of existing
> > Ethernet
> > > > mechanisms such as 802.3x flow control or a reasonable facsimile on
the
> > line
> > > > card versus complicating the implementation of all Ethernet products
> > which must
> > > > support a MAC/PLS rate which is not a multiple of 10. These
> > implementation
> > > > difficulties include multiple clocks which may "beat" against each
> > other, not
> > > > being able to easily feed 10 slower links into one faster one, and
> > numerous
> > > > other difficulties which are best listed by Ethernet product
> > implementers.
> > > >
> > > > My intention is not to make light of the problem but rather to agree
> > with a
> > > > solution direction along the line proposed by Dan Dove of HP at the
> > Montreal
> > > > meeting. I believe that Dan's general direction was to tradeoff a
simple
> > > > architectural change with respect to MAC operation to enable cost
> > effective 10
> > > > Gbps to SONET implementations. I don't particularly agree with
resolving
> > > > implementation cost issues between two dominant legacy protocols by
> > tweaking
> > > > with the underlying architecture, but I'll raise my hand in support
of
> > this
> > > > solution to the problem.
> > > >
> > > > Such a solution would enable the implementation of a 10 Gbps
Ethernet to
> > SONET
> > > > OC-192 line card without requiring a full MAC.
> > > >
> > > > I'll let Dan fill in the details of his proposal so I don't get it
wrong
> > if it
> > > > is still applicable.
> > > >
> > > > Best Regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > > Given a raw continuous bit stream at the PMD, some scheme for
> > > > > framing packets would be needed. 10M used a carrier, 100M used
> > coding,
> > > > > 1000M used coding. Using coding where the PMD speed is fixed at
> > 9.58Gb/s
> > > > > would mean a further speed reduction (probably 10-20%) at the
MAC/PLS
> > > > > interface. The discussion at the meeting has already started to
> > consider ways
> > > > > of
> > > > > reducing the useful throughput at the MAC/PLS below the data
clocking
> > rate.
> > > > > An
> > > > > alternative framing scheme presented to HSSG, which has a smaller
> > throughput
> > > > > reduction, requires a packet length header -- a departure from
> > previous 802
> > > > > practice.
> > > > >
> > > > > In considering the advantage of leveraging SONET OC-192 transport
> > > > > we should also consider the issues which come up in actually
getting
> > > > > the hoped-for benefits. It would also be worthwhile to carefully
> > consider
> > > > > what volume forecasts for the OC-192 components can be documented,
in
> > > > > evaluating the advantage to be gained. Counting IEEE802.3 10Gb/s
data
> > > > > ports (however the definition works out) to get 2 million ports
sounds
> > > > > good, but I found the forecast of 2,000,000 OC-192 ports in 2000
> > rather
> > > > > surprising.
> > > > >
> > > > > -hwc
-------------------------------------------------------------
Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
Principal Architect Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way http://www.transcendata.com
Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx