Interface Priority

Service providers have long needed faster, more effective ways to provision services to their growing customer bases in order to meet competitive pressures in the industry.

The solution lies in a standard, open software interface that will ease the way for service providers to manage their multivendor networks so they can deliver new products and services to end users quickly and more efficiently.

Fujitsu, Lucent Technologies and Tellabs recently announced they are focusing on the element management layer (EML)-to-network management layer (NML) interface using an approach that's consistent with the Telecommunications Management Network (TMN) framework. The companies are working through the Network Management Forum to ensure this interface remains open in the future.

A scenario using the EML-to-NML interface lends insight into its operation. The arrangement is similar to the interface's live demonstration at the 1998 NFOEC conference. The demonstration highlights the interoperability of the CORBA among different platforms. By using the same CORBA interface definition language specification, the Lucent ITM network management platform (written in C++ on HP-UX) seamlessly communicates with the Lucent element management system (EMS), the Tellabs Titan 5500 EMS (written in C++ and running on Windows NT), and Fujitsu Network Communications' Netsmart (written in Java and running on Solaris).

To create the actual end-to-end connection between DS-3 A and DS-3 Z (Figure 1), the network management system (NMS) user must first specify the end points of the connection. To create the end-to-end connection, the NMS must send a subnetwork connection creation request to each EMS because the connection spans all three element system domains.

Service providers can meet the challenges of gaining practical, full-featured network management solutions for a multivendor Sonet network by moving standardization from the NML-to-EML interface point to the EML-to-NML point. This approach makes the communication link more scalable and easier to develop and manage. Using CORBA technology as the implementation protocol makes the solution even more viable.

Sonet management Sonet technology promised the ability to freely mix and match products from different vendors-a promise that was clearly achieved at the level of transport interoperability.

Practical, full-featured network management solutions for a multivendor Sonet network, however, have been elusive. One solution is to move standardization of network management interfaces to the EML-to-NML interface point based on the TMN model. This makes it easier for the NMS to manage large-scale, multivendor networks (Figure 2).

Initial efforts to achieve multivendor network management set out to standardize the network element layer (NEL)-to-EML interface. As a result, standards organizations such as ITU-T, ANSI and Bellcore define many NEL object models for managing individual elements.

Unfortunately, these standards did not solve the problem: The standards are based on the common management information protocol, which is not widely deployed.

Although the standards have been in place for several years, no significant deployment of such interfaces has taken place.

Contributing to the lack of common management information service element (CMISE)-capable network elements are these issues:

* Complexity of the models.

* Lag in the model specifications to support new features.

* Slow emergence of development tools and expertise using CMISE.

* Limited number of CMISE-capable management systems.

* Continued sufficiency and popularity of Transaction Language 1.

The difficulties and failures in solving the multivendor management problem of the NEL-to-EML interface warrant a new approach.

This approach involves moving the interface standardization up one layer in the TMN hierarchy to the EML-to-NML. The relative simplicity of this interface impr oves the likelihood of successful implementations and deployments.

The new approach addresses the issue of scalability as well as multivendor network management. Even in a single-vendor network, an EMS is limited to the number of network elements it can support. It is not unusual to encounter operations centers managing 10,000 to 20,000 network elements as a result of Sonet network growth and the trend toward consolidation of operations centers. The EML-to-NML interface provides a way to consolidate management not only across different vendors' EMSs, but also across multiple systems from the same vendor.

To further ensure the solution's commercial viability, CORBA was chosen for the interface specification and implementation. CORBA allows applications to communicate and interoperate with one another in a distributed computing environment-for example, a collection of NMSs and EMSs.

CORBA is defined by the Object Management Group, made up of more than 800 software vendors, software developers and end users representing a broad spectrum of vertical industries, including telecom, finance, health care and manufacturing.

Solution architecture A typical Sonet network may consist of equipment from several different vendors. For example, one vendor may supply a digital cross-connect system with Sonet interfaces, while another provides OC-12 (622 Mb/s) rings and below, and yet another supplies OC-48 (2.4 Gb/s) rings and above. The main questions such a network poses are: how to obtain an overall view of the network, how to manage connections across the network and how to perform fault management across the network.

Each Sonet vendor provides an EMS that supports the standard EML-to-NML interface. However, the EMS is responsible for supporting the detailed configuration, fault, performance and security management of the vendor's own network elements.

The EMS performs several important functions, such as automatic discovery of the vendor's network elements and connectivity, element setup and configuration, shelf-level views, equipment inventory, performance monitoring, data collection and analysis, alarm and event collection and display, testing, remote software download, and remote memory backup and restoration. In general, an EMS should have enough functionality to fully manage the vendor's own equipment in the absence of a NMS.

The NMS's role is to provide connection and fault management across multivendor EMSs. It provides a view of the entire network down to the individual network elements, termination points and links between network elements. NMS users or a service management system may specify the termination points of a connection, and the system will delegate the necessary portions of the overall connection to each responsible EMS in the form of subnetwork connection requests.

The NMS also receives alarm notifications from each EMS to provide a networkwide view of faults. The end-to-end connection view that the NMS establishes provides a basis for network partitioning (security), fault isolation and rerouting, quality of service monitoring and network inventory.

Each element and NMS provides a graphical user interface (GUI) that typically runs on a separate client workstation. It is useful if the GUI client of each system can run on a common client workstation so a single user can gain access to each system. Given the variety of client platforms in use today, this may not always be practical. However, the increasing use of cross-platform technologies such as Java- and Web browser-based clients will significantly ease platform compatibility problems.

The object model Before an EML-to-NML interface can be specified, the functionality supported over the interface must be clearly defined. The starting point for the CORBA-based EML/NML object model was a Sonet Interoperability Forum-approved object model, specified in GDMO/ASN.1. For simplicity, ease of implementation and performance, the forum model can be simplified and still meet the network/EMS requirements.

With a generic object model, a CORBA interface definition language specification can be developed as the basis for the interface's implementation. The most straightforward approach is to represent each object in the model as a true CORBA object. This "fine-grained" approach raises performance concerns, however, because of the extremely large number of instances possible in a typical EMS.

Rough calculations show that such a system managing a modest network of 4000 network elements would result in more than 1 million object instances.

To alleviate such performance concerns, a conservative "coarse-grained" approach keeps the number of actual CORBA objects very low.

Most of the objects are represented as simple data structures. The CORBA objects defined for the interface are NetworkR1, ManagedElementMgr, MultiLayerSubnetworkMgr, and Version. To support notifications such as alarms, object creation, object deletion and attribute value changes, each interface-except Version-inherits another defined interface known as observable. This interface lets the NMS register with each EMS interface and receive notifications issued by that interface.

The registration operation also supports filters so the NMS can control precisely which notifications it receives.

Filters can be based both on the types of notifications and attributes within a notification.

An observer interface, which serves as the target of the notifications, is also defined. The NMS establishes the observer object and specifies the object when it registers with the EMS. As a result, the EMS knows exactly where to send the notifications.

Because the filtering is performed on the observable side (the EMS)-as opposed to the observer side (the NMS)-only the notifications that the network system wants are sent across the CORBA bus.

The OMG recently approved a standard CORBA notification service, with commercial implementations to be released this year. A subsequent release of the EML/NML specification most likely will incorporate the notification service.

Each interface mentioned supports several operations that allow the NMS to interact with the EMS. These operations are similar in concept to CMISE operations. For example, the MultiLayerSubnetworkMgr interface supports an operation called CreateAndActivateSNC, which instructs the EMS to set up a subnetwork connection. That system then creates the subnetwork connection between the specified termination points by sending the necessary cross-connect, transmission parameters and service-state commands to the network elements.