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.
Brian
-----Original Message-----
From: Devendra Tripathi <devendra.tripathi@xxxxxxxxx>
To: Rogers, Shawn <s-rogers@xxxxxx>; 'Booth, Brad' <bbooth@xxxxxxxxxx>; HSSG
<stds-802-3-hssg@xxxxxxxx>
Date: Thursday, July 22, 1999 11:26 AM
Subject: 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
>>
>