Re: 10GE data rate?

[Roy Bynum <Roy.Bynum@xxxxxxxx>]

Martin,

In answer to your questions:

1) In order to provide problematic traffic/route protection on the
OC192C MPLS interfaces, the router vendors are going to be using the
SONET/SDH OAM functionality. MCIW engineering in Richardson and Tulsa
are working with the vendors to develop a standard that will operate
for both SONET and SDH. Beta versions of these interfaces are expected
from the vendors late this year. The high restoration speeds that MPLS
is promising over OC12C and OC48C interfaces is due to using the
existing L1 SONET/SDH OAM functionality, not some "magic" at L2 or L3.

UUNet is indicating that they will be using protected transport at the
line and segment level with path protection at L3. This allows for
maintenance of the fiber facility, fiber repairs, and other
operational support functions without effecting the traffic at L1/L2.
Nodal and router issues are still handled at L3. 

2)  By utilizing existing transport technology and functionality, a
fully operational OC192C/STM64-BaseXX interface could be on the market
as early as fist quarter next year.  I understand that the OC192/STM64
chip set has not been migrated to silicon yet, so the first interfaces
would be expensive.  As soon as the chip/ASIC migration takes place,
this will become much cheaper.  By using the same L1 interface standard
as MPLS, it will be fully functional over carrier WAN systems from
day one.

3)  The problem with simply adding control fields to a non-WAN transport
rate is that the existing OEO WDM/DWDM and regenerators will not be
able to support it.  A totally separate communications system will
have to be implemented to support that alternative rate.  This will
be very expensive; something that the carriers will not want to do.


There are DWDM vendors that provide transport for GbE over WAN distances
today.  They do not however provide signal clock recovery so the distances
between discrete L2 switches is limited.  Some of the Metro DWDM vendors
do provide clock recovery and some fiber span protection switching,
but can not provide protection for bit errors due to a failing transmit
laser.  These are major extended cost of ownership issues that come
into play over a period of time.  Without operational functionality,
existing GbE MAN/WAN systems will be very expensive to maintain toward
"end of life", or sooner if there is a fiber problem. 

While most people look at the WAN interfaces today and see them as
being very expensive. They do not see the cost savings that the
additional functionality provides. Part of the expense is the limited
market. Part of the expense is the leading edge technology that the
higher speed interfaces utilize. Only part of the expense is the
additional functionality. 

The additional WAN functionality exists in all WAN interfaces today.
For the most part, the router/bridge user does not see it. This allows
service operators and carriers to maintain the fiber and transport
system without major daily "maintenance outages". It also tends to
prevent the users being down for days/weeks when there is a major
fiber cut.

While I am not pushing the idea that WAN OAM functionality be pushed
down to the LAN, there are some things to think about that could
shorten the time to market for 10GbE. The OC192 SONET/SDH ASIC
technology is already fairly mature. I have been told that migration
of OC192 to silicon will happen very soon, reducing the cost. The
mapping of 802.3 framing into the SONET/SDH payload has been around
for several years. For LANs the SONET/SDH overhead can be default
values, without any processing required at L1/L2. The scramble encoded
OC/STM-BaseXX will run at a lower signal bit rate than the block
encoded full 10G-BaseXX will, making the silicon less expensive.
(Signal speed and latency are directly related to geometry sizes.) The
more that I think about it, allowing a shift from the artificial
requirement for exact modulo 10 data rates may provide for a "WAN
rate" version of GbE that could be less expensive than the "LAN rate".

Thank you,
Roy Bynum
MCI WorldCom





Date:     Tue Jun 22, 1999 12:44 pm  CST
Source-Date: Tue, 22 Jun 1999 14:40:34 -0400
From:     nuss
          EMS: INNERMAIL / MCI ID: 208-7612
          MBX: nuss@xxxxxxxxxx
 
TO:     * Roy Bynum / MCI ID: 424-5935
TO:       HSSG_reflector
          EMS: INNERMAIL / MCI ID: 208-7612
          MBX: stds-802-3-hssg@xxxxxxxx
Subject:  10GE data rate?
Message-Id: 99062218441187/INTERNETGWDI1IG
Source-Msg-Id: <376FD8A2.916CFD48@xxxxxxxxxxxxxxxxxxx>
U-Organization: Bell Labs - Lucent Technologies
U-X-Mailer: Mozilla 4.51 [en] (WinNT; I)
U-X-Accept-Language: en
 
Roy:
I wanted to get your expert opinion on a few issues that would be of
interest to me as we go forward in the standard:

1) do you really believe that we need to support all the WAN OAMP
features in 10GE?  I would rather prefer a light-weight 10ge protocol
that guarantees the lowest cost in the LAN, but make sure that it can be
wrapped easily into a WAN envelope to support all the WAN features.

2) at the last meeting, Paul Bottorff as well as Mike Salzman presented
approaches to a serial 10GE standard based on scrambling as opposed to
block coding.  Both of these could be used for a low-cost serial LAN
standard, and wrapped into WAN envelopes like SONET to provide WAN OAMP
features.  The 10GE data rate would have to be kept to around 9.6 Gb/s
to make that possible at the lowest cost.  Presumably, that would
accelerate the acceptance of 10GE in the WAN.

3) Alternatively, we could propose to allow for additional control
fields in the 10GE standard that duplicate the functions most important
for WAN apps.  This may be the cleanest solution, but it will require
802.3 to venture into an area that it has not worried about before...

Any thoughts?

Martin
begin:vcard 
n:Nuss;Martin
tel;fax:(732) 949-2473
tel;work:(732) 949-5358
x-mozilla-html:FALSE
org:Bell Labs - Lucent Technologies;Optical Enterprise Networks Research
adr:;;101 Crawfords Corner Rd.;Holmdel;NJ;07733-3030;
version:2.1
email;internet:nuss@xxxxxxxxxx
x-mozilla-cpt:;-1
fn:Martin Nuss
end:vcard