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

Re: 10.0 vs 9.584640: That's the PHY's Job

Just curious about your comment that "frame size will be more limited".  Any
further explanation welcome.


-----Original Message-----
From: Devendra Tripathi <devendra.tripathi@xxxxxxxxx>
To: Rogers, Shawn <s-rogers@xxxxxx>; 'Booth, Brad' <bbooth@xxxxxxxxxx>; HSSG
Date: Thursday, July 22, 1999 11:26 AM
Subject: Re: 10.0 vs 9.584640: That's the PHY's Job

>How about using the "COL" signal for it. It will remain compatible with
>Ethernet and will
>require a small buffering, if at all in PHY. At 9.58460, a buffer of 64
>bytes can support
>64*24 (=1540) length frame. In case of OC192 interface, the frame size will
>be possibly
>much more limited (I need education on this). The PHY could assert COL just
>TXEN going low, till its buffer gets empty (or reaches some suitable
>threshold). A fancier
>implementation though could use COL for word by word flow control, but that
>be a variation from Ethernet (as is known so far) protocol.
>At 08:21 AM 7/22/99 -0500, you wrote:
>>Brad, more like a quarter's worth.  How would you architect the LAN-WAN
>>matching connection?  That's obviously not in the PHY.
>> -----Original Message-----
>>From: Booth, Brad [mailto:bbooth@xxxxxxxxxx]
>>Sent: Wednesday, July 21, 1999 9:22 PM
>>To: HSSG
>>Subject: RE: 9.584640
>>I really liked the proposal that Kevin Daines put on the overhead.  One of
>>the reasons that I liked the proposal is that it matched what I pictured
>>my mind. :-)  But there were other technical reasons why I liked it.  The
>>proposal for those that missed it was to leave the MAC/PLS data rate at
>>Gb/s, but to have the PHYs determine what data rate was required.  In the
>>case of a LAN PHY, the data rate would be 10.0 Gb/s... a direct match to
>>MAC/PLS data rate.  In the case of a WAN (or OC-192) PHY, the data rate
>>would be 9.58464 Gb/s and the PHY would obtain that data rate by either
>>form of flow control or buffering scheme.
>>I like this because it allows the LAN architectures to remain cost
>>while offering the ability to easily concentrate links (i.e. ten 1 GbE
>>map nicely into one 10 GbE link).  This architecture puts a bit of a cost
>>burden on the WAN PHY, but I think that this still results in a cost
>>effective solution for OC-192.  The WAN solution may not be as low cost as
>>the LAN solution, but show me a Gb/s WAN solution today that is as cost
>>effective as a Gb/s LAN solution.
>>The other part that I like is that the only real difference between the
>>and LAN solutions in Kevin's proposal is the PHY.  Everything above the
>>(including interface to PHY) remains relatively unchanged.  Yes, it's all
>>going much faster, but that's an implementation issue, not a standards
>>issue.  At least that's my impression. :-)
>>Just my 2 cents worth,
>>Brad Booth
>>Level One Communications, Austin Design Center
>>(512) 407-2135 work
>>(512) 589-4438 cell
>> -----Original Message-----
>>From:   Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxxxxx]
>>Sent:   Wednesday, July 21, 1999 7:39 PM
>>To:     Paul Bottorff; HSSG
>>Subject:        Re: 9.584640
>> Paul,
>> Vacation!!! What's a vacation???
>> Thanks for taking the time out to respond. I'd like you to review my
>>original note
>>on this thread to see where you stand based on your agreement that
>>as being the "perfect" Ethernet for matching to OC-192 SONET. Here is the
>>text of
>>that note:
>> 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
>>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
>>argument with the choice of one over the other, rendering the
>>(i.e. product cost) of the losing side only slightly more difficult.
>>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
>>make inroads into "green-field" applications, but SONET will be king for
>>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
>>LAN as well as encroach on other non-traditional Ethernet transports
>>MAN, SAN, and some WAN. I don't include WAN access in WAN. Instead I
>>access in LAN or MAN;
>> 3) The existing WAN infrastructure does a great job of transporting
>>packets end-to-end today. However, much protocol conversion and equipment
>>between packets and TDM bits exists in mapping Ethernet to the WAN at each
>>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.
>> 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,
>>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
>>and related (i.e. full duplex) on the Ethernet side:
>>  a) Ethernet -> SONET @ 9.584640 Gbps: The Ethernet side can continuously
>>the SONET link with no flow control required.
>>  b) Ethernet -> SONET @ 10 Gbps: The Ethernet side must be flow
>>prevent over-feeding the SONET link
>>  c) SONET -> Ethernet @ 9.584640 or 10 Gbps: The Ethernet side can
>>source SONET data but will flow control or drop packets downstream
>>network is congested.
>> Therefore, the issue boils down to one of implementation of existing
>>mechanisms such as 802.3x flow control or a reasonable facsimile on the
>>card versus complicating the implementation of all Ethernet products which
>>support a MAC/PLS rate which is not a multiple of 10. These implementation
>>difficulties include multiple clocks which may "beat" against each other,
>>being able to easily feed 10 slower links into one faster one, and
>>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
>>meeting. I believe that Dan's general direction was to tradeoff a simple
>>architectural change with respect to MAC operation to enable cost
>>Gbps to SONET implementations. I don't particularly agree with resolving
>>implementation cost issues between two dominant legacy protocols by
>>with the underlying architecture, but I'll raise my hand in support of
>>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,
>> --
>> Paul Bottorff wrote:
>> > Toshio, Rich:
>>> Sorry for dropping in a little late, but I'm supposed to be on vacation.
>>> The 9.584640 is the exact rate of a OC-192 payload. Running at this rate
>>> will allow the data to be encoded onto an OC-192 directly at rate. In
>>> addition, this data rate allows running over the installed base of 10 G
>>> DWDM regenerator networks.
>>> To encode a 9.584640 G Ethernet steam on an OC-192 the encoding system
>>> not expand the data like 8b/10b does. Both the Nortel and the Lucent
>>> proposals are capable of providing an encode which can be transported a
>>> 9.584640 G Ethernet data stream over OC-192.
>>> Paul
>>> At 02:29 PM 7/20/99 -0700, Rich Taborek wrote:
>>> >
>>> >Toshio,
>>> >
>>> >I believe that the framing solution is a second-order task and that the
>>> >order task is to determine if there is any possibility of supporting an
>>> >Ethernet stream, consisting of variable sized packets at ANY MAC/PLS
>>> rate
>>> >which would eliminate any flow control requirements between Ethernet
>>> >OC-192.
>>> >
>>> >Is 9.584640 Gbps this data rate? If not, is there any data rate that
>>> the
>>> >above requirement? If not, the HSSG speed objective should be 10.0
>>> >
>>> >Best Regards,
>>> >Rich
>>> >
>>> >--
>>> >
>>> >Toshio Ooka wrote:
>>> >
>>> >> Rich,
>>> >>
>>> >> > I have assumed that the proponents of the 9.584640 Gbps MAC/PLS
>>> >> > payload rate have selected that rate specifically to allow a SONET
>>> links to
>>> >>
>>> >> > accept Ethernet payload at full rate as indicated in my #5a
>>> >> I believe that the rate specifically to allow a SONET links to accept
>>> >> Ethernet payload
>>> >> is great idea.
>>> >>
>>> >> But to realize this idea, I think we need to have some framing
>>> >> After framing process, the length of the data on SONET will not
>>> >> the content of the Ethernet payload data. POS solution is not
>>> >> this.
>>> >>
>>> >> Send Ethernet 10B code to SONET may be to fit SONET byte stream
>>> >>
>>> >> Thank you for your prompt reply.
>>> >>
>>> >> Best Regards,
>>> >> Toshio
>>> >> ----
>>> >> Toshio Ooka @Sumitomo Electric U.S.A., Inc.
>>> >> 3235 Kifer Rd, #150, Santa Clara, CA 95051-0185
>>> >> Phone:(408)737-8517x232    Fax(408)737-0134
>>> >
>>> >-------------------------------------------------------------
>>> >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    
>>> >Palo Alto, CA 94303-4305    Alt email: rtaborek@xxxxxxxxxxxxx
>>> >
>>> >
>>> >
>>> >
>>> 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
>> -------------------------------------------------------------
>>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    
>>Palo Alto, CA 94303-4305    Alt email: rtaborek@xxxxxxxxxxxxx