Digital crossconnect system integrates ATM/Sonet network elements
The digital crossconnect system represents the core building-block of future atm/Sonet networks because it leverages fault, configuration, and performance management via a single intelligent platform
alan repech
tellabs operations inc.
The convergence of Synchronous Optical Network (Sonet) digital crossconnect systems (dcss) and traditional Sonet add/drop multiplexers (adms) is at hand. Next-generation dcss will be implemented as elements of ring-based Sonet or Asynchronous Transfer Mode (ATM) networks. They will provide the benefits usually associated with a dcs--groom and fill, performance monitoring, test access, and optical hubbing, among others--while also furnishing the high-speed building-block features of Sonet network elements.
Yet this integration of Sonet network elements by a dcs raises issues of equipment interoperability within the network. Interoperability is mandatory because multiple Sonet network elements from multiple vendors have to be connected to the dcs. In addition, common management approaches using vendor-specific equipment must continue to support a multivendor network. Fortunately, the integration of Sonet network elements into a dcs results in the natural role of a gateway network element.
Network integration
Currently, telecommunications transmission networks use adms as network building blocks and use dcss as networking tools. In operation, the adm represents a three-terminal device. It consists of either an east and west ring or 1+1 protected linear high-speed optical ports (two of three ports) and a series of tributary interfaces that make up the third port of the model. Similarly, the dcs typically represents a 2-port device with a switch matrix that enables connections between interface pairs (see Fig. 1).
Network service pro viders have designed their operations under the assumption that the equipment in Sonet rings comes from a single vendor. However, the evolution of the dcs has provided an opportunity for network service providers to eliminate unnecessary adms in the central office by integrating the adm functions into the dcs.
In this approach, the system cost of the adms is replaced by the smaller incremental cost of the dcs. In addition, network operation is simplified because fewer network elements are needed in the infra structure design. Moreover, network reliability increases because fewer devices are required.
For example, the dcs can be modeled as a 4-port device (see Fig. 2). The two pairs of optical interfaces operating in the unidirectional path-switched ring mode or linear 1+1 protected mode can be connected at either wideband (VT1.5) or broadband (sts-1 or sts-3c at 52 and 150.336 Mbits/sec, respectively) levels, or at both levels. Deploying a dcs within a central office in this way offers groom-and-fill flexibility and simplicity over what is achievable using stand-alone adms. That is, the constituent signals can be directly connected among all rings and linear circuits interfaced to the dcs.
Using stand-alone adms requires the mapping of signals into physical DS-3 (44.736 Mbits/sec), sts-1, or oc-n signals for connection to a dcs where groom and fill can be performed. This approach, however, introduces complexity and low reliability due to the physical interconnects and the need for additional provisioning activities because at least two adms are involved in the circuit. Furthermore, when multiple rings are terminated in the central office, all the rings can be terminated in the dcs, where bandwidth management activities can be performed.
Mandatory interoperability
To achieve the benefits offered by the integrated Sonet architecture, the dcs in the central office and the adms at remote locations must interoperate over the network features of interest. However, the dcs and adms in combination do not need to jointly support the union of all features offered by these network elements. On the other hand, they do need to interoperate at the intersection of features within a subnetwork. For example, interoperability agreement needs to be achieved for Sonet transport signals, Sonet overhead, and data communications channel (dcc) protocols.
To achieve Sonet transport signal and overhead agreement, equipment manufacturers must meet appropriate Bellcore specifications (such as GR-253-core and GR-400-core) and American National Standards Institute committee standards. These standards documents have evolved since the mid-1980s but are now stable.
Once equipment implementation is completed, basic testing needs to be performed between vendor equipment to verify signal level interoperability. Testing for extensions to standards should include verifying that the extensions can be disabled in cases where far-end Sonet network elements do not support the extensions. Verification of this type can be done between vendors directly, in service provider laboratories, by third-party testing organizations, or in combination.
Whereas Sonet transport and overhead implementations are well-understood in the telecommunications industry, the deployment of interoperable dcc protocols has just begun. Because the dcc has been used since the inception of Sonet to control activities within Sonet subnetworks, vendors have chosen methods that suit their particular network element architectures. This approach has led to a variety of proprietary implementations for data networking over the dcc.
In proprietary deployment models, no interoperability is achievable in multivendor networks. Furthermore, trying to address a like-vendor network element across a foreign-vendor subnetwork is not possible because the addressing schemes are invariably different.
Perhaps the largest contribution made by the Sonet Interoperability Forum has been settling on the tid address resolution protocol (tarp) as the standard for associating transaction language-1 (TL-1) identifiers with addresses used within data communications protocols on the dcc. Specifying tarp and open systems interconnect (osi) standards for the dcc has stabilized the channel to the point that several demonstrations of dcc interoperability have occurred publicly in the telecommunications industry (for example, the interoperability events sponsored by Bellcore and Tellabs Inc. at nfoec `96; see Lightwave, November 1996, page 7).
Verification of dcc interoperability is more complex than for Sonet transport and overhead, mostly due to the complexity of the 7-layer osi protocol stack and the plethora of options available to vendors for implementation. Third-party testing can be performed to verify basic conformance to specifications, such as the Bellcore GR-253-core. However, only actual connection of the equipment of interest ensures network interoperability.
Gateway elements
A target network architecture can decrease the number of network elements within a central office and ease the management of complex ring subnetworks. To achieve this architecture, the dcs must provide gateway network element functions that enable the remaining network elements in the subnetwork to provide ties to the management systems and the craft personnel located in central offices and maintenance centers. Necessary gateway network element functions include routing osi protocol data units to downstream network elements and converting wide area network protocols (such as X.25 or tcp/ip) to the osi protocols used over the dcc.
Routing osi protocol data units only requires osi interoperability between the gateway network element and subtending network elements because the capability to perform this function is contained within the osi protocol stack. Only the endpoints of the transaction need to be aware of the content of the osi protocol data units. Protocol conversion of wide area network protocols to osi protocols requires not only osi interoperability, but also agreement in the applications being used within the subnetwork that includes the gateway network element.
For example, if TL-1 is the command language being used, then the gateway network element must identify the network element addresses contained within the TL-1 commands, terminate the wide area network protocol, and insert the TL-1 command into an osi protocol data unit over the dcc.
Gateway network elements can perform other specialized functions within single-vendor subnetworks. However, these functions become secondary to the need to provide access to remote network elements for maintenance centers and craft personnel located within central offices.
The ability to manage and maintain the network from a single location is paramount to delivering reliable services in complex network architectures. The dcs can provide the gateway network element functions within large subnetworks because it contains the large amounts of transient and persistent memory needed to run osi protocols and perform large-scale protocol conversions. Furthermore, because the dcs is centrally located within the subnetwork, it provides an ideal location for access to remote network elements and to general-purpose routers within the central office.
atm contributions
Consolidation of network elements is expected to continue in next-generation dcs architectures, which are anticipated to incorporate atm capability within the core system. This atm capability is expected to provide more flexible bandwidth management than is presently achievable in traditional Sonet networks.
atm technology also provides a mechanism to reduce the number of overlay networks required to deliver a variety of service products. Therefore, atm technology is also anticipated to be deployed at the facility interfaces of the dcs as point-to-point circuits and rings (such as for pure atm networks and for atm-over-Sonet networks).
Future Sonet and atm core networks should continue to be consolidated using dcss. Presently, these systems integrate Sonet network element technology in the form of unidirectional path-switched rings. The combination of traditional Sonet ring technology using both unidirectional path-switched and bidirectional line-switched rings will position the dcs to become a ubiquitous network element.
This type of dcs must be scalable from the equivalent of a single OC-48 (2.5-Gbit/sec) adm to at least 320 Gbits/sec in bandwidth--equivalent to 128 OC-48 adms. It probably will integrate wavelength-division multiplexing and other forms of optical networking as well. u
Alan Repech is senior product planner, digital systems division, at Tellabs Operations Inc., Lisle, IL.