Sonet interoperability in the new competitive environment

Sonet interoperability in the new competitive environment

If Sonet is such a great success, then why are some network operators unhappy? Government-mandated interconnect is creating multivendor mayhem.

Brian McFadden, Nortel

And everyone thought that Synchronous Optical Network (Sonet) was doing so well.

Actually, it is. Sonet has made tremendous inroads into fiber-optic transport networks in the last few years. There are more than a half million Sonet network elements (NEs) deployed in the North American grid, and another quarter of a million more Synchronous Digital Hierarchy NEs internationally. The technology standard that promised to push multiplexing standards beyond DS-3 has delivered just that: It has evolved rapidly from an OC-3 (155-Mbit/sec) optical signal to one that leaps over the terabit barrier with 10-Gbit/sec OC-192 and wavelength-division multiplexing. The Sonet NE business is in a market-driven boom and you need sunglasses to see the future.

But then along comes the Telecommunications Act of 1996. Interconnection requirements mandated by the act have service providers running for their Bellcore GR-253 bible on Sonet standards to understand one of the major tenets of Sonet: interoperability. So far, they don`t like what they see. As one operating company executive was quoted as saying at supercomm `97 in New Orleans, LA, "The level of [Sonet] interoperability has not yet penetrated to the extent we would like."

The issue goes beyond mere carrier network management. The Federal Communications Commission`s first order for interconnection defined a minimum set of categories of network elements that incumbents had to unbundle to new entrants to the market, and that included operations support systems (osss). State commissions have taken this one step further by ordering incumbents to provide interfaces for access equal to what the incumbent provides its own retail customers. Indeed, the direction is toward a kind of integration, interconnection, interdependence, and interoperation that the telecommunications industry has never seen before.

Sonet environments, each frequently single-vendor clusters of equipment, are now being interconnected in a tedious process of trial and error. The truth is that not all Sonet NEs are created the same. No wonder Sonet vendors are feeling the heat from their customers. The question customers are asking their vendor is: "What happened to the promise of Sonet interoperability?"

There`s one promise that Sonet has kept: traffic interoperability over mid-span meets. Since the early 1990s, Sonet NEs from different vendors have interoperated over mid-span meets where Sonet payload can be transported without being demultiplexed to a DS-1 or DS-3. This interoperability only requires protection switch compatibility across boundaries. Thus, there is widespread deployment of mid-span meet solutions.

But given the interconnect mandate, it is obvious that mid-span meet alone will not qualify as full Sonet interoperability. Vendors have differentiated their products just enough to keep a proprietary hold on the product and the customer, which has proven frustrating for service providers as they gear up for mandated interconnection and face the prospect of more-costly overlay networks. They are increasingly impatient with the complexity of multivendor Sonet interoperability.

Sonet interoperability is not about standards, but about applications. By itself, Sonet is a standard that serves as a tool to facilitate the evolution of fiber-optic networks, which happen to contain ever more intelligent NEs and more-demanding applications. The Sonet challenge is to overcome the applications barriers in ne-to-ne interfaces and the ne-to-oss limitations of systems network architecture. The solution isn`t to reform Sonet; it is to overcome NE architecture that is traditionally the domain of proprietary technology and has kept Sonet NEs sufficiently distinct. This is why service providers with legacy osss and older Sonet NEs--in particular the incumbent local exchange carriers--are finding the transition into the new interconnect reality very difficult indeed. Hence, they are putting pressure on vendors to come up with solutions.

The role of the SIF

The desire for interoperability at the application layer is what is driving the Sonet Interoperability Forum (sif), a voluntary vendor/user working group begun in 1995 under the umbrella of the Alliance for Telecommunications Industry Solutions (see figure). Service providers` hopes for meaningful resolutions to interoperability issues are such that sif requirements are already appearing in contracts.

Yet the sif can do only so much. For instance, the remote login group has successfully defined a requirements document for a remote login application based on the Open Systems Interconnection (osi) seven-layer stack, yet no vendor adheres to this standard completely. Individual vendors are proceeding with their own efforts to make their NEs interoperable with other vendors` NEs, sometimes one vendor at a time, one application at a time. Still, the fact that vendors are prepared to make seven different vendor NEs work on a dual ring suggests they are taking to heart the new reality of the post-reform telecommunications business.

The first level of Sonet interoperability is traffic, where few vendors have difficulty. This corresponds to compatibility at Layer 1 of the osi model.

The second and third levels concern the data communications channel (dcc). The Sonet standards bodies decided that two embedded channels in the basic format, i.gif., section dcc and line dcc, would be used for operations, administration, maintenance, and provisioning (oamp) communication between network elements and operations systems and among network elements. This would avoid an expensive overlay for an oamp communications network. The full seven-layer osi protocol stack would be used for this dcc network, where transaction-oriented messages would be specified and communicated.

Routing, or the basic exchange of messages over the dcc, is the second level of interoperability, which corresponds to compatibility up to Layer 3 of the osi model. Using either transaction language 1 (TL-1) or common management information service element (cmise), queries are routed to Sonet NEs, and the responses are routed back to the oss.

Headway is being made to achieve this level of interoperability. For example, demonstrations held at past National Fiber Optic Engineers Conference and supercomm events showed a Tellabs Titan 5500 crossconnect passing dcc messages between two Nortel OC-3 Express terminals, and the OC-3 Express routing between two Titans. Crossconnect assignments were changed, and a DV45 video source provided additional proof of successful second-level dcc interoperability.

Application interoperability, or the use of network management applications over the dcc, corresponds to Layer 7 of the osi model and is the third and most complex layer of Sonet interoperability. At this level, the dcc goes from being the passive router channel of the previous level to being an interactive, integrated network enabler. This capability is key, since it holds the promise of fast deployment of new services anywhere, anytime. It is the most complex level because it involves oss interoperability using both TL-1 and Q3 interfaces in oss management domains using legacy and/or telecommunications management network-based technology. Bellcore`s ocat protocol testing software is a useful osi-based compliance tool for interoperability evaluations.

Solutions today

While integrated Sonet oamp will need time to evolve, vendors are already beginning to deliver solutions to meet the tremendous market pull--as the Nortel/Tellabs demonstrations illustrate. Sonet interoperability at the applications level appears headed toward the latest distributed technology proposed by the object management group and Network Management Forum. Applications using the building block approach based on the application protocol interface appear ready to adopt standards such as corba`s interface definition language. (corba, or Common Object Request Broker Architecture, is a standard from the object management group for communicating between distributed objects.) Given the success of distributed applications in the computer world, it would seem the future of mixed-architecture Sonet NEs in the telecommunications grid is also likely to be based on open architecture.

Meanwhile, all vendors must cope with an issues compliance matrix that is beginning to emerge and will surely measure a vendor`s efforts to achieve interoperability. It includes dcc domain size (domain size affects the dcc`s ability to handle the data, e.g., a domain of 30-40 NEs will have difficulty handling data from a domain of 150 NEs); Level 2 routing (the solution for the domain problem); TL-1-based versus cmise-based approaches; use of standard addressing; support for target ID address resolution protocol; X.500 standards to perform name-to-address translations; and finally, support for the full osi seven-layer stack.

In general, vendors need to focus their efforts on the large installed base of older, lower-speed (OC-3) Sonet NEs. Given the tremendous pressures generated by mandated interconnect, the pressure point on the network is at this level. Faced with making crucial network decisions, network operators are looking to the vendor to bring much-needed relief.

They are looking for vendors to deliver the promise of Sonet. u

The Sonet Interoperability Forum held a demonstration at last June`s supercomm show, which not only showed interoperability among Sonet network equipment, but the abilities of network management solutions as well.