Re: A telephony carrier industry perspective
- To: Jonathan Thatcher <jonathan@xxxxxxxxxxxxx>
- Subject: Re: A telephony carrier industry perspective
- From: Martin Nuss <nuss@xxxxxxxxxx>
- Date: Tue, 18 May 1999 18:32:51 -0400
- CC: IEEE HSSG <stds-802-3-hssg@xxxxxxxx>
- Organization: Bell Labs - Lucent Technologies
- References: <8E37550684B3D211A20B0090271EC59D016CF35A@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Reply-To: nuss@xxxxxxxxxx
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Jonathan:
With all the flurry of interest in coding vs. scrambling and the new
folks that are approaching 10GbE more from the WAN angle, I am wondering
if we can find (at least) 2 volunteers that can educate the study group
on this issue at the interim meeting:
- from the Ethernet point-of-view (all the good stuff coding does for
us...)
- from a WAN point-of-view (how much of the coding can be dispensed with
and why...)
Martin Nuss
Optical Enterprise Networks Research
Bell Labs - Lucent Technologies
(732) 949-5358
FAX: (732) 949-2473
Chang, Edward S wrote:
>
> Drew:
>
> I feel comfortable with your item 1, of your summary, cable lengths. I
> think we can fix it one way or the other.
>
> However, I do not feel comfortable with the "Scrambled Coding" in item 2.
> The scramble-code has been discussed, and exhausted for last 2 weeks on the
> reflector. Nevertheless, there are still a few significant factors not
> being brought up.
>
> 1. Probability of excessive run-length.
>
> Based on the 8B/10B coding, the run length of a scramble-code should be less
> than six to be comparable with 8B/10B maximum run-length of 5 bit. This is
> one of the reason, it can minimize base-line wander to achieve BER of
> 10^-12. Under this assumption, the probability of running into excessive
> run length is : SUM of P(n,70) + P(n,69) + ......P(n,6). The probabilities
> of run-lengths, 70, 69, 68 ....6 should be summarized, which is much larger
> than 1/2^70.
>
> Alternately, if we assume, PLL error-signal drifting is the major concern,
> the probability of running into excessive error is: SUM of P(n,70) +
> P(n,69) + ..... +P(n, x). Where, x is the maximum allowed run-length of a
> PLL.
>
> Either way, the run length is a real issue, of which the probability is not
> much smaller than 10^-12 (BER) to be ignored.
>
> 2. BER 10^-12
>
> For Datacom, BER of 10^-12 is a necessary requirement for file transfers.
> Any compromise in BER will cause through-put reduction across the board
> which will negate the rate advantage(from Gbe to 10GbE), we pay for 10GbE.
> In fact, to maintain the higher rate advantage, 10GbE should have lower BER
> than GbE.
>
> For Telecom, the BER is 10^-10; as a result, the scramble code can fit in.
> I think, if the BER is upgraded to 10^-12, the scramble-code will have hard
> time meeting the BER of 10^-12 in the Telecom equipment. The proposal was
> voted down in ATM_Forum four or five years ago.
>
> It is true that scramble-code is 20% more efficient to save some cost.
> However, the LAN industry is accustomed to block code; therefore, the cost
> to change to scramble-code for 10GbE will far exceed the cost for upgrading,
> than the cost of new design which includes hardware, software, documents,
> and training. I do not believe the money saved by 20% more-efficient code
> can even compensate a small fraction of the cost required to change
> block-code to scramble-code----assume, BER of 10^-12 is still met.
>
>
> It seems to change block-code to scramble-code is much more complex than we
> realize. We should take more time to weigh the differences.
>
> Regards,
>
> Ed Chang
> Unisys Corporation
> Edward.Chang@xxxxxxxxxx
>
>
> -----Original Message-----
> From: Drew Perkins [mailto:drew.perkins@xxxxxxxxxxxx]
> Sent: Tuesday, May 18, 1999 3:05 PM
> To: 'IEEE HSSG'
> Subject: RE: A telephony carrier industry perspective
>
> I'd like to make some proposals that summarizes everything I've seen in the
> last few weeks.
>
> 1. Like previous Ethernets, 10 GbE should have different PMDs for different
> applications. It's easy to imagine very short MMF links (enterprise desktop,
> enterprise LAN, etc.), relatively short SMF links (enterprise risers, telco
> intra-office, etc.), intermediate SMF links (telco inter-office/IR), and
> finally very long SMF links (telco long-haul/LR, etc.). The latter would be
> somewhat new to the IEEE if the IEEE embarks on it, and has previously been
> the domain of more telco-ish standards bodies.
>
> 2. WRT the last one (LR), it seems that:
> a) it will be more cost-effective to use a scrambled encoding scheme
> rather than a block scheme, primarily because the cost of the components
> rise quickly with bandwidth and the cost of scrambling at 10 Gb/s is less
> than the additional cost of 12.5 Gb/s components for a block encoding
> scheme;
> b) we need additional OAM capabilities;
> c) we need very fast protection and restoration at Layer 1, similar to
> SONET APS.
>
> The conclusion that I reach from the above is that 10 GbE for LR
> applications should simply use a standard POS framing mechanism over SONET
> OC192 (or equivalently STM64). If we don't just use SONET, then we'll be
> reinventing a wheel with almost identical characteristics, just different.
> By reusing SONET, not only do we get to declare success VERY quickly, but we
> get to leverage the existing volumes on OC192 components, and at the same
> time increase them, lowering the costs for OC192 itself.
>
> Drew
> ---------------------------------------------------------
> Ciena Corporation Email: ddp@xxxxxxxxxxxx
> Core Switching Division Tel: 408-865-6202
> 10201 Bubb Road Fax: 408-865-6291
> Cupertino, CA 95014 Cell/Pager: 408-829-8298
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Roy Bynum
> Sent: Tuesday, May 18, 1999 8:16 AM
> To: bill.st.arnaud
> Cc: IEEE HSSG
> Subject: RE: A telephony carrier industry perspective
>
> Bill,
>
> We could both be wrong. Unless UUNet is not telling the rest of us
> about what they are doing, every thing they are using the traditional
> TDM/ATM/SONET transport for everything. I have been getting the
> message from UUNet that they consider GbE as "not scaleable". I have
> been doing experimentation with GbE over direct optical, DWDM, and
> SONET WAN systems. I was given the impression that I was the only one
> within MCIW that was working at this level, because I am the only one
> that has the long haul lab systems to do it with. However, it could be
> that they have put in the GbE circuit that you are referring to, but
> are not telling MCI WorldCom about it. I will investigate and let
> everyone know.
>
> Bill, given today's attitude toward IP and the Internet, it does not
> surprise me that institutions such as universities and entire school
> systems are putting in single threaded GbE systems. I know of quite
> a few of them myself. The issue that I am raising for the business
> enterprise systems that are requiring more and more reliable, immediate
> data communications. The major margins for the extending of GbE in the
> WAN environment will come from the business sector. These are going
> to be premium, high quality services. Besides, GbE can carry other
> protocols besides IP. What about high quality services for these?
>
> Thank you,
> Roy Bynum
>
> Date: Tue May 18, 1999 7:12 am CST
> Source-Date: Tue, 18 May 1999 09:05:50 -0400
> Fromm: bill.st.arnaud
> EMS: INTERNET / MCI ID: 376-5414
> MBX: bill.st.arnaud@xxxxxxxxxx
>
> TO: * ROY BYNUM / MCI ID: 424-5935
> CC: IEEE HSSG
> EMS: INTERNET / MCI ID: 376-5414
> MBX: stds-802-3-hssg@xxxxxxxx
> Subject: RE: A telephony carrier industry perspective
> Message-Id: 99051813120991/INTERNETGWDN2IG
> Source-Msg-Id: <NBBBJIMEPHPGCNGAHPMFMEJEELAA.bill.st.arnaud@xxxxxxxxxx>
> U-Importance: Normal
> U-X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
> U-X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> U-X-MSMail-priority: Normal
> U-X-Priority: 3 (Normal)
>
> >
> >
> > Bill,
> >
> > Internet IP will continue to be what the market requirements reflect.
> > Slow restoration times are acceptable in that environment. The UUNet
> > Long Haul GbE is part of what I am doing. I am the one that put the
> > Long Haul Optical switching/Metro DWDM/SONET DATS evaluation of GbE
> > together.
>
> Were you also involved in the UUnet GbE circuit from Quebec City to NY City?
> I was under the impression that link was a pure GbE over dark fiber with
> transceivers ( the one built with 2 guys and a Volkswagen bus). It is my
> understanding that circuit is still UUnet's main IP trunk between Canada and
> the US.
>
> >
> > As a bit irony, dependable GbE is turning out to be less expensive
> > than undependable IP over TDM, ATM, or POS. Unless MPLS comes in a
> > respectable price break, GbE over Native Data SONET DATS will still be
> > less expensive.
>
> No surprise there. The only issue of have with GbE over native SONET DATS
> (e.g. like Nortel InterWAN) is the high cost of repeaters particularly if
> you are dedicating an entire wavelength or OC-192 channel to carrying GbE
> traffic.
> On long haul links in excess of 1000 km the economics of using SONET
> regenerators ( with or without restoral) probably makes sense. But on
> medium range links up to 1000 km, GbE transceivers may make more economic
> sense.
>
> No question SONET currently provides a lot more link state and signaling
> information than currently provided by GbE. But again I question the need
> for fast restoral and protection. Where it is required - GbE over SONET may
> make sense. But many carriers have concluded that Internet links do not
> need SONET restoral and protection services.
>
> > Dependable, high quality transport of Native data traffic such as GbE
> > and 10GbE is probably going to be a different market, one that "best
> > effort" is unacceptable to. If there is a market that provides the
> > profit margin that will sustain 10GbE, it will not be the Internet as
> > it is today.
>
> I disagree. We have many regional networks here in Canada who are looking to
> deploy GbE and 10xGbE networks for their own purposes i.e. to carry
> university traffic. A couple of them already operate OC-48 SONET networks.
> The driver, particularly for the university community is cost. In a
> couple of provinces the cities own the duct work and right of ways so any
> vendor can get access to dark fiber, or install their own at a very
> reasonable cost. The capital cost of the fiber can be amortized over a
> long time period and as such the cost of regenerators and routers becomes
> the most significant cost of the network. GbE switches are significantly
> less costly then POS routers and it is hoped the GbE transceivers will be
> significantly less than SONET regenerators.
>
> Their current traffic requirements are already close to 1xGbE rates. They
> also carry a lot of video over IP between the universities - mostly MPEG.
> But are prepared to suffer the slow recovery of IP for the benefit of low
> cost.
>
> >
> > I do know that I have been given the requirement that carriers can not
> > support a data service over long haul systems that does not provide
> > "SONET like" functionality. The reason that I joined this study group
> > is to provide that insight to the standards developers. If that is GbE
> > or 10GbE over SONET then the issue is already resolved. All that
> > remains is to determine what the LAN application requirements are,
> > then the standard can be defined.
>
> Again I point you to your competitors who have already come to the
> conclusion that "SONET like" functionality is not required other than for
> framing and signaling purposes. e.g Enron, Frontier GlobeCenter, Sprint,
> ATT @Home, Hermes, Ebone, etc
>
> Bill
>
> >
> >
> > Date: Mon May 17, 1999 3:23 pm CST
> > Source-Date: Mon, 17 May 1999 17:17:51 -0400
> > Fromm: bill.st.arnaud
> > EMS: INTERNET / MCI ID: 376-5414
> > MBX: bill.st.arnaud@xxxxxxxxxx
> >
> > TO: * ROY BYNUM / MCI ID: 424-5935
> > Subject: RE: A telephony carrier industry perspective
> > Message-Id: 99051721234042/INTERNETGWDN1IG
> > Source-Msg-Id: <NBBBJIMEPHPGCNGAHPMFIEIJELAA.bill.st.arnaud@xxxxxxxxxx>
> > U-Importance: Normal
> > U-X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
> > U-X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> > U-X-MSMail-priority: Normal
> > U-X-Priority: 3 (Normal)
> >
> > Roy:
> >
> > Again no disagreement. I don't think traditional SONET or ATM
> > networks will
> > disappear. The model we advocate is the same that Frontier is now
> > deploying:
> > IP/DWDM for best efforts, slow restoral traffic on one set of wavelengths,
> > IP over SONET on another set of wavelengths for those services that need
> > fast restoral and security of SONET, and IP over ATM over SONET on another
> > set of wavelengths for fine grained QoS services.
> >
> > I agree with you that the driving force for GbE is cost. It makes a
> > dramatic difference to the overall cost of the network.
> >
> > But I believe GbE can also make an equal dramatic difference on the
> > transport side on medium, long haul links up to 1000 km. Your sister
> > company UUNet has already demonstrated that on some long haul GbE systems.
> > But I agree with you this type of link is probably only good for best
> > efforts IP traffic.
> >
> > Bill
> >
> > -------------------------------------------
> > Bill St Arnaud
> > Director Network Projects
> > CANARIE
> > bill.st.arnaud@xxxxxxxxxx
> > http://tweetie.canarie.ca/~bstarn
> >
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Roy Bynum [mailto:RBYNUM/0004245935@xxxxxxxxxxx]
> > > Sent: Monday, May 17, 1999 4:54 PM
> > > To: bill.st.arnaud
> > > Cc: IEEE HSSG
> > > Subject: RE: A telephony carrier industry perspective
> > >
> > >
> > > Bill,
> > >
> > > I have an IP base video conferencing demonstration application that is
> > > full motion, full resolution. It uses MPEG2 compression and drives the
> > > IP data at 7Mbs bidirectional. Part of the demonstration of the
> > > reliability of GbE over optical and SONET Native Data systems is to do
> > > a simulated fiber break. Over a normal IP network, there is a major
> > > loss of data and thus video synchronization, sometimes the "call" is
> > > even dropped. Over a Native data network, optical or SONET DATS, if
> > > you blink, you miss the cut. It is that kind of traffic path
> > > restoration quality that will be required by future, real time,
> > > visual, and virtual applications. This is the quality of traffic path
> > > restoration that needs to be implemented in Metro/MAN and WAN
> > > environments. I do not believe that any one protocol and/or system can
> > > do that and still be cost effective.
> > >
> > > Fromm looking at Cisco's DPT description, it looks a lot like a
> > > SONET/SDH BLSR ring. In duplicating the alternate path coupled
> > > architecture of SONET/SDH, Cisco could well duplicate the restoration
> > > functionality of SONET/SDH. Although what value it will have over long
> > > haul systems that are geared for very high bandwidth, I am not sure.
> > > Within a LAN environment, that type of restoration is probably not
> > > required. Within a Metro MAN environment, we have found that GbE
> > > combined with optical path protected DWDM is very cost effective.
> > > Cisco will have to come in at a VERY "cheep" cost in order to justify
> > > the deployment of their systems. I expect to have some test systems
> > > before too long. I am looking forward to finding out.
> > >
> > > The bottom line to this is cost. Preliminary evaluations are showing
> > > that GbE already is so cost effective that it is less expensive to
> > > have 10 GbE interfaces on a router than it is to have 4 OC48 POS
> > > interfaces. Combine that with the less expensive interfaces on the
> > > DWDM and SONET DATS equipment it becomes even more attractive. The
> > > capital cost of IP over "Ethernet" or what I am now calling Native IP
> > > is less expensive over a MAN or WAN environment than the existing TDM
> > > WAN systems. 10GbE must compete in this environment. In order for it
> > > to be deployed, it must provide high native data bandwidth, very cost
> > > effectively with the specific service, maintenance, and operations
> > > support that each very different environment requires.
> > >
> > >
> > > Thank you,
> > > Roy Bynum
> > >
> > >
> > >
> > > Date: Mon May 17, 1999 1:07 pm CST
> > > Source-Date: Mon, 17 May 1999 15:02:01 -0400
> > > Fromm: bill.st.arnaud
> > > EMS: INTERNET / MCI ID: 376-5414
> > > MBX: bill.st.arnaud@xxxxxxxxxx
> > >
> > > TO: * ROY BYNUM / MCI ID: 424-5935
> > > Subject: RE: A telephony carrier industry perspective
> > > Message-Id: 99051719074549/INTERNETGWDN3IG
> > > Source-Msg-Id: <NBBBJIMEPHPGCNGAHPMFAEHPELAA.bill.st.arnaud@xxxxxxxxxx>
> > > U-Importance: Normal
> > > U-X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
> > > U-X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> > > U-X-MSMail-priority: Normal
> > > U-X-Priority: 3 (Normal)
> > >
> > > Roy:
> > >
> > > I agree with you that for traditional telecommunications traffic SONET
> > > restoral makes sense. For IP traffic it makes less sense.
> > >
> > > I can assure you we can already do 500 msec restoration on an IP
> > > network by
> > > simpling cranking down the I/F timers. Peter Lotheberg at Sprint
> > > claims he
> > > will be doing 300 msec, again by adhusting the OSPF and I/F
> > timers. CISCO
> > > claims, although we have to yet to test it, that they can do 50
> > msec with
> > > their new DPT product. However, I tend to believe the CISCO claims as I
> > > know most of the engineering team, mostly former SONET engineers from
> > > Nortel.
> > >
> > > Juniper has also promised similar values, but as yet unproven.
> > >
> > > Bill
> > >
> > > -------------------------------------------
> > > Bill St Arnaud
> > > Director Network Projects
> > > CANARIE
> > > bill.st.arnaud@xxxxxxxxxx
> > > http://tweetie.canarie.ca/~bstarn
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Roy Bynum [mailto:RBYNUM/0004245935@xxxxxxxxxxx]
> > > > Sent: Monday, May 17, 1999 12:01 AM
> > > > To: bill.st.arnaud
> > > > Cc: IEEE HSSG; Roy A. Bynum
> > > > Subject: RE: A telephony carrier industry perspective
> > > >
> > > >
> > > > Bill,
> > > >
> > > > I have had some of the "IP over DWDM" systems in a lab at MCI. They
> > > > are not able to restore at SONET speeds because they do not have the
> > > > tightly coupled framing and link maintenance that is incorporated in
> > > > SONET. You would be surprised, as I was, at how much time was added to
> > > > traffic restoration, in addition to the DWDM/Optical path restoration
> > > > time. The fastest traffic restoration was by a "cut-through" GbE
> > > > switch. An IP switch did not come close enough to even be considered
> > > > as "SONET Like" even though it was running POS over DWDM.
> > > >
> > > > Long haul, carrier grade, optical networking requires the same
> > > > traffic protection as well as the maintenance and operations support
> > > > that currently exists in SONET. This is a different requirement from
> > > > the IT industry that drove the existing 802.3 standards.
> > > >
> > > > What some of the other carriers are implementing is "transparent" data
> > > > services. There was a recent magazine that showed that the AT&T,
> > > > Sprint, and GTE offerings are actually ATM with LAN emulation. This
> > > > is not the same as Native data exemplified by GbE.
> > > >
> > > > Don't count too much on the "promises" of IP level restoration. At
> > > > present, 2 minutes path restoration is considered fast. Tightly
> > > > coupling IP traffic restoration to layer two changes the nature of the
> > > > routing protocols as they exist in a mesh or semi-mesh architecture.
> > > > Other than MPLS, which is more for traffic bandwidth reservation,
> > > > there have not been any proposals accepted that change the existing
> > > > protocols. I may be mistaken, but I believe that PNNI Augmented
> > > > Routing (PAR) did not make it beyond RFC Draft.
> > > >
> > > > I hope that this group continues to consider 10GbE as an independent
> > > > protocol. The upper layer protocols, such as IP or IPX, will take
> > > > care of themselves.
> > > >
> > > > Thank you,
> > > > Roy Bynum
> > > >
> > > >
> > > > Date: Sun May 16, 1999 6:04 pm CST
> > > > Source-Date: Sun, 16 May 1999 19:58:37 -0400
> > > > Fromm: bill.st.arnaud
> > > > EMS: INTERNET / MCI ID: 376-5414
> > > > MBX: bill.st.arnaud@xxxxxxxxxx
> > > >
> > > > TO: * ROY BYNUM / MCI ID: 424-5935
> > > > TO: IEEE HSSG
> > > > EMS: INTERNET / MCI ID: 376-5414
> > > > MBX: stds-802-3-hssg@xxxxxxxx
> > > > CC: "Roy A. Bynum"
> > > > EMS: INTERNET / MCI ID: 376-5414
> > > > MBX: roy.bynum@xxxxxxx
> > > > Subject: RE: A telephony carrier industry perspective
> > > > Message-Id: 99051700041309/INTERNETGWDN2IG
> > > > Source-Msg-Id:
> > <NBBBJIMEPHPGCNGAHPMFKEFIELAA.bill.st.arnaud@xxxxxxxxxx>
> > > > U-Importance: Normal
> > > > U-X-Mailer: Microsoft Outlook IMO, Build 9.0.2212 (4.71.2419.0)
> > > > U-X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> > > > U-X-MSMail-priority: Normal
> > > > U-X-Priority: 3 (Normal)
> > > >
> > > > Roy:
> > > >
> > > > Some excellent comments and observations.
> > > >
> > > > One comment I would make is that many carriers are moving away
> > > from SONET
> > > > for restoral and protection for IP traffic. CANARIE, Enron, Sprint,
> > > > Froontier, Teleglobe and many others are building IP/DWDM
> > networks where
> > > > restoral is done at layer 3. MPLS (multi Protocol Label
> > > Switching) is the
> > > > most common implementation of supporting restoral and protection
> > > > at layer 3.
> > > > The vendors claim that we will be able to do restoral at the
> > > same speed as
> > > > SONET - 50 msec for up to 14 nodes.
> > > >
> > > > With layer 3 restoral, the type of transport protocol becomes
> > > > less critical.
> > > > Thus a simple and cost effective data protocol like GbE may be
> > > all that is
> > > > required.
> > > >
> > > > FFor more detailed information on layer 3 restoral please see
> > the white
> > > > papers on our web site at www.canet3.net
> > > >
> > > > Bill
> > > >
> > > > -------------------------------------------
> > > > Bill St Arnaud
> > > > Director Network Projects
> > > > CANARIE
> > > > bill.st.arnaud@xxxxxxxxxx
> > > > http://tweetie.canarie.ca/~bstarn
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > > > > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of
> > > Roy Bynum
> > > > > Sent: Sunday, May 16, 1999 10:55 AM
> > > > > To: IEEE HSSG
> > > > > Cc: Roy A. Bynum
> > > > > Subject: A telephony carrier industry perspective
> > > > >
> > > > >
> > > > >
> > > > > All,
> > > > >
> > > > > As an introduction, my name is Roy Bynum. I work for MCI WorldCom in
> > > > > the Data and Optical Network Technology Development
> > organization. I am
> > > > > late coming to this discussion because of a failure by the telephony
> > > > > industry to recognize GbE as a defacto optical networking
> > technology.
> > > > > My charter was to work on a native optical networking
> > standard for IP
> > > > > services over carrier systems. I came across GbE by accident and
> > > > > friends that work for data systems vendors.
> > > > >
> > > > > Over the last several months, I have been involved in evaluating
> > > > > Gigabit Ethernet (GbE) as a viable data service. The outcome of that
> > > > > is the following observations (I apologize for the length of this
> > > > > memo.):
> > > > >
> > > > > 1. Depending on whom you talk to, 80% to 85% of all data
> > > > > communications traffic in the world originates on
> > "Ethernet" (802.3).
> > > > > The reason for this is a combination of almost commodity
> > prices on the
> > > > > interfaces and very simple operational support requirements, which
> > > > > translates into very low cost of ownership for the return on
> > > investment.
> > > > >
> > > > > 2. Internet Protocol (IP) can operate on most any layer two
> > protocol,
> > > > > and does. However, (again depending on whom you talk to) up
> > to 95% of
> > > > > all IP communications traffic originates on Ethernet. This makes
> > > > > Ethernet the defacto native data communications protocol for IP. The
> > > > > reason for this is economics, as stated above.
> > > > >
> > > > > 3. GbE is following the precedence of Ethernet in that it
> > is very cost
> > > > > effective to deploy compared to other high bandwidth
> > technologies. The
> > > > > cost for GbE, per bandwidth, is anywhere from one forth to one tenth
> > > > > of that of ATM or Packet Over SONET (POS).
> > > > >
> > > > > 4. Dense Wavelength Division Multiplexing (DWDM) is being developed
> > > > > and deployed in the Metropolitan carrier and other fiber optic
> > > > > systems. These DWDM systems have up to 32 wavelengths, with path
> > > > > protection for each. Metro DWDM uses single mode fiber (SMF) over
> > > > > "short" distances, 200km or less. The economics for these systems is
> > > > > turning out to be very favorable as well.
> > > > >
> > > > > 5. Another technology standard is being proposed in the telephony
> > > > > industry that provides for transportation of native data, such as
> > > > > Ethernet, directly over SONET facilities. Data Aware
> > Transmission over
> > > > > SONET (DATS) is the name of that proposal. DATS comes in two types,
> > > > > transparent data, and Native data. The transparent data technology
> > > > > puts ATM SAR switches directly on SONET transport nodes. Native data
> > > > > technology puts Ethernet switches directly on SONET nodes.
> > Native data
> > > > > over SONET was demonstrated last year at Interopt and is
> > also turning
> > > > > out to have some economic benefits.
> > > > >
> > > > > 6. Telephony carrier data communications standards (WAN) today are
> > > > > very different from Information Technology (IT) data communications
> > > > > (LAN/MAN) standards. Telephony standards are circuit based and are
> > > > > concerned with maintaining traffic connection path integrity and
> > > > > quality. IT standards are based on connectionless data with a major
> > > > > emphasis on cost of ownership. Telephony standards have
> > been based on
> > > > > Time Division Multiplexing (TDM) of voice rate (modulo 64kbs)
> > > > > circuits. IT Ethernet standards have developed independently and are
> > > > > based on native data requirements (modulo 10Mbs). Up until recently,
> > > > > the two standards only came together at a router/gateway device that
> > > > > removed the different standards at layer two, leaving the
> > upper layer
> > > > > (layer three and above) data to be communicated. It also means that
> > > > > data traffic path restoration has been dealt with differently by the
> > > > > two industries and standards. This is changing.
> > > > >
> > > > > 7. Telephony carriers have recognized that in a few years
> > the massive
> > > > > bulk of the traffic on their systems will be connectionless oriented
> > > > > native data, not connection oriented voice. Some have also
> > recognized
> > > > > that the services on this traffic are abstracted from
> > software on the
> > > > > end systems, not the facilities based services that provides the
> > > > > profits of today. This means that telephony carriers are
> > looking for a
> > > > > very cost-effective alternative to the TDM systems that
> > they have been
> > > > > using. Many are working, along with vendors on what they refer to as
> > > > > "Optical Networking". This is a combination of very high DWDM
> > > > > wavelength systems (up to 160 wavelengths) and optical
> > switching which
> > > > > provides for direct optical transport of data. I will not
> > go into the
> > > > > economics of what has been developed so far, but it is sufficient to
> > > > > know that this work is being done.
> > > > >
> > > > > 8. SONET/SDH is a very resilient communications standard.
> > It provides
> > > > > for very tightly coupled traffic path restoration, which
> > prevents the
> > > > > unnecessary loss of data traffic connectivity. It provides for very
> > > > > high bandwidth of channelized and concatenated traffic. It provides
> > > > > for operational and maintenance support for 365 day x 24 hour
> > > > > communications services. It is also very expensive, but justified in
> > > > > the many customers, much circuit oriented, bulk traffic services
> > > > > provided by the telephony carrier industry.
> > > > >
> > > > > 9. The loss of traffic path connectivity for high
> > bandwidth, bulk data
> > > > > communications has a much more massive impact than it does
> > with lower
> > > > > or moderate bandwidth communications. As more and more applications
> > > > > utilize more and more data communications bandwidth, the loss of
> > > > > traffic path connectivity will have a business, economic,
> > and personal
> > > > > impact that it did not have on lower or moderate bandwidth data
> > > > > communications.
> > > > >
> > > > > 10. The nature of wide area networking protocols such as IP's OSPFF
> > > > > changes when you move from a telephony circuit based WAN to a common
> > > > > virtual circuit based, layer two switching/bridging WAN. The
> > > > > implications of traffic restoration timers and timing requirements
> > > > > change when moved from a non-broadcast, multiple circuit path
> > > > > architecture to a broadcast domain, single segment
> > architecture. This
> > > > > is not very well understood at the present time. It will
> > take a while
> > > > > for WAN data communications engineers to work out these
> > changes. This
> > > > > will delay, for a short while, the deployment of GbE or 10GbE for
> > > > > enterprise WAN systems.
> > > > >
> > > > > These observations should help provide some insight into the some of
> > > > > the issues being discussed by the HSSG. Whatever is
> > developed must be
> > > > > economical for it to survive. 10GbE is approaching the bandwidth and
> > > > > functionality requirements of the telephony carrier
> > systems. Where it
> > > > > is deployed will have a major impact on what the requirements for it
> > > > > will be. Depending on where it is deployed, it needs to be traffic
> > > > > path resilient and have operational and maintenance support
> > > > > functionality directly within 10GbE. This does not mean that 10GbE
> > > > > could not defined with two standards, one for LAN/MAN, and another
> > > > > that encapsulates the LAN/MAN framing in a WAN transport standard. A
> > > > > LAN standard does not have the requirements of a WAN
> > standard. Many of
> > > > > the WAN requirements can be incorporated in the Metro DWDM
> > systems for
> > > > > MAN services. This could simplify many of the issues of wavelength,
> > > > > power, distance, synchronous or block coding, fiber type,
> > and others.
> > > > >
> > > > > I hope that I can be of some help with the development of this or
> > > > > these standards. It is very critical to the future economics of the
> > > > > carrier data communications industry.
> > > > >
> > > > > Thank you,
> > > > > Roy Bynum roy.bynum@xxxxxxx
> > > > > Sr. Engineer, Data and Optical Networking Technology Development
> > > > > MCI WorldCom
> > > > > (972) 729-7249
> > > > >
> > > > >
> > > >
> > >
> >