RE: The myth that SONET is an interoperable standard

[Roy Bynum <Roy.Bynum@xxxxxxxx>]

Drew,

In working with different router vendors that OC48 POS interfaces, and
different SONET/SDH transmission systems vendors, the only real
interoperability issues has been between SONET and SDH.  There have
been some issues with individual, user definable bytes that get addressed
in configurations, but very little that has been a "show stopper".
This is because the OC48 router hands off a "standard" interface to
the transmission systems.  

Within each SONET/SDH vendor's domain, each has its own OAMP
implementation, allowing for market feature differentiation. Also,
other functionalities are sometimes proprietary. Somehow, when handing
off between the vendors the data steam does not become garbage.  This
is because there is a minimum interface standard.

OC192 DWDM technology today is still in a state of major innovation.
Each vendor is doing development work that can potentially have a
major equipment or operations cost savings or increase in bandwidth
density. Each of these innovations are proprietary to each of the
vendors that develop it.  Each vendor is attempting to get customers
to "standardize" on their proprietary technology, forcing other vendors
to license the technology.

The only consideration, when a data stream is handed off between one
vendor and another, is that both adhere to the same interface
standard. This is no different than the continuing innovation that
exists in the LAN technology environment. For example, if a vendor
comes up with a new way of implementing flow control to the desktop,
it will only interoperable between their data switches and their
interface cards. When the data steam is handed off between different
vendors data switches, the proprietary innovations are turned off,
leaving the standard interface between them.

The development of 10GbE, in the long term, will be no different. What
is important is that a standard, minimum interface is defined that
will support all of the users requirements, low initial cost, long
functional life, and operationally inexpensive for a given data
bandwidth and size of implementation.

Thank you,
Roy Bynum,
Optical and Data Network Technology Development,
MCI WorldCom 


Date:     Fri Jun 25, 1999 12:21 am  CST
Source-Date: Thu, 24 Jun 1999 23:24:16 -0700
From:     Drew Perkins
          EMS: INNERMAIL / MCI ID: 208-7612
          MBX: drew.perkins@xxxxxxxxxxxx
 
TO:       "'Bill.St.Arnaud@xxxxxxxxxx'"
          EMS: INNERMAIL / MCI ID: 208-7612
          MBX: Bill.St.Arnaud@xxxxxxxxxx
TO:     * Roy Bynum / MCI ID: 424-5935
CC:       'nuss'
          EMS: INNERMAIL / MCI ID: 208-7612
          MBX: nuss@xxxxxxxxxx
CC:       'HSSG_reflector'
          EMS: INNERMAIL / MCI ID: 208-7612
          MBX: stds-802-3-hssg@xxxxxxxx
Subject:  RE: The myth that SONET is an interoperable standard
Message-Id: 99062506212757/INTERNETGWDI2IG
Source-Msg-Id: <2072E1221F1DD211848C00104B938E7B566D97@xxxxxxxxxxxx>
U-Content-return: allowed
U-X-Mailer: Internet Mail Service (5.5.2448.0)
 
Please excuse me, but I would like to respond to a number of myths and
untruths that are being thrown around here.

1. The statement about SONET (not) being interoperable is partly true, and
partly untrue. SONET has a very well standardized frame format to which
almost all systems adhere. There are many functions beyond simple framing
that are made available through a number of elements of the protocol. The
most basic of these are always made interoperable. Some of the more complex,
in particular network management protocols, are still rarely interoperable.

On the one hand, the interface between end-systems and the SONET network is
intentionally simplified because it needs fewer functions. These interfaces
are very very interoperable. Many companies build switches of all kinds that
interoperate successfully with SONET equipment of all kinds.

On the other hand, the interface between nodes in a SONET subnetwork uses
all of the functions. Subnetworks in this environment are almost always
purchased from a single vendor. Thus there is rarely interoperability at
what's called the "mid-span meet" in long-haul systems.

Metro-area systems tend to be somewhere in the middle. There is a great deal
of interoperability here. The non-interoperable portions tend to be more in
the long-haul at this point.

The long-haul mid-span meet is also complicated by the fact that it is
usually using the latest and greatest technology where the standards have
not caught up (it can be separately debated as to why standards aren't out
ahead of this, but I won't venture there for the moment). In particular,
long-haul SONET and DWDM systems (in many products it is impossible to
separate the two technologies) use rapidly-changing DWDM technology, and in
some cases unstandardized FEC algorithms.

2. I am not aware of any vendor using 'a proprietary "hello" protocol to
signal for node failure (as opposed to path, link or section failure)'.
These systems all use the SONET k1/K2 protocol in a relatively standard and
increasingly interoperable fashion. Bill, please explain what you mean by
this.

3. Device managements, stats and OAMP mostly use proprietary Network
Management (not signalling) protocols. These are typically in-band using the
standard SONET DCC, not a proprietary out of band systems.

4. MPLS will not have faster restoration speed than SONET. This is poppycock
(does anyone know where this phrase originated?). The SONET protocol is
highly optimized for very fast restoral by limiting the topology to a simple
ring. SONET gives 60 ms restoration in long-haul (not metro) 1,200 km rings.
MPLS is NOT going to achieve this except in similarly limited situations.

5. The comments about ITU standards for DWDM are indeed correct. There is a
standard for the spacing between wavelengths, and for a reference point. But
there is no standard for how many wavelengths, where the ends of the
spectrum are, what the power levels are, what the signaling format is, etc.

6. The criticisms of the OIF are entirely unfounded. I happen to be the Vice
Chairman of that organization. Roy, I invite you to become involved with the
OIF so that you can get an accurate view before you take the liberty of
speaking ill about it. Your concept of the OIF's mission is highly skewed
for some reason. The OIF's mission is to bring together datacom and telecom
experts in one location (which has previously never been done) in order to
lower the cost of equipment for the benefit of carriers and other customers.
There are a number of very exciting projects underway in the OIF that are
going to have effects on the industry comparable with the current 10 Gb/s
Ethernet effort.

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 Bill St.
Arnaud
Sent: Thursday, June 24, 1999 9:18 AM
To: Roy Bynum
Cc: nuss; HSSG_reflector
Subject: RE: The myth that SONET is an interoperable standard



Roy:

One of the great myths in the networking world is that SONET is an
interoperable standard.  It is only an interoperable standard between back
to back ADM nodes.  I don't know of any SONET/SDH systems that will
interoperate at the transport level.  Let me give you a few examples of why
this is so:

1. On most OC-192 (and some OC-48) systems vendors have implemented
different proprietary types of FEC
2. Every vendor uses a proprietary "hello" protocol to signal for node
failure (as opposed to path, link or section failure)
3. Device managements, stats and OAMP uses proprietary signalling
protocols - most use proprietary out of band systems
4. The ITU grid only establishes the wavelength frequencies.  There is no
standard for optical modulation technique, power levels, wavelength spacing
and optical system management

In the optical Internet we built across Canada  (CA*net 3)we encountered all
sorts of problems between equipment vendors who claimed to have supported
that latest SONET specs (which they did) - but the equipment would still not
interoperate.  To handle the OAMP  issues we had to build custom digital
cross connects (DCCs) around each router and other vendor's SONET equipment.
We also turned off most of the "standard" SONET signalling features in the
routers and regen equipment to avoid other problems.

Once we have MPLS installed in our network that will support restoral and
protection switching at layer 3, at speeds possibly faster than SONET, all
we need is a very simple transport protocol such as 10GbE.  SONET just gives
us grief.

As I mentioned before most of this is anathema to most carriers and I very
much doubt that traditional carriers will deploy native 10GbE networks.
Given our experience with CA*net 3 I see little need for any additional OAMP
beyond what is currently available in the GbE spec.

However, as we gain further experience with a couple of the 4xGbE CWDM
networks we are now in the process of deploying (700 km and 1700km
respectively) we will have a better feel on what OAMP features are important
and essential.

Bill




> -----Original Message-----
> From: Roy Bynum [mailto:Roy.Bynum@xxxxxxxx]
> Sent: June 23, 1999 11:53 AM
> To: Bill.St.Arnaud
> Cc: nuss; HSSG_reflector
> Subject: RE: 10GE data rate and OAMP issues
>
>
> Bill,
>
> I am not sure where you are having interoperability problems at the
> SONET/DWDM level. The SONET OAMP byte definition standard is in
> BellCore GR253. The DWDM optical wavelength grid standard has been
> defined by ITU. SDH is non-North America standard developed by ITU
> after SONET was developed.  There are some issues with attempting to
> use the same interfaces with both SONET and SDH transport systems.
> Those issues are being addressed outside of OIF.
>
> I have had many conversations with the MCIW representatives to OIF.
> (They are part of the same organization that I am in.) From what I can
> gather of OIF, it is actually an attempt by various vendors to alter
> the existing optical transport technology in ways that they can profit
> it more than they currently can. This is the same thing that I found
> at SIF when I was attending that. Most of what these people are
> proposing are proprietary solutions to issues that I and others in
> the industry have already addressed. The biggest issues are
> inter-service functionality between the various carriers, not
> interoperability of the transport protocols. OIF and SIF are no where
> near being as specific task focused as IEEE 802.3 is. The 802.3 WG
> will be much better able to define and make sure of an interoperable
> standard than OIF or SIF.
>
> Things like Cisco's DPT might leverage the fiber plant to provide some
> cost savings. Other things like the proposed "SONET Lite" or "SDL"
> provide so little bandwidth advantage that the additional cost of
> implementation is not worth it. With the advent of SONET/SDH shared
> bandwidth rings running mapped 802.3 with VLANs, I don't think that DPT
> will see much market advantage, particularly since Cisco is so
> late with it.
>
> I was involved with the original OC3/STM4 POS interface development. I
> had an OC3/STM4 POS interface in an international system several years
> ago. That interface was one of the reasons that Cisco was picked as
> the prime data transport vendor for the Avantel project in Mexico. The
> only consistent issue between the POS interfaces and the SONET/SDH
> transport systems has been the use of line timing for sync instead of
> an external stratum clock source. That issue is addressed by turning
> off the path sync alarms on the provisioned SONET/SDH transport systems.
> I do not see any problems for a SONET/SDH version of 10GbE.
>
> People that use the existing GbE over MAN and WAN systems will have to
> come up with their own proprietary methods of doing operational
> maintenance and performance monitoring. There are no "hooks" or
> "digital optical service overhead" provided in the existing GbE for
> that functionality. Long term, GbE is going to be very expensive to
> maintain over MAN and WAN systems. As the GbE MAN and WAN
> installations age they will require a lot of manual intervention and
> "maintenance outages" to remain operational. As the users start using
> more 7X24X365 time critical applications, the service outages of GbE
> MANs and WANs will become unacceptable. These are issues that
> end-system data service providers and vendors have never had to deal
> with before. This is an issue that HSSG does have to address in 10GbE.
>
> Thank you,
> Roy Bynum
> MCI WorldCom
>
>
>
>
> Date:     Wed Jun 23, 1999  8:51 am  CST
> Source-Date: Wed, 23 Jun 1999 10:49:11 -0400
> From:     Bill.St.Arnaud
>           EMS: INNERMAIL / MCI ID: 208-7612
>           MBX: Bill.St.Arnaud@xxxxxxxxxx
>
> TO:       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:  RE: 10GE data rate and OAMP issues
> Message-Id: 99062314514173/INTERNETGWDI2IG
> Source-Msg-Id: <NBBBJIMEPHPGCNGAHPMFEENAEOAA.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.0810.800
> U-X-MSMail-priority: Normal
> U-X-Priority: 3 (Normal)
>
> >
> > 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.
>
> As far as I know in the SONET/DWDM world there does not yet exist any OAMP
> standards.  These are all proprietary to the various manufacturers.  Yes,
> there does exist numerous bytes in the SONET header for signalling of
> protection switching, etc.  But interoperability at the transport level
> remains a challenge, never mind OAMP interoperability.  The
> Optical Internet
> Forum (OIF) has been working very hard to develop standards in this area.
>
> In my opinion it would be unwise at this time for HSSG to venture
> into this
> area as so there so many complexities and conflicting priorities.
>
> Traditional carriers have very demanding requirements for OAMP
> which may be
> significantly more stringent than that required for
> non-traditional carriers
> who may want to deploy low cost medium haul GbE links.  I don't know of a
> single traditional carrier who plans to deploy native GbE on
> medium or long
> haul links.  I suspect traditional carriers, in most cases, will map 10GbE
> to SONET for long haul (and even short haul) applications where they can
> take advantage of  well known OAMP tools.  A number of vendors are already
> offering products that map GbE ( and soon 10GbE) to SONET
>
> Non-traditional carriers such as regional networks, ISPs, etc have 2
> choices:
>
> 1. Carrying GbE on data transparent networks and using OAMP tools at the
> optical level (a couple of products are already on the market in
> this area)
>
> 2. Carrying native GbE on dark fiber and using proprietary OAMP techniques
> combined with SNMP
>
> Bill
>
>
> >
> > 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
>