RE: What is ~10 Gb/s?

[pbottorf@xxxxxxxxxxxxxxxxxx (Paul Bottorff)]

At 03:55 PM 6/21/99 -0500, Thirion, Walt wrote:
>So, in your opinion the only data rate we need at the MAC interface is
>9.584640 Gb/s (data rate). For transmit, the Sonet PHY would take in raw
>ethernet data at this speed and spit out encoded data at 9.95328 Gb/s
>(baud rate) and do the opposite for receive. Doing this would allow the
>10 Gb/s ethernet MAC to be directly connected to the Sonet network. Is
>this a correct summation?

Correct summation.
> 
>To continue down this path, are there any other signals necessary to
>support the direct connection, i.e. does the MAC have to be
>started/stopped/etc.? Is there any kind of flow control between the
>Sonet PHY and its upper layer clients? etc. etc. etc.

I beleive this is a function of the encoding method used in the PHY not the
data rate. For the scrambled PHY it is highly desirable to start/stop the
MAC interface in both the transmit and receive direction.
> 
>Would adopting the Sonet data rate allow us to use already developed
>PHYs or would we still need to customize features, etc. for
>autonegotiation, coding, etc.?

Many SONET optical and electric components could be used for early
products, but would not be cost effective due to tighter specs and higher
than required functionality. The parts also will need additional support
logic for encoding, attachment to Ethernet MACs, etc.
> 
>I'm trying to narrow down the issues to see if it really is simply a
>matter of 9.584640 Gb/s vs. 10.000 Gb/s or if other issues come into
>play.
>Walter Thirion 
>Level One Communications 
>512-407-2110 
>
> 
> 
> 
> 
>
>-----Original Message-----
>From: pbottorf@xxxxxxxxxxxxxxxxxx [mailto:pbottorf@xxxxxxxxxxxxxxxxxx]
>Sent: Monday, June 21, 1999 12:16 PM
>To: 'stds-802-3-hssg-speed@xxxxxxxx'; Thirion, Walt
>Subject: Re: What is ~10 Gb/s?
>
>
>
>
>My answers, 
>
>
>At 01:04 AM 6/21/99 -0500, Thirion, Walt wrote: 
>
>>>>> 
>
>What is ~10 Gb/s? 
>
>
>Ok, I would like to get the discussion really going. So, I'm going to
>propose a couple of issues. Hopefully, we'll get extensive reflector
>discussion, then I'll schedule a conference call for Wednesday to try to
>hash out differences. 
>
>
>A lot of the discussion revolves around the objective of whether we want
>to support a direct attachment to the WAN infrastructure by having a
>specification that maps 10Gig directly to an OC-192 like interface. 
>
>
>For the sake of discussion, my first objective is to nail down exactly
>which speeds we're talking about. There were a couple of numbers thrown
>out at the Interim in Idahao. The following table was taken from the web
>site at http://www.data.com/tutorials/sonet.html. 
>
>
>Comparing Capacity 
>
>OC level Number of DS-3 
>
>circuits or STS-1 DS capacity ATM capacity POS capacity 
>
>
>tributaries (Mbit/s) (Mbit/s) (Mbit/s) 
>
>
>OC1 1 45 47 52 
>
>OC3 3 135 129 156 
>
>OC12 12 540 563 622 
>
>OC48 48 2,160 2,254 2,488 
>
>OC192 192 8,640 9,014 9,953 
>
>OC768 768 17,280 36,057 39,813 
>
>
>DS = Digital signal 
>
>POS = Packet over Sonet 
>
>STS =Synchronous transport signal 
>
>______________________________________________ 
>
>
>1. So, when we say ~10Gb/s, is there an actual number that we want and,
>if so, what is that number? 
>
><<<< 
>
>Yes, it is an actual number. The number is a data rate of 9.584640
>Gbits. This rate is expressed after coding overhead (i.e. for 8b/10b
>coding the baud rate would be 11.98080 Gbaud). The reason this number is
>not identical to SONET transmission clock is because all SONET overhead
>has been subtracted. The SONET transmission clock is 9.95328 Gbits of
>which a few percent are coding overhead leaving a 9.584640 data payload.
>The numbers quoted for POS above are incorrect since they include the
>SONET overhead as data therefore not stating the actual line capacity. 
>
>>>>> 
>
>
>
>2. Is there more than one WAN number that we should be considering? If
>so, what are they and what is the basis (standard) for the number? 
>
><<<< 
>
>The 9.584640 is the only number which is required. Adaption to OC-48 and
>OC-768 would be performed by inverse multiplexing and multiplexing
>respectively. The question is whether we need any special considerations
>to allow for multiplexing. This will depend on the PHY design not on the
>10GMII interface rate. 
>
>>>>> 
>
>
>
>3. Is the number a "raw" bit/baud rate or is it the net after
>subtracting some protocol overhead? 
>
><<<< 
>
>The 9.584640 rate includes any Preamble, SA, DA, Type, FCS, and IFG. It
>therefore includes protocol overhead, but not encoding overhead. 
>
>>>>> 
>
>
>
>4. When we talk about a direct connection to the WAN, is there also an
>assumption that we will pick up the integrated management, i.e.
>self-healing Sonet rings? 
>
><<<< 
>
>The 10 GigE is not required to support self-healing or any other SONET
>management attributes. At the demarcation point between 10 GigE and a
>SONET ring a transcoding device will isolate the SONET characteristics
>from 10 GigE characteristics. The transcoder will allow SONET management
>on the SONET ring and Ethernet management on the 10 GigE ring. 
>
>
>An independent issue to the speed is whether 10 GigE should have SONET
>type management capabilities for self-healing and failure detection.
>These may be desirable objectives, but have little to do with the speed
>issue. The management issue is more important for dark fiber and dark
>wavelength applications than SONET mapping applications. 
>
>>>>> 
>
>
>
>Walter Thirion 
>
>Level One Communications 
>
>512-407-2110 
>
>
>
>
>
>
>
>
>Paul A. Bottorff, Director Switching Architecture 
>
>Bay Architecture Laboratory 
>
>Nortel Networks, Inc. 
>
>4401 Great America Parkway 
>
>Santa Clara, CA 95052-8185 
>
>Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365 
>
>email: pbottorf@xxxxxxxxxxxxxxxxxx
>
>
>Attachment Converted: "c:\eudora\attach\RE What is ~10 Gbs"
>
Paul A. Bottorff, Director Switching Architecture
Bay Architecture Laboratory
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx