Re: 9.584640
"Perkins, Drew" wrote:
> 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.
Drew,
Other than an outstanding objective to determine speed, I'm unaware of any HSSG
proposals to significantly deviate from Ethernet architecture. Therefore, both
an ~10 Gbps Ethernet element and protocol converter element MUST be present to
convert between Ethernet and SONET. I don't know whether these elements would be
located in a transponder or not. However, they must be present somewhere in the
path between Ethernet and SONET.
> 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.
Assuming that an Ethernet element is required, the cost of standard Ethernet
flow control between 10 Gbps Ethernet and OC-192 is relatively inexpensive. Walt
Thirion of Level One addressed this in a note to the HSSG Speed reflector which
can be found at the following URL:
http://grouper.ieee.org/groups/802/3/10G_study/public/speed_adhoc/email/msg00035.html
> 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.
I don't understand the relevance of an Ethernet switch in this context.
> 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
--
Best Regards,
Rich
-------------------------------------------------------------
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