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.