RE: The myth that SONET is an interoperable standard

["Bill St. Arnaud" <Bill.St.Arnaud@xxxxxxxxxx>]

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
>