RE: 9.584640
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