RE: A telephony carrier industry perspective
- To: "'Chang, Edward S'" <Edward.Chang@xxxxxxxxxx>, "'IEEE HSSG'" <stds-802-3-hssg@xxxxxxxx>
- Subject: RE: A telephony carrier industry perspective
- From: Drew Perkins <drew.perkins@xxxxxxxxxxxx>
- Date: Tue, 18 May 1999 20:45:09 -0700
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Ed,
Other telco standards bodies (T1X1, IETF, etc.) are already dealing
with these issues. There is no need for the IEEE to reinvent new solutions.
With respect to the cost of scrambling hardware, the cost is trivial
compared with the cost of WAN line systems (DWDMs, optical amplifiers,
low-chirp wavelength-locked transmitters, etc.). In fact, the cost of those
all go up with the bit rate, or worse the square of the bit rate. I'm not
sure what software would be changed, but the cost of documentation and
training would go up with a new block-coded system since this is not the LAN
industry we're talking about, it's the telco industry, and they are already
very familiar with OC192/STM64.
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 Chang,
Edward S
Sent: Tuesday, May 18, 1999 3:06 PM
To: Drew Perkins; 'IEEE HSSG'
Subject: RE: A telephony carrier industry perspective
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
> > > >
> > > >
> > >
> >
>