Re: 10.0 vs 9.584640: That's the PHY's Job
Shawn,
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
after
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
woul
be a variation from Ethernet (as is known so far) protocol.
Regards,
Tripathi.
At 08:21 AM 7/22/99 -0500, you wrote:
>
>Brad, more like a quarter's worth. How would you architect the LAN-WAN rate
>matching connection? That's obviously not in the PHY.
>
>Shawn
>
>
>
> -----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 in
>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 10.0
>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 the
>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 some
>form of flow control or buffering scheme.
>
>I like this because it allows the LAN architectures to remain cost effective
>while offering the ability to easily concentrate links (i.e. ten 1 GbE links
>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 WAN
>and LAN solutions in Kevin's proposal is the PHY. Everything above the PHY
>(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
>
>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 9.584640
>Gbps
>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
>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
>
> --
>
> 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
>must
>> 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
>first
>> >order task is to determine if there is any possibility of supporting an
>> >Ethernet stream, consisting of variable sized packets at ANY MAC/PLS data
>
>> rate
>> >which would eliminate any flow control requirements between Ethernet and
>> SONET
>> >OC-192.
>> >
>> >Is 9.584640 Gbps this data rate? If not, is there any data rate that
>meets
>> the
>> >above requirement? If not, the HSSG speed objective should be 10.0 Gbps.
>> >
>> >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 (below).
>> >> 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
>solution.
>> >> After framing process, the length of the data on SONET will not
>affected
>> >> the content of the Ethernet payload data. POS solution is not suitable
>for
>> >> this.
>> >>
>> >> Send Ethernet 10B code to SONET may be to fit SONET byte stream world.
>> >>
>> >> 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 http://www.transcendata.com
><http://www.transcendata.com>
>> >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 http://www.transcendata.com
><http://www.transcendata.com>
>Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx
>