RE: 9.584640
Rich:
A few of the slides I left off my presentation in Montreal dealt with the
issues you have outlined...
...At the risk of sounding like I am coming "from way deep in left field" I
had made the following proposition in those slides:
1) Having listened to various SONET vs. Ethernet discussions, I was
beginning to question the "assumption" that we needed to have ONE 10 Gig
standard...This assumption is based on the resounding success of Gigabit
Ethernet - but we should all recall that Gigabit Ethernet did not face the
added complexity of needing to correctly accommodate the WAN/MAN.
Further more, as I stated in my presentation, there is a fundamental
cost/benefit difference between campus networks and WAN/MAN networks that
cannot easily be reconciled.
2) For me, I felt the correct "blueprint" for a 10G standard was probably 10
years old - namely 10Base-F_..Let me try to explain why chronologically...
A) After a series of "pitched battles", 3 standards were adopted to
accommodate the various stakeholders: 10Base- FL, 10Base-FB, and
10Base-FP....
B) FB was basically "industrial strength" FL, and FP was a PON-like
system that was probably a generation too early. Over the years, the
market did indeed pick FL for it's simplicity and accommodated for some of
it's shortcomings...
3) I believe that we should a similar approach for 10 Gig...That is, rather
than argue about one standard vs. other, we should develop a way to
accommodate both under separate PARs..
PAR 1) Could be called 10G-FC (as in Fiber Campus)
Possible Features:
10.000 line rate
truncated temp spec (EG: 10C - 70C)
various MMF specs
>= 2 km's SMF spec
No L1 management features
PAR 2) Could be called 10G-FM (as in Fiber Metro)
Possible Features:
9.584640 line rate
full temp spec (EG: 0C - 85C)
no MMF specs
>= 3 km's SMF spec
L1 management features
We would then do some of "throttling features" - or what ever else is
proposed - between the 2 standards at the MAC layer.
A few additional points to consider:
1) The campus doesn't need - and will probably never need - SONET features.
No need to weigh a campus spec with such features. (Remember, virtually no
one bought into the notion of adopting the added "benefits" of ATM to the
desktop).
2) Conversely, the wide/metro area requires L1 features that L3 routing
doesn't appear to provide...Why force that market segment to "drop" a
requirement that they have repeatedly said they need?
3) The added cost of SONET is partly the result of additional spec
requirements placed on components...A key example is the temp requirement;
but there are others such as laser monitoring....
Ultimately, in my (admittedly biased) opinion, 10G-FC will push into the
metro because of it's superior cost position...However, let the market place
decide that...just like the market place decided on 10Base-FL...
Atikem
AMP
> -----Original Message-----
> From: Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxxxxx]
> Sent: Thursday, July 15, 1999 6:17 PM
> To: Hon Wah Chin; HSSG; Dan Dove
> Subject: Re: 9.584640
>
>
> Hon Wah,
>
> Thanks for kicking this issue off again!
>
> Hon Wah Chin wrote:
>
> > Perhaps a difficult number to remember, but with the +- 100ppm tolerance
> > and a bit rate that needs only to fit within about 200ppm of the nominal
> > SONET number we should be able to choose a round number with 4 digits in
> it.
> >
> > ---
> >
> > As I understand the presentations in Montreal on speed,
> > a strong advantage of choosing this OC-192 payload rate is
> > to transport the signal over SONET OC-192 equipment. This would
> > be from a "10Gb/s Ethernet" port out to SONET gear, which is really
> > a PMD external interface rather than a definition for the MAC/PLS
> interface
> > and data rate.
>
> 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
>
> --
>
> > Given a raw continuous bit stream at the PMD, some scheme for
> > framing packets would be needed. 10M used a carrier, 100M used coding,
> > 1000M used coding. Using coding where the PMD speed is fixed at
> 9.58Gb/s
> > would mean a further speed reduction (probably 10-20%) at the MAC/PLS
> > interface. The discussion at the meeting has already started to consider
> ways
> > of
> > reducing the useful throughput at the MAC/PLS below the data clocking
> rate.
> > An
> > alternative framing scheme presented to HSSG, which has a smaller
> throughput
> > reduction, requires a packet length header -- a departure from previous
> 802
> > practice.
> >
> > In considering the advantage of leveraging SONET OC-192 transport
> > we should also consider the issues which come up in actually getting
> > the hoped-for benefits. It would also be worthwhile to carefully
> consider
> > what volume forecasts for the OC-192 components can be documented, in
> > evaluating the advantage to be gained. Counting IEEE802.3 10Gb/s data
> > ports (however the definition works out) to get 2 million ports sounds
> > good, but I found the forecast of 2,000,000 OC-192 ports in 2000 rather
> > surprising.
> >
> > -hwc
>
> -------------------------------------------------------------
> 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
>
>