In search of Sonet interoperability
Basic synchronous optical network transport interoperability has been achieved, but full operations interoperability efforts have just begun
Jeffrey A. Ross
Bell Communications Research
Synchronous optical network standards were created to provide an interface that would be common for all fiber-optic transport equipment. There are, however, small problems to overcome. If a Sonet payload is put into a supplier`s network element, it can usually be extracted from another supplier`s network element across a mid-span meet. The elements can communicate across the optical or electrical interface. More complex Sonet architectures, such as equipment used in a Sonet bidirectional line switched ring, cannot guarantee transport interoperability for some time.
Operations interoperability is still in its infancy. The standards are in place, and the development of the open systems interconnection protocols is proceeding steadily. This common protocol stack on the Sonet direct communications channel and local area network allows the transport of management information between Sonet network elements and their management systems, even when the information must be carried over other suppliers` network elements.
Full operations interoperability, however, requires implementation of common management information service elements and the Sonet information model in both management systems and network elements. These systems might be available this year, but time will be needed for interoperability testing as the protocols and information model settle out. At that point, fully interoperable Sonet networks should be deployable. Sonet standards were created to provide a common interface for all fiber-optic transport equipment. Sonet network elements are available from several suppliers, but whether they can interoperate is still questionable.
Transport standards
For more than a decade, fiber-optic systems have been deployed in large quantities throughout telephone company networks. A standardized optical interface was needed, and the Sonet concept was therefore invented by Bell Communications Research. The family of Sonet specifications includes a set of standard rates and formats, as well as optical and electrical interface parameters. The Sonet specifications call for a mid-span meet between carriers, or a meet among Sonet equipment from different suppliers within a single carrier`s network.
The first version of the Sonet standard was produced in 1988, coincident with the synchronous digital hierarchy international standard that effectively includes Sonet. Later standards refinements solidified the specifications of optical line systems and optical interfaces. Electrical interfaces are specified for low Sonet speeds for intra-office interconnections. Current optical and electrical specifications promote inter-supplier connectivity at either optical or electrical line rates.
Although several rates were initially defined, a few key optical signal rates have emerged: OC-1 at 51.84 megabits per second, OC-3 at 155.52 Mbits/sec, OC-12 at 622.08 Mbits/sec and OC-48 at 2.488 gigabits per second. A new rate of OC-192 at 9.953 Gbits/sec is being addressed by the standards bodies, but a mid-span meet at this rate is not soon likely. Moreover, low-speed Sonet virtual tributary rates are being developed in standards.
The other critical aspect of Sonet is formatting. Because high-speed Sonet signals are created by byte-interleaving low-speed Sonet signals, the basic structure of formatting is consistent throughout the different rates. However, with continual specification changes of some functions within the format, interoperability issues naturally arise.
Strong efforts are usually made by some standards members to preserve backwards compatibility whenever Sonet standards are changed. Backwards compatibility means equipment built to earlier versions of the standard will interoperate with equipment built to more recent versions of the standard.
For example, the original Sonet specifications called for an STS-ID byte that identified the time slot occupied by each STS-1 in the Sonet STS-N signal. Originally, this byte was important for framing when high-speed Sonet signals were expected to be created by bit-interleaving tributary signals. Later, it was not needed when Sonet moved to byte interleaving. In the STS-N signal, these STS-ID bytes have been replaced by a section trace byte in the first STS-1 and in the remaining STS-1s by growth bytes, that is, bytes reserved for new functions that may be standardized in the future. The value of the section trace can be set by the network operator, with a default value for it (and for the new growth bytes) consistent with the STS ID, so new and old equipment can interoperate.
The line overhead contains other growth bytes. One of these is used for the transmission of a line far-end-block-error count. When the far end detects bit-interleaved parity errors, the line FEBE returns the number of parity errors in that frame to the near end. When both line terminations support the line FEBE function, and if neither line termination supports the line FEBE function, no interoperability issues emerge. However, if one line termination supports line FEBE and the other does not, interoperability problems might arise.
These problems can be minimized, though, if suppliers follow the Bellcore requirements, which maintain that transmitters place all zeros in an undefined byte and receivers ignore the contents of such a byte. In this setup, the line termination without the line FEBE function ignores the incoming line FEBE values and places zeros in the line FEBE byte on the outgoing signal. Therefore, no line FEBEs are recorded at the other termination.
The new function cannot be used because the older equipment does not support it. However, no alarms are generated, and no other problems should arise. In this case, Bellcore`s additional requirements promote backwards compatibility.
Changes have been made to the standard for which backwards compatibility cannot be maintained. One such change concerns the meaning of a bit in the path status byte. Asynchronous transfer mode mapping into Sonet uses the remote defect indication path status bit to signal the loss of cell delineation. The remote defect indication signal is being changed from one to two bits, and the additional second bit will be used for signaling loss of cell delineation. Thus, new asynchronous transfer mode equipment will not be able to signal older ATM equipment about loss of cell delineation because the older equipment will not recognize the new signal.
Backwards compatibility for new overhead definitions has always been an issue, even for earlier network technologies. Consider the DS-1 extended superframe, a frame format developed in the 1980s, which now coexists with the older DS-1 superframe format, or examine DS-3 C-bit parity--a new version of the DS-3 frame format. Sonet will undoubtedly continue to change, or at least expand, as new functions are identified for the available overhead. The goal is to minimize the negative effects of backwards incompatibility on networks and equipment.
Other transport interoperability issues go beyond small format changes. For example, significant format changes might be architecture-dependent. Specifically, the new automatic protection switching protocol for the bidirectional line switched ring uses the automatic protection switching overhead bytes in a different manner than it does for linear protection. Although bidirectional line switched ring and non-bidirectional line switched ring equipment are not intended to interoperate over high-speed optical interfaces, bidirectional line switched ring equipment from different suppliers eventually needs to interoperate. However, because the bidirectional line switched ring automatic protection switching protocol is complex, time and experience are necessary before interoperability of bidirectional line switched ring equipment can be ensured.
Operations standards
The operations section of the Sonet standard attracts the most attention when interoperability issues are raised. Three bytes in the section overhead are reserved for a section data communications channel. Twelve bytes in the line overhead are reserved for a line data communications channel, although the use of this channel is not currently specified. The primary use of the section data communications channel is for communications with a management system when there is no direct connection between the Sonet network element and the management system. A local area network that performs as an extension of the data communications channel network can provide connectivity through an office.
For full Sonet interoperability, management systems and remote network elements must communicate over wide area data communications networks, local area networks and the Sonet data communications channel. The Sonet standards that are used to accommodate management interoperability have two essential components--a set of protocols that support the transport of management information and a management information model that permits a common understanding of the information transferred. The protocol standards are firm, and the information model for a core set of management functions is also complete. Work is ongoing to add management capabilities to the information model.
National and international standards bodies chose an open systems interconnection, seven-layer protocol stack, with the common management information service element at the application layer, as the standard for Sonet operations communications. Although this protocol stack was specified some time ago, the detailed requirements needed for implementation were not initially provided.
To move the industry forward in achieving the goal of interoperable Sonet network elements, some regional Bell operating companies held interoperability forums with suppliers. These forums, particularly the Southwestern Bell forum, developed detailed Sonet requirements. From this work, Bellcore produced protocol implementation conformance statements and a complete profile of the Sonet operations protocols up to the application layer.
Southwestern Bell Corp., recently renamed SBC Communications Inc., then led the formation of an open Sonet Interoperability Forum under the auspices of the Corporation for Open Systems. The Sonet Interoperability Forum has refined the initial Bellcore requirements; the new profiles appear in Bellcore Sonet criteria published at the end of 1994. It provides a solid baseline for interoperability of the Sonet operations protocols, among Sonet network elements on the data communications channel and LAN, and among Sonet network elements and their management systems.
To use the common management information service element, the information to be exchanged across the interface must be specified in an information model. In 1992, national and international standards bodies produced the common information model needed to manage a core set of operations functions (alarm surveillance, performance monitoring and memory administration). This information model has been expanded to include more functions, such as protection switching; it will provide similar functions for new Sonet architectures, such as Sonet equipment in path-switched rings.
The information model is being expanded to cover new areas; for example, standards bodies are currently working on a model for the management of synchronization in Sonet networks.
A dramatic shift
Another standards thrust is affecting the management of Sonet equipment. The Telecommunications Management Network standards recognize a layered structure for managing telecommunications. This layering of functions is causing a paradigm shift from a centralized operations system managing network elements to a distributed management environment. This dramatic shift, in turn, is affecting interface definitions because there can now be multiple interfaces between physical realizations of these layers.
For Sonet, the emphasis in the near term is the management of network resources, which comprise the network management, element management and network element layers of the Telecommunications Management Network functional model. Information modeling to date has focused primarily on direct management of individual network elements that support network element layer functions and perhaps element management layer functions. Work is also beginning on management of subnetworks of Sonet equipment such as Sonet rings.
Standards have been in place long enough, and suppliers have had sufficient time to develop compliant products. Consequently, interoperability at the transport level is practically available for basic Sonet architectures. Transport interoperability has been verified between a number of network elements at the STS-1 electrical, OC-3 and OC-12 levels, and has been verified for some OC-48 equipment. Electrical or optical signals produced by one network element are correctly decoded by another network element from another supplier; the services mapped at one network element and put into the Sonet line signal are correctly extracted at the other end.
Minimizing glitches
However, more work needs to be done to minimize glitches. In some cases, problems in transport interoperability have arisen because suppliers have not followed requirements. For example, some carriers have cited a Bellcore requirement that a supplier be able to "turn off" the data communications channel. However, some equipment provides this capability, but goes into an alarm condition when connected over the optical interface to another supplier`s network element. Although these alarms can be cut off to eliminate a response, such practice is not industry acceptable in operating networks. Sonet equipment needs to insert and extract services across mid-span meets, and operate correctly across mid-span meets without unnecessary alarms.
Other transport interoperability problems have occurred because the applicable requirements may not be specific enough. When these problems are discovered, requirements are updated to alleviate the problem. One such problem involved the use of different virtual terminal numbering schemes. Low-speed Sonet channels, or virtual terminals, must be individually identified within their high-speed STS-1 channel. The standards, as well as Bellcore documentation, presented two methods of virtual terminal identification: by group number and virtual terminal number within the group (a two-level scheme), or by one virtual terminal number within the STS-1.
Because these numbering schemes did not specify a virtual terminal naming scheme for the user interface, suppliers actually used one of three methods to name their virtual terminals--either of the two methods above, or a third scheme that corresponded to the way DS-1s are named within a DS-3 (and also corresponded to the way the DS-1s carried by the virtual terminals were laid out and numbered on a digital signal crossconnect frame). This variation became confusing because the same virtual terminal channel number in different equipment could correspond to different virtual terminal channels, leading to misconnections. To rectify this problem, Bellcore now requires the two-level virtual terminal numbering scheme. A similar issue is being addressed on the STS level.
Despite some minor problems, different suppliers` Sonet network elements generally have the capability to transport services between them, thereby providing the necessary interoperability at the transport layer.
Operations interoperability
Operations interoperability has not duplicated the progress of transport interoperability. Management systems with open systems interconnection stacks, including the common management information service element at the application layer, are available. However, many such systems have not implemented the information model required for Sonet management. They might only provide a platform on which management applications can be placed. Before delivering equipment that requires standard open systems interconnection and the common management information service element for support, suppliers of Sonet network elements want the necessary management systems in place.
Regional Bell operating companies typically manage their Sonet networks by using Transaction Language One, a language defined by Bellcore. Bellcore operations systems that currently manage these Sonet networks, the network monitoring and analysis system for surveillance, and the OPS/INE for memory administration, implement Transaction Language One over an X.25 protocol stack. To move to the Sonet operations standards in this environment, Sonet network elements should implement Transaction Language One over a full open systems interconnection protocol stack on the data communications channel and LAN. Some network element suppliers have already done this, and other suppliers are in the process of doing so. Several suppliers` Sonet network elements that have a full open systems interconnection protocol stack are expected to be available this year.
Implementation of Transaction Language One over the open systems interconnection protocol stack provides a transition path to the full standard (with the common management information service element), and delivers an important first step in achieving operations interoperability. Implementing the same lower layer communications protocols on the network elements means that information on the Sonet operations communications network can be correctly routed even when the network consists of equipment from different suppliers, and even if that equipment has different application layer management protocols (Transaction Language One or the common management information service element). To interoperate with currently deployed operating systems on the X.25 network when the network elements use Transaction Language One over an open systems interconnection stack, the Target Identifier Address Resolution Protocol, which was defined in Southwestern Bell`s interoperability forum and subsequently documented by Bellcore, is used.
The next step toward operations interoperability requires management systems with the common management information service element and the Sonet information model. These systems are presently in various stages of development. For example, Bellcore`s network monitoring and analysis system is "test ready"--the open systems interconnection stack with the common management information service element at the application layer and much of the Sonet information model have been developed.
Interoperability testing has already begun with a Sonet network element supplier. Using the protocol and information model standards in addition to Bellcore systems, some suppliers are developing element managers (or subnetwork controllers) to manage Sonet network elements. These management systems might not manage network elements that use Transaction Language One or other suppliers` network elements. However, because the lower layer open systems interconnection protocols are common, intermediate network elements that have an open systems interconnection protocol stack should be able to route information destined for the managing system or the managed network element. u
Jeffrey A. Ross is director, transport technology requirements and evolution, at Bell Communications Research in Red Bank, NJ.