Re: 9.584640
At 05:39 PM 7/21/99 -0700, you wrote:
>Paul,
>
>Vacation!!! What's a vacation???
Agree
>
>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 very much disagree that the choice is purely ease-of implementation. The
major issue is whether Ethernet will be competitive versus other
alternatives for mainstream WAN applications. The mainstream WAN
applications are currently dominated by ATM and PoS. Ethernet could provide
a much simpler and more cost effective solution for WAN applications with
the added advantages of standards links for dark fiber and compatibility
with the majority of data sources. Whoever, if Ethernet does not move to
simplify WAN access interfaces, then the existing alternatives and their
future generations will dominate the WAN market locking Ethernet out.
Technically anything can be done, but the market will only accept a
solution which is better than the other available choices. Using a data
rate of 9.584640 G will simplify the WAN access to the extent where
Ethernet will become the top contender in the WAN space. Further the data
rate change does not force negative impacts on LAN implementations.
>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.
Agree
>Ethernet will
>make inroads into "green-field" applications, but SONET will be king for some
>time to come;
The viability of Ethernet in "green-field" applications is impacted by
alternative technologies. If Ethernet looses the mainstream WAN to, for
example, a future generation of PoS, then Ethernet will compete in "green
fields" with the mainstream alternative with uncertain outcomes.
>
>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;
Agree
>
>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.
At the same time WANs are architected to transport data traffic more
seamlessly. In particular the trend is to move to photonic DWDM networks
which are not SONET based. It is these new photonic DWDM networks where a
9.584640 G Ethernet would be most important. In the DWDM networks Ethernet
would be directly carried, not encapsuled in OC-192. The issue here is one
of transition. The current DWDM networks were built for SONET transport.
Because of this they will retain some of the SONET character for a number
of years before they become completely transparent.
>
>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.
Agree
>
>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.
Agree
> b) Ethernet -> SONET @ 10 Gbps: The Ethernet side must be flow
controlled to
>prevent over-feeding the SONET link
Agree, the data rate after flow control will be 9.584640
> 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.
I don't understand c) do you mean "The SONET side can continuously source
Ethernet 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.
I disagree that using a 9.584640 data rate complicates Ethernet products. I
also disagree with the assumptions about clock usage. The data rate and
clock rate at the MAC/PLS don't have to be the same. Even though current
Ethernet MAC/PLS interfaces use the same data rate as clock rate I believe
it is desirable to have a MAC/PLS interface with a faster clock rate than
the data rate. Of course this may lead to what I think Dan Dove was
proposing.
>
>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.
I also believe Dan has a solution in hand, but would like Dan to fill some
details before I make his solution into something other than he intended.
>
>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
>> >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
>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