A Programmable Control Architecture for TMN Q3 Interface Yao Liang Alexandria Research Institute Bradley Department of Electrical and Computer Engineering Virginia Polytechnic Institute and State University Alexandria, VA 223 14. USA
Abstract: The lack of flexibility of traditional TMN architecture becomes a serious obstacle to modem multivendor network environment. In this paper, we propose a novel programmable control architecture for TMN 4 3 EMLNML interface to address such issues. Our approach provides an effective and systematic solution to complicated telecommunication network management in a multkvendor network environment, and facilitates rapid and easy deployment of new network management services and operations at NML, through TMN CMIP mechanism.
resource and offer an access interface at the object boundary, and the conceptual repository for all managed objects is referred to as Management Information Base (MIB). Information models in TMN are developed using object+riented methodology. A managed object class is defined in terms of characteristics (mainly attributes and operations that can be performed on attributes, and notifications that objects can emit). The notations known as GDMO (Guidelines for the Definition of Managed Objects) are used to specify the information models in TMN [2]. The traditional control architecture of TMN has been monolithic and static, and tries to provide the management functionality which may be required by all current and anticipated future network elements (NEs) and network management systems. The problems associated with ITU-T TMN qproach are the lack of flexibility and extensibility, making it vely complex and inefficient.
Keywords: TMN, GDMO, Programmable Networks, MultiVcndor Network Environment
I. Introduction Telecommunications industry is experiencing great growth across the world at today's information age. Various high-speed multimedia broadband services, based on advanced tcchnologies, are dcployed at a rather fast pace in many countries. On the other hand, multivendor's network environment is going bccoming dominant infrastructure. Thus, one great challenge that vendors, operators and service providers face is how to meet customers demands on creating new features and services promptly, reducing the time-to-market, and increasing the utilization of the network resources in a more efficient manner in multi-vendor's network environment. Clearly, an effcctive network management system architecture can be critical in addressing such issues.
In contrast, this paper presents the concept and mechanism of programmable control architecture in TMN. Our work focus on the Q3 interface between EML plement Management Layer) and NML (Network Management Layer) in TMN, which is essential for multivendor's network environment. The presented programmable control architecture allows that EMLR'IML interface in multi-vendor's telecommunications system is to be dynamically programmable by network operator and service provider at run-time, which, consequently, can significantly overcome the drawbacks of traditional TMN architecture. The rest of paper is organized as follows. Section 2 justifies the presented approach by detailed analysis on the traditional TMN architecture and its inherent problems. Section 3 presents our programmable control architecture at EMLMML interface. Section 4 describes the related work. Finally in section 5, a conclusion remark is given.
Traditionally, telecommunications network management architecture is mainly defined in Telccornmunication Management Network (TMN) standards developed by ITU-T to address interoperable interfaces between managed systems and network managing systems [I]. The traditional TMN relies on OS1 systems management- concepts and is based on Manager-Agcnt paradigm, with the emphasis on modeling the interfaces of the resources managed. Network resources are modeled in tcrms of managed objects (MOs) which encapsulate the underlying
11. Motivation In TMN architecture, a lot of management functionality for the managed system has been realized and implemented at the managed system side, in terms of functions embedded into managed objects as methods.
Email:
[email protected]
0-7E03-7547-5102RI7.00@2002 lEEE
80 1
managed systems (EMSs) and managing systems (NMSs), the traditional TMN 43 approach tries to predefine and provides the management functionality required by all current and anticipated future NEs and network management systems. However, this universal approach suffers from several drawbacks which are identified as follows.
Recommendations of generic network element information model [3] and network view information model [4] have been developed in TMN standards, and information models for some specific technologies, such as G.774 series for SDH model are also developed. Similarly, Bellcore (currently Telcordia Technologies) and SIF (SONET Interoperability Forum) developed management information model for SONET technology, based on TMN framework. Various levels of abstraction in TMN is achieved through arranging network management functions into five different management layers as shown in Fig. 1, and the Information models are mainly focused on the NEL and EML.
Since it intends to cover all the features of individual vendors current and anticipated future NEs and to deal with all the ways to use them, the traditional TMN 4 3 architecture is very heavy and inefficient. Consequently, the predefinition process is slow, tedious, and usually far behind the industry innovation and market changes.
OS
/
.
EMS
-.
Because of its monolithic and static nature, any changes in the 43 interface means management and service downtime because the old management interface must he replaced with the new one.
SeniceMsnapment
, Element Msa%ement
Many management functions are relevant to the management police, network operation style and network services of the managing system. NE vendors are very reluctant to support such specific managing system flavored functionality into its 43 interface, whereas network operatoriservice provider demands for those to he supported by vendor's EMS, to simplify the network operator's management task across the multi-vendor's network.
Fig. I TMN Layers
Typically, a multi-vendor's telecommunications network environment, as illustrated in Fig. 2, consists of multiple vendors' network elements (that are connected with each other), and a unified network operatoriservice provider's network management system (NMS) to manage and control the entire telecommunications network. Each individual vendor usually provides with its own element management system (EMS) as a gateway to its NEs. The management interface between the NMS and various EMSs are 4 3 interface using CMIP. Driven by the philosophy on ultimate interoperability among any
Any changes at NMUEML 43 interface must be coordinated and negotiated with each involved vendor and the network operator. Due to the above drawbacks, in practice, TMN network management systems for multi-vendor network environment are still few and difficult to develop. This situation becomes moTe and more serious recently where NMS is subject to frequently change due to
Q3
Vendor I
Vendor k
Fig. 2 Multi-vendor's Telecommunications Network Environment
802
A novel EMS control architecture for the proposed programmable TMN EMLMML interface is presented and illustrated in Fig. 3.
telecommunications deregulation and customer demands for new network services. Our work is motivated by addressing such issues and attempts to overcome the serious limitation of the traditional TMN 4 3 architecture. We take an evolutionary approach. We identify that the key problem underlying the traditional TMN 4 3 architecture is the monolithic and static nature, and the lack of flexibility and extensibility. As a result, the traditional TMN 4 3 architecture can not adapt to any changes and new requirements dynamically and efficiently. Our approach is to add the programmability into the TMN 4 3 control architecture, so that the 4 3 interface can be programmed and hence modified dynamically at runtime. By such programmable TMN control architecture, all kinds of specific managing system flavored functionality which is based on management police and style now can be easily programmed into managed EMSs by network operator by using an EMS API provided by vendor, and can he changed easily as management police is changed. Consequently, the above shortcomings of the traditional TMN Q3 architecture can be overcome in this evolutionary approach, instead of the complete replacement of the current telecommunications management infrastructure.
Fig. 3 EMS Control Architecture
One critical feature of this architecture is that the mechanism for 4 3 interface programmability is based on current widely TMN CMIP, which provides an elegant approach to reuse and evolve the already widely implemented TMN architecture in today's telecommunications management infrastructure. Another critical feature of this architecture is the strong separation between the conventional EMS control (i.e., EML 4 3 agent engine and MIB) and the value-added control module for management interface programmability. In fact, if the EML/NML interface programming functionality is not used in some management environment, the valueadded controller will be transparent and hence no unnecessary processing overhead is involved. The control module mainly contains two parts, the controller itself and the environment where the programmable management policieslfunctions are executed. The controller is responsible for installing and maintaining the dynamically installed management policieslfunctions.
III. Programmable Control Architecture Aimed at improving the flexibility of traditional TMN architecture to solve the problem identified above, a novel programmable TMN architecture is proposed.
A. Basic Idea In order to achieve the programmability at EMLNML interface at run-time, we introduce a new concept and entity, called as programmable managed object, into conventional TMN 4 3 interface. A Q3 programmable MO is different from ordinaty 4 3 MO in that a programmable MO always has two system-level meta-methods, named as insfallNewActionsand de-installActions, respectively. The installNewActions is used to download and install any newly defined actions under that MO dynamically, allowing new management policies and functions can be implemented and deployed at run-time, in terms of the managed object's newlrevised actions. Once a new action is installed dynamically through this mechanism, it can be immediately activated by NMS through CMIP, in the same way as to activate any predefined actions of MO (using newly gencrated OID for the installed action). The de-installActions can only be used to de-install those actions dynamically installed by using installNeivActions previously. With this mechanism, a run-time programmable TMN EMLNvIL interface can be achieved.
The execution environment for the run-time dynamically installed actions can use a scripting language, such as Tcl.
C. Procedure for programming EMLNML interface Based on the proposed control architecture, EMS needs to provide an API of operation primitives that NMS can use in order to develop delegated programs, and then install them into the relevant managed objects of EMS as new actions at run-time. Thus, the procedure for run-time programming EMLINML interface is as follows. Transfer a delegated program to an EMS;
B. The Architecture
Install the delegated program as a new method
803
V. Conclusion Remark
(action) to the indicated Q3 managed object; Invoke the new actions by NMS when needed;
The need for flexibility in network infrastructure is of paramount importance in today and future’s TMN in a truly multi-vendor network environment. The lack of flexibility of traditional TMN architecture, however, has made the development of telecommunication management system a very difficult task for multi-vendor environment. In this paper, we present a novel programmable control architecture for TMN 43 EMLNML interface to address such issues. The proposed framework allows that telecommunications network operators and service providers are able to rapidly and easily deploy new NML management police and services dynamically at run-time, in response to market demands and changes.
De-install any dynamically installed actions when not needed anymore. A s an example, a run-time programmable managed is shown in Fig. 4, where object subnetwork installNewActions and de-inslallActions are the system. level meta-methods, setupSNC / releaseSNC are predefined regular actions, whereas policy-A-setupSNC / policy-A-releaseSNC and policy-B-setupSNC / policy-9-teleaseSNC are run-time installed delegated programs to deploy two new management policies of subnetwork connection and release respectively.
The future work is to implement the proposed framework into a prototype system, and then conduct experiments on it to evaluate the programmable control architecture in some real-world environment, with cooperative research activities with various vendors and service providers.
IV. Related Work The problems associated with the monolithic and static nature, and lack of flexibility and extensibility of the conventional architecture of network management systems have been identified by many. In [ 5 ] , a mechanism of network management via delegation is proposed. However, this work and several other following up research focus on network management with SNMP, and do not address the complicated TMN where CMIP is employed. In [6], an approach called active objects is proposed to address the issues of TMN, but its power is limited by the fact that the approach can only apply to a few supporting managed objects in Q3 interface, such as discriminator, and summarisation. Yet, another approach is to explore distributed object technologies [7][8], such as CORBA [9], to replace or nix with conventional TMN architecture.
References [I] ITU-T Recommendation M.3010, Principles for a Telecommunications Management Network, 1996. [2] ITU-T Recommendation X.722, Information technology - Open Systems Interconnection - Structure of Management Information: Guidelines for the Definition of Managed Objects, 1992. [3] ITU-T Recommendation M.3 100, Generic Network Information Model, 1995. [4] ITU-T Recommendation G.855. I , GDMO Engineering Viewpoint for the Generic Network Level Model, 1999. [5] G. Goldszmidt and Y . Yemini, “Evaluating Management Decisions via Delegation”, IFIP Internariorial Syritpsium of Network Management, April, 1993. [ 6 ] A. Vassila, G. Pavlou, and G . Knight, “Active Objects in TMN”. [7] G. Pavlou, “ Using Distributed Object Technologies in Telecommunications Network Management”, IEEE J. Selected Areas i n Conmr.,Vol. 18, pp. 644-653, May 2000. [8] Y. Tsubakihara, M. Takimoto and T. Miyazaki, “A ‘truc’ TMN network management system for large-scale transport network using a distributed object environment’’ ,NOMS 2000, pp. 425434,2000. 191 OMG Common Object Request Broker: Architecture and Specification, OMG Rcvision 2.0, 1995. [IO] G. Hjalmtysson and S . Bhattacharjee, “ ControLonDemand: An Efficient Approach to Router Progammability” , IEEE J. Selected Areas in Conrrn.,Vol. 17, pp. 1549-1562,Sept. 1999.
Our work on control architecture shares some idea with Hjalmtysson and Bhattacharjee in their work on router programmability [IO]. Subnetwork --ATTRIBUTES
-- ACTIONS
subnetworklist,
de-inslallAclions.
subnetworkld, subnctworkType,
setupSNC,
-
releascSNC, policy-A-setupSNC, policy-A-releaseSNC, policy-B-setupSNC, policy-B-releaseSNC,
Fig. 4 An Example of Programmable Managed Object
804
