RE: The myth that SONET is an interoperable standard

[Andrew Smith <andrew@extremenetworks.com>]

Drew,

I don't know much about SONET (and neither does the OED, although it does
have "son et lumiere": there's got to be a new networking startup name in
there somewhere ...)  but POPPYCOCK is a mid-19th centruy corruption of the
Dutch dialect 'pappekak' which means "soft dung".

Hoping that helps reach consensus in this illuminating debate,

Andrew


-----Original Message-----
From: Drew Perkins
To: 'Bill.St.Arnaud@canarie.ca'; 'Roy Bynum'
Cc: 'nuss'; 'HSSG_reflector'
Sent: 6/24/99 11:24 PM
Subject: RE: The myth that SONET is an interoperable standard


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@lightera.com
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@majordomo.ieee.org
[mailto:owner-stds-802-3-hssg@majordomo.ieee.org]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@wcom.com]
> 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@canarie.ca
>
> TO:       nuss
>           EMS: INNERMAIL / MCI ID: 208-7612
>           MBX: nuss@lucent.com
> TO:     * Roy Bynum / MCI ID: 424-5935
> TO:       HSSG_reflector
>           EMS: INNERMAIL / MCI ID: 208-7612
>           MBX: stds-802-3-hssg@ieee.org
> Subject:  RE: 10GE data rate and OAMP issues
> Message-Id: 99062314514173/INTERNETGWDI2IG
> Source-Msg-Id:
<NBBBJIMEPHPGCNGAHPMFEENAEOAA.Bill.St.Arnaud@canarie.ca>
> 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
>