SONET Interconnect (was RE: MCI)

Shikhar Bajaj bajaj at
Tue Mar 26 15:48:34 UTC 1996


> Has there been any thought given to How the OC-3c signal from a router
> will be connected to a OC-48 or 192 signal in a typical SONET ring?

Currently, the only way of doing this is the "traditional way" of using
SONET add-drop muxes to get you up to higher rates.  You mux the STS-3c into
an STS-12 and then mux the 12's into a STS-48. This is what we are doing
in ATDNet which is a ATM OC-48 bidirectional line-switched ring for ARPA and DoD.

As per our previous discussion, the trend seems to be putting the switching
and transport functions in one box so that you may be able to buy an
ATM switch that also does SONET protection switching.   

> I would think that the SONET vendors (Alcatel, Fujitsu, etc) would have to
> work with the router vendors to ensure that SONET overhead information
> is passed properly to the higher level signal. This overhead provides
> data on performance, net management, etc. The kicker here is that SONET
> contains undefined overhead bytes that many vendors have used for
> proprietary services. This is the reason why different vendors'
> equipment cannot be mixed within the same ring. The CMISE set of
> standards is supposed to take care of incompatibilities, but as with any
> other standard, it will be complete years from when it is needed.

The SONET standards (at least for frame and overhead) generation are well 
documented so that router vendors, theoretically, should not need to work
with traditional SONET vendors to get transport and framing functionality.
For ATM over SONET, there are also a number of chips/chipsets which will perform SONET 
framing.  PMC-Sierra (which FORE Systems uses) and IGT immediately come to mind (and I
know that I have missed some others).  Of course, if a router and SONET vendor
want to work together to also offer some value-added functionality, that is an

You are entirely correct that many vendors have used the undefined overhead 
for proprietary services.  The most common overhead used are the growth
bytes (Z-bytes) and DCC bytes (D-bytes).  In many cases, those bytes are used to pass
proprietary messages for network element control and maintainance.  That is a
major reason why you don't see multiple vendors on the same ring.  More than
likely the transport would work fine but the OAM would be a nightmare.

If and when the vendors fully implement CMISE, that would solve a lot of headaches.
Until then, we have to deal with a mixture of partial CMISE support, proprietary
interfaces, and TL-1 (Transmission Language-1, an old Bell System management 
protocol).  In lieu of this (and other factors), it is not surprising that
strategic partnerships between carriers and vendors are so common.


More information about the NANOG mailing list