End-user's guide to TMN.
Management in telephone net-works, up to now proprietary and arcane, is under immense pressure from deregulation and its resulting competition, to become uniform. As more providers enter the market, they need smooth transfers of information in order to serve business and residential customers. Equipment from different vendors must fit into an overall architecture without disturbing the fabric. In response to this situation the industry is attempting to bring some consistency to how networks are managed when they are deployed, upgraded, or repaired.
Telecommunications Management Network (TMN), introduced in the late 1980s by the International Telecommunications Union (ITU), lays out a common infrastructure to manage telecommunication assets and provide compatibility between carriers through common standards for systems and software. Although some major international telephone companies are in partial compliance, adoption by U.S. carriers is slow.
The standard's main visibility in North America is the Tele-management Forum (TMF), which draws its membership from both the carrier and the vendor communities. Once called the Network Management Forum (NMF), the organization changed its name a few months ago. Its principal objective is to foster the adoption of TMN throughout North America. The forum's charter is well described in a recently published book called The Lean Communications Provider by Keith Willetts and Elizabeth Adams (McGraw-Hill, April '96).
Viewed from an actual implementation aspect, the processes being debated within the TMN Forum appear somewhat ambiguous. The emergence of the original ITU specification for TMN prompted the forum to recommend that the carrier community manage all the equipment using a standardized Open Systems Interconnection (OSI) approach. However, the many diverse services currently in use (X.25, Ethernet, etc.) do not lend themselves directly to management systems based on TMN.
The TMF's main task is to work within the current network and attempt to iron out the inconsistencies. The members strive to develop an understanding of now providers manage their networks, and they apply the TMN recommendations within this context. Several working groups have been formed to develop a solution and provide a set of recommendations on how ITU's objectives really apply to today's telecommunications infrastructure.
Many of these issues are complex and difficult to interpret. For example, when a carrier has specific data devices that are not necessarily TMN compatible, how does it get these into the TMN environment? What kind of an interface, for instance, would be needed to exchange billing information between carriers, and how would it fit into the overall architecture?
The long-term objective for TMN is to define and implement a management structure that, regardless of the equipment used, allows the carrier to construct its infrastructure to generate alarms, provide billing information, and keep the network secure consistently. This would allow a multiplexer from one manufacturer, for example, to be replaced by another company and basically respond in the same manner using the same data set.
From a technical aspect, this discards the idea of a message-based system that reports a failure, provides the supporting text, and identifies the circuit card that has gone down or a bit stream with too many errors. Rather, it develops an object at the initiation of the contact which then stores all the information required to describe the device fully.
In this way each item of equipment can identify itself to the network management system. A multiplexer reports what type it is, computes the number of incoming and outgoing T1 channels, provides data on available capacity, counts its operational cards, identifies their location, and assesses its involvement in transport, protection, and powering. It uses its fundamental management information base (MIB) structure to send this in an object-oriented manner so the top-level management system recognizes the device and restores it to service.
The objective is to identify everything in a switch or a mux--or any other piece of telecommunications equipment. Within the object model resides all the data needed by the manufacturer to meet the TMN standard, no matter whether the processes involve faults, performance, upgrades, or changes. Equipment vendors will thus create their own TMN object model, allowing carriers to transmit these data to the upper-level management system in a standardized format.
In the U.S., TMN has not been applied with great vigor, for good reasons. Suppose a broadband wireless equipment supplier sells a high-capacity radio system. The company debates the provision of a Q3 interface, defined by TMN as managing one particular network element. To implement this, the vendor might be required to add four times the memory, upgrade the multiplexer, and redesign the backplane. This results in a hefty design investment and a recurring expense for enhanced memory and processing.
The company has to sell the network provider on this added cost. But the customer gets the same number of DS1s or DS3s whether the equipment is TMN compatible or not. Thus the user sees no immediate benefit from the transaction. Is the vendor asking customers to pay $75K instead of $50K without any increase in traffic capability? It would be different if TMN was more widely deployed, but this is not likely to happen in the U.S. any time soon.
On the plus side, TMN may eventually become an internationally accepted management method which some large providers predict is future-proof and could become essential over the long term. This leaves equipment vendors with a major decision--should they install TMN in their products and absorb the added cost in the hope of being in the mainstream in a few more years? Or should they sidestep the problem?
Most manufacturers are not building TMN capabilities into their existing product lines but are considering TMN as an option for new equipment development. The rationale is that they could perhaps absorb the added cost when they develop an entirely new product. And for very large systems such as Class 5 switches, enough network elements are involved to make the added cost worthwhile.
A large supplier, therefore, might decide to provide an outboard processor, write the necessary software to run a piece of equipment, and provide a Q3-compliant interface that can be managed via TMN. If customers don't want it, they don't have to buy it. This leads to anomalous situations where, for instance, a major switch manufacturer has an element manager that is TMN compliant, but the associated equipment does not.
The one area where there may be more incentive to apply TMN is the Synchronous Optical Network (SONET). Here the industry is beginning to deploy Q3 interfaces, which is the portion of TMN that manages the element. More and more SONET equipment is becoming Q3 compliant because it's a leading-edge technology and doesn't require the up-front costs associated with adding TMN interfaces later.
Nevertheless, it is a difficult marketplace to enter. The TMN Forum says it requires standards to be created down to the element level so that the top-level manager has only to deal with one kind of interface. For the carders, this means either proxy agents or full compliance with TMN standards. One very real problem for the network management system vendors is that TMN puts them squarely in the center of the decision-making process.
CLECS AND TMN
Competitive local access providers want a management platform that enables them to transfer information among themselves. For example, many end users run T1 carrier from their headquarters to their manufacturing plants in other states. In order to do that, they may require an ILEC, an interexchange carrier (IXC), and possibly an ILEC and a CLEC (competitive local exchange carrier) at the far end.
In one scenario, the end user orders the entire connection from the IXC rather than ordering individual pieces from each provider. For the long-distance company to establish end-to-end service and meet an accurate installation date, it has to work with several providers who must set up their portion of the path independently and keep the long-distance company informed of problems.
The IXC would like to take the order, process the information, and provide a delivery date to the customer immediately. A week or two before cut-over, the carrier must review each participant's ability to meet the target delivery dates. In this situation, a management system common to all providers could handle troubleshooting and availability. With TMN, these advantages apply to service activation, service changes, operations, fault management, and billing. This is the solution that ITU is promoting.
In graphical form, TMN corresponds to a angle with five different levels which can be considered as simple descriptions rather than protocols.
Starting at the base these are:
1. Network elements comprise all of the network infrastructure;
2. Element managers provide specific management for a specific technology or a specific element;
3. Network management involves network-wide consolidation of alerts, performance, billing, security, etc.;
4. Service management extends beyond surveillance to workforce management, performance for growth, overall effectiveness; and
5. Business management involves resource economics, charge backs, human resources, administration.
Two years ago, the regional Bells were very much in favor of TMN. They believed they could use it to perform end-to-end circuit provisioning and could provide information hand-offs and understanding between companies. But the payoff for this heavy investment has been minimal. Today it is those manufacturers and network management vendors that service the international market who are the main supporters of TMN.
The TMF- and the TMN-compliant marketplace will continue to swirl. Over the past year and a half, the forum has defined the Q3 interface very stringently as being a CMIP (Common Management Information Protocol) and object model using GDMO (Guidelines for the Definition of Managed Objects). Now it is considering an alternative protocol known as CORBA (Common Object Request Broker Architecture). Within the computing software programming world, it is possible to transfer objects between applications. Because it has become very intensive with lots of different software applications, the impact on TMN development and acceptance are likely to be significant.
Stewart is a contributing editor. This article was prepared from interviews with John Koenig, director of sales, Harris Corp., Melbourne, Fla. The company produces Harris Network Management (HNM), a mediation solution for carrier networks.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||Industry Trend or Event; Telecommunications Management Network standard|
|Date:||Feb 1, 1999|
|Previous Article:||Paying the piper.|
|Next Article:||Building next-generation switched SANs.|
|FNS SELECTS SUN MICROSYSTEMS' TECHNOLOGY PRODUCTS.|