|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SONET Interconnect (was RE: MCI)
Bharat, > 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. (see http://www.atd.net/atdnet.html). 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 issue. 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. Shikhar
|