Major vendor cooperation yields network-management interoperability

As networks become more complex, a simple solution promises to improve global network management.

For the telecommunications industry, a new and more efficient day is at hand. Open multivendor network management, which has been slow to arrive and costly for service providers to implement, is being addressed through the standardization of a new management interface developed through the cooperative efforts of major vendors.

The service provider's need to manage all the equipment that comprises a network is constant--to understand when there's a fault and why it has occurred, to be able to turn up service in response to volatile customer demand, to provide new services quickly enough to capitalize on emerging market opportunities, to understand the quality provided to customers, and to be positioned to implement critical new technologies for the future. But meeting this need remains a difficult proposition.

The difficulty is compounded by a number of factors, first and foremost of which is the growth of the public network. Fueled by the explosion of the Internet and the broad implementation of multiple lines, the network has grown at an astonishing rate over the last five years. This growth in turn has driven new technologies (e.g., ISDN, ADSL, DWDM, and ATM), the proliferation of which is accelerating--bombarding service providers with significant new network challenges. Add to this a commercial environment where competitive pressures are greater and more geographically dispersed than ever. The result is that network management has emerged as one of the central strategic imperatives facing the industry.

Carriers have made valiant efforts and spent large sums to manage their networks, but the increasing demands and rapid changes have outpaced their attempts. The hoped-for benefits of industry standards have not yet had the needed impact.

The problem posed by the delay in standards-based solutions is a stubborn one because of the industry's approach to solving it--something deeply rooted in the industry's stance toward issues of standardization. In the past, the telecommunications industry waited for standards to be established before building products to provide needed functions. This process has been painfully slow, often resulting in "overstandardization"--the creation of standards so complicated and technologies so expensive that they drive up implementation, operation, and maintenance costs.

Competition and rapid technology change have overwhelmed the old methods of developing standards-based products. What has been needed is an approach from a totally different angle--something that finally has been undertaken by a broad consortium of vendors and service providers in the TeleManagement Forum (TMF), an industry group formerly called the Network Management Forum. This new solution, a "network-management layer-element-management layer" (NML-EML) interface based on Common Object Request Broker Architecture (CORBA) technology, promises to simplify the resolution of network-management issues-empowering faster time-to-market, the ability to manage multivendor networks, and enhanced network performance at dramatically lower costs.

One only needs to look at the existing network-management solutions to see the shortcomings of earlier attempts to resolve this problem.

Although the ITU-T recommendations for Telecommunications Management Networks (TMN) have been in place for over a decade, wide-scale deployment has not yet been achieved. Initial efforts at achieving multivendor network management were based on standardizing the network element interface. To this end, many network element-level object models were defined by organizations such as ITU-T, ANSI, IETF, ETSI, and Telcordia (formerly Bellcore) for managing individual network elements. These standard interfaces defined to varying degrees the information to be exchanged between management systems and managed elements.

However, as vendors worked with various network-management pro viders, they found that the amount of information that the standard interfaces called for was overwhelming management systems tasked to deal with tens of thousands of network elements. Both the volume of information and complexity of this information prevented the effective deployment of management systems based on the network-element interfaces.

The failure to adopt a single standard for network-element interfaces has resulted in the implementation of multiple proprietary point solutions--solutions that have not met the service providers' major goal of fully featured, multivendor, end-to-end network management. These solutions have presented service providers with persistent interoperability issues, because the typical service provider network increasingly comprises multivendor equipment and management systems.

The rapid pace of technological advancement also exacerbates network-management headaches. For example, the emergence of hybrid network elements will give service providers increased bandwidth and maximum network resource utilization, while facilitating the introduction of new technologies in a single piece of equipment. In the near future, it will be common for a single network element to support combinations of SONET, SDH, DWDM, ATM, and IP. Yet such technological advances also add to the complexity of network management.

Geographical lines of delineation have also blurred. As mergers, acquisitions, and joint ventures have become increasingly part of the strategic growth plans of telecommunications companies, the boundaries of service providers' networks have expanded beyond traditional geographic limits. Therefore, the scope of network management has also increased. Many point solutions that had not been designed to work across large-scale networks quickly became unworkable because of scalability problems.

To break free from this conundrum of network issues, the TMF initiative was launched in late 1997. Its aim was to create an open, vendor-independent standard for achieving network-management goals. The TMF initiative--spearheaded by Tellabs, Lucent Technologies, Fujitsu, and Nortel Networks, with Siemens and Telcordia Technologies--focused the effort around a group of implementation experts. The idea was to define what functions needed to be implemented--i.e., identify the requirements of a viable solution and then devise a solution that was simple and capable of being implemented quickly. Because past efforts had proceeded at a foot-dragging pace, a tight timeline was imposed on the initiative--and in less than 18 months, the NML-EML specification was established.

The consensus was that the following characteristics were the minimal requirements for a realistic solution to network-management issues:

• Non-proprietary, vendor-neutral, and applicable across multivendor networks.
• Commonly applicable to multiple technologies.
• Abstracted at the EML, rather than providing all of the network-element details.
• Futureproof (i.e., not tightly coupled with a specific technology, protocol, or implementation).
• Easy to implement and commercially viable.
• Scalable (to meet the demands of large and growing networks).
• Open and available.

The TMF decided to follow the framework of the layered Telecommunications Management Network model1 but to focus standardization of the interface up one layer from the network element in the TMN hierarchy to the NML-EML interface--a step that would significantly reduce complexity and necessary functionality (see Fig.1). The relative simplicity of the NML-EML interface dramatically improved the likelihood of successful implementations and deployments.

At that point, the TMF had to quickly decide what technology to base the interface on. It chose CORBA.

CORBA was a good fit for a number of reasons. First, it was an open standard. Second, it was strongly supported by the Object Management Group (OMG)--a not-for-profit corporation that was gaining considerable recognition and support across multiple industries at the time and that was committed to developing technically excellent, commercially viable, vendor-independent applications for the software industry. Third, CORBA had been adopted by a raft of industries as a foundation interface architecture--ensuring the aggressive, rapid, and ongoing development of the technology.

The choice posed one serious risk: CORBA had not been widely used in the telecommunications industry, and the industry had long shown a predilection for telecommunications-specific software technologies. The risk from CORBA's lack of telecommunications application was offset by its success in other large-scale applications.

The original TMF solution focused on SONET and started with fault and configuration management (see Fig. 2). A typical SONET network may consist of equipment from multiple vendors. For example, a digital crossconnect system with SONET interfaces may be supplied by one vendor, with OC-12 rings and below coming from another, and OC-48 rings and above provided by a third. The main network-management problems posed by such a network are:

• How can a complete and accurate view of the entire network be obtained and maintained?
• How can connections across the network be provisioned and de-provisioned?
• How can fault management across the network be carried out?

An NML-EML interface that can solve these problems. Here's how it's done: Each SONET vendor provides an element-management system (EMS) that supports the standard NML-EML interface. The EMS is also responsible for concurrently supporting the detailed configuration, fault, performance, and security management of the vendor's own network elements--in addition to functions such as auto-discovering the vendor's network elements and connectivity, network-element setup and configuration, shelf-level views, equipment inventory, performance monitoring data collection and analysis, autonomous alarm and event collection and display, testing, remote software download, and remote memory backup and restoration. Generally, an EMS should have enough functionality to fully manage the vendor's own equipment in the absence of a network-management system (NMS).

Why is an EMS needed? It removes the burden of having to understand the detail of every element in the network, support the variety of protocols in the installed base, and maintain compatibility with new network-element capabilities.

The role of the NMS is to provide multivendor, network-wide connection and fault-management capabilities. It provides a view of the entire network down to the detail of individual network elements, termination points, and links between network elements. The NMS also supports connection management across the entire network. NMS users or service management systems may specify the termination points of a connection--and the NMS will delegate the necessary portions of the overall connection to each responsible EMS in the form of subnetwork connection requests. It also receives alarm notifications from each EMS to provide network-wide visibility of faults.

The CORBA NML-EML interface leverages the separation of management concerns as outlined at the layers of the TMN. The EML is concerned with managing individual network elements, whereas the NML focuses on the network as a whole.

At the NML, the NMS is responsible for managing the network from end to end, providing an abstracted view of the underlying network, where visibility to network element specifics is minimized. This "network view" is the key to the solution, making it possible to obtain commonality across multiple vendor-specific equipment at the NML--and to normalize managed objects at this reference point. There are fewer, less complex objects in the network view than in the element view. Because the managed objects are the only visible objects across the interface, the solution is highly scalable.

The TMF has taken a top-down approach to the NML-EML interface specification. Starting with the service or operation process requirements, it then identifies the data needed to fulfill them. This data flow is designed to normalize data before it reaches the NMS application, making it appear homogenous and succinct.

Reducing the amount of data passed upward to the NML reduces the programming required in the development of end-to-end management applications--thus lowering costs while speeding time-to-market of the management application, as well as future upgrades and new service deployments.

The beauty of this methodology is in its simple, compact information model that eliminates the complexity of TMN application design.

The use of CORBA allows applications to communicate and interoperate with one another in a distributed computer environment like a collection of NMSs and EMSs. Because it provides a scalable, non-proprietary solution that enables multivendor management systems to interoperate in an open-architecture environment, the use of CORBA and the standard interface enables service providers to select best-in-class SDH and SONET equipment from any vendor that supports the interface. They also permit carriers to deploy their chosen architecture globally while still managing the network from a single, integrated management system.

The interface also provides auto-discovery and graphical user interface (GUI) "cut-through." Auto-discovery allows the NMS to discover all the EMSs and network elements in the managed network without having to manually inventory the elements into the NMS. This allows users to get up and running quickly and to maintain synchronization between management systems and the actual network elements. The interface also provides a standard mechanism to "cut-through" to the EMS GUIs. Through the "cut-through" window, an operator can perform all the functions of the EMS from the NMS screen.

Given this generic object model, a CORBA IDL specification was developed as the basis for the implementation of the NML-EML interface. The most direct approach for this is to represent each object in the model as a true CORBA object--meaning that the object exposes an interface consisting of a set of operations that may be invoked by clients. Each object instance has a CORBA object identifier that may be registered with the naming service.

This "fine-grained" approach, however, raised performance issues because of the extremely large numbers of objects possible in a typical network. For example, an EMS managing a network of 4,000 network elements could result in over a million objects. To alleviate such performance concerns, a conservative "coarse-grained" approach was taken by TMF. In this approach, the object model was constructed so that the number of actual CORBA objects is small, and the majority of objects are represented as simple data structures.

Each interface in the specification supports a number of operations that allow the NMS to interact with the EMS. The complete CORBA IDL NML-EML specification has been submitted to TMF and will be publicly available.

While specifications like this are often agreed upon but not implemented, many vendors who contributed to the interface agreement are finalizing product implementations. Both Tellabs and Lucent have developed products supporting the nml-eml interface specification that will have been introduced to the market and purchased for deployment by major telecommunications service providers by the time this article appears.

There are three major drivers behind the vendor involvement in the TMF initiative:

• The industry has struggled in this area, and there was a genuine belief that vendor participation could help facilitate a solution.
• Without a reasonable NMS solution, service providers would have difficulties employing equipment at the rates necessary to meet network growth-and this could impact equipment volumes.
• In the absence of a real, workable standard or solution, carriers were deploying equipment that could not be managed together.

The new specification provides a simpler, more flexible means of network management--empowering service providers to respond more rapidly and effectively to the demands of technological change driving the market.

Such change will shape the development of the CORBA NML-EML interface. What began with SONET, SDH, and fault and configuration management has evolved to include functionality such as GUI "cut-through" and auto-discovery. This interface is currently being enhanced to accommodate ATM and DWDM through the TMF.

Perhaps this is the major contribution of the initiative--empowering the industry, service providers, and vendors alike to evolve at the pace of the market itself. After all, customers are providing high-bandwidth service at ever-increasing rates-and demanding the best services technology can offer. Those that succeed in this accelerating environment will have to manage those services from day one if they are to flourish in the challenging times ahead.

1. The ITU Telecommunication Management Network (TMN) model is an eloquent description of the various management functions in telecom networks. Its five-layered architecture segregates and simplifies the various management tasks involved in telecommunications management and is key to ensuring a choice of vendors--allowing operators the flexibility to "mix-and-match" systems from multiple suppliers. This framework is scalable and adaptable enough to provide a platform for telecommunication management as the network infrastructure evolves from TDM to packet-based-even though the interfaces and technologies described by the ITU are destined to change.

Jeff Schmitz is director of marketing and development for the Network Solutions Group (NSG) at Tellabs.