Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: 9.584640




Rich,

Given that we are discussing many flow controls here, it may be usefull to
mention which one we are talking and
when. In my understanding following flow controls are being mentioned here.

a. 802.3x : Useful  on recieve (wrt medium side) side FIFOs. In the context
of 10 vs 9.58460 I do
    not appreciate, how it can help.
b. Transmit side PHY to MAC flow control either using COL (as I suggested)
or HOLD (as Dan has suggested).
    This is applicable when PHY is at 9.58460 and MAC at 10.
c. Receive side MAC to PHY flow control. Applicable if one decides to have
9.5846 as MAC speed and 10 as PHY. I am
    not sure if, ever, this has been context, though.

Is there anything else we are talking ?

Thanks,
Tripathi.

At 10:48 AM 7/23/99 -0700, you wrote:
>
>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@ciena.com
>> > 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@majordomo.ieee.org
>> > [mailto:owner-stds-802-3-hssg@majordomo.ieee.org]On Behalf Of Rich
>> > Taborek
>> > Sent: Monday, July 19, 1999 10:17 AM
>> > To: rabynum@airmail.net; 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@transcendata.com
>1029 Corporation Way              http://www.transcendata.com
>Palo Alto, CA 94303-4305    Alt email: rtaborek@earthlink.net
>