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