D1vol1
advertisement
Project P812-GI TMN Evolution – Service Providers’ Needs for the Next Millennium Deliverable 1 TMN Evolution Volume 1 of 2: Main Report Suggested Readers: Technical strategy Procurement of TMN products Specification of TMN systems TMN developpers For full publication March 1999 EURESCOM PARTICIPANTS in Project P812-GI are: BT Deutsche Telekom AG Portugal Telecom S.A. Sonera Ltd. Telecom Eireann This document contains material which is the copyright of certain EURESCOM PARTICIPANTS, and may not be reproduced or copied without permission. All PARTICIPANTS have agreed to full publication of this document. The commercial use of any information contained in this document may require a license from the proprietor of that information. Neither the PARTICIPANTS nor EURESCOM warrant that the information contained in the report is capable of use, or that use of the information is free from risk, and accept no liability for loss or damage suffered by any person using this information. This document has been approved by EURESCOM Board of Governors for distribution to all EURESCOM Shareholders. Disclaimer: The contents of this document are not guaranteed to be usable for the development or purchase of telecommunications management systems or for any usage apart from being a source of ideas. © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report Preface (Prepared by the EURESCOM Permanent Staff) Project P812, "TMN Evolution – Service Provider’s Needs for the Next Millenium", with a budget of 63 man-months for 5 Participants (BT, DT, PT, TF, TI) was running between January 1998 and March 1999, and was led by TI. The objectives of this Project were to propose how TMN should evolve in order to adapt to changing technologies and changing needs. The result is a Deliverable giving first a realistic assessment of the status of TMN today, then a list of the real issues preventing the wider acceptance of TMN, and finally a practical analysis of the solutions proposed by emerging technologies. The Deliverable consists of 2 volumes, with Volume 2 containing the full analysis reports in 5 annexes. The Project also produced a web site containing an adapted version of this Deliverable as well as supplementary reference information. The URL is http://www.eurescom.de/public/deliverables/wwwdeli.htm. © 1999 EURESCOM Participants in Project P812-GI page i (xiii) Volume 1: Main Report page ii (xiii) Deliverable 1 – TMN Evolution © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report Executive Summary Introduction In 1997 EURESCOM telecommunications management experts judged that the progress and direction of TMN needed to be re-appraised due to the diversity of choices facing TMN system owners and developers. In response, a Project was started entitled “TMN Evolution: Service Providers’ Needs for the Next Millennium” that ran through 1998 and into the first quarter 1999. Full Project results and associated information can be found at [1]. The term “TMN” is widely used and abused leading to confusion over its meaning. In this paper, the TMN architecture is defined to be that described in the ITU’s M.3010 (1996) recommendation and the recommendations and standards that lead from it. This provides: Architectural concepts to identify and structure functionality Standards to ensure inter-operability across interfaces Technology and protocols such as CMIS/CMIP and GDMO to implement those standards The ITU-T TMN concepts and technologies meet functional requirements as well as efficiency considerations for many management systems. This paper takes a critical view of these concepts only in the light of dramatic changes in the market and business climate. During the past five years many new requirements for management systems were stated and many new implementation options were brought into consideration [2]. TMN needs to evolve to match a changing world. The Industrial Status of TMN A recent survey contained in [3] found that out of 250 OS systems examined, 70 claimed to be fully TMN compliant and 51 claimed partial compliance. Amongst the more common opinions expressed were that: The necessary TMN implementation skills are scarce TMN technology is not IT mainstream TMN toolkits have been slow to emerge and are expensive TMN standards are too complex with too many options TMN doesn’t help with legacy problems It is worth noting that TMN had a bad reputation amongst early users while later adopters, who are able to benefit from development toolkits, have more positive opinions. The Changing Need for TMN Standards In the changed telecommunications world, there is a greater need for inter-operability between operators and between management applications and systems than before. The world in which TMN exists may have changed but appropriate standardisation is still needed. We now have more new types of network to be managed, new services, new needs of users, new software technologies and new business rules influenced by new types of service provider – greater diversity in the TMN Environment. © 1999 EURESCOM Participants in Project P812-GI page iii (xiii) Deliverable 1 – TMN Evolution Volume 1: Main Report Issues Affecting TMN Deployment Work in the EURESCOM Project P812 has examined many aspects of TMN as it exists today and defined a number of issues. We say that an ‘issue’ is a problem or uncertainty that stops, or will stop progress on TMN within the next three years. The TMN issues are grouped into the broad categories of: Issues traceable to service provider needs Issues concerned with architectures and standards Issues concerned with new and emerging technologies Each issue is formulated as a question and explained in 4-8 lines of text. These issues can be used to determine the priority that the various groups involved in TMN evolution assign to the topics that they wish to progress. Future Evolution of ITU’s TMN The future of TMN can be addressed under a number of headings: The Separation of Architecture from Protocol Better Support for External Access Caution over Service Management Provide Support for Finer-grained Distributed Systems Respond to the Internet Exploiting mainstream IT developments from OMG Web-related Technology Consider Component Interoperability in an IT Industry Context Clarify Scope and Intended Use of the TMN Architecture Adapt to Changing Network Technology Methodologies Most of these issues are addressed in this document and its annexes. Some are addressed at a greater level of detail than others. Concluding Remarks The management systems segment of the telecommunications industry continues to dramatically change in terms of the multiplicity of choices to be made by owners and builders. It is inevitable that its current architectures and standards will either evolve to match those changes or will be abandoned. The TMN architecture is no exception and if its proponents wish for it to survive then they must evolve it to match changing needs. The ITU’s SG4 group has recognised this and has initiated some changes but some resistance can be observed. TMN’s success has been in areas characterised by large operators and vendors where investment is high and where stability exists. Perhaps this is TMN’s survival niche but if so we must question whether this niche will expand or contract in today’s market arena. Should TMN strategists seek such areas of stability or attempt to evolve TMN to address areas with different characteristics? page iv (xiii) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report The need for TMN architecture must lie in application areas that have telecommunications-specific needs. For areas that are common across other industries, telecom management system developers should attempt to use common solutions thereby benefiting from reduced costs and shared risks. The evolution of TMN must ensure that it recognises this point and that it supports operators and vendors in benefiting from IT developments. If TMN does not succeed in evolving such that telecom management systems owners are able to use innovative solutions, a new management paradigm may emerge which will eventually eclipse TMN. This may not be a great tragedy but, on the basis that much time and effort has been consumed in the name of TMN, its failure to adequately evolve would be judged as a poor return on investment. References [1] ‘TMN Evolution’ link on www.eurescom.de/public/Deliverables/wwwdeli.htm [2] Proceedings of NMF Communications Management Forum and Expo, Orlando, May, ’96, Barcelona, October, ’96 Long Beach, April, ’97. [3] OSS “An Operator’s Perspective” Dittberner Associates, Project ESS, Advanced Technology Series Update 36 1998 © 1999 EURESCOM Participants in Project P812-GI page v (xiii) Volume 1: Main Report page vi (xiii) Deliverable 1 – TMN Evolution © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report List of Authors Manooch Azmoodeh BT Jose Domingues BT Rob Davison BT Jane Hall Deutsche Telekom Bharat Bhushan Deutsche Telekom Renato Roque Portugal Telecom José Bonnet Portugal Telecom Pedro Leonardo Portugal Telecom Nuno Beires Portugal Telecom Martti Tikkanen Sonera Timo Wirkkala Sonera Tom Counihan Telecom Eireann Mandy Martin Telecom Eireann Terry Turner Telecom Eireann © 1999 EURESCOM Participants in Project P812-GI page vii (xiii) Volume 1: Main Report Deliverable 1 – TMN Evolution Table of Contents Preface ............................................................................................................................. i Executive Summary ...................................................................................................... iii List of Authors ............................................................................................................. vii Table of Contents ........................................................................................................ viii Acronyms ...................................................................................................................... ix 1 Introduction ............................................................................................................ 1 1.1 Purpose ......................................................................................................... 1 1.2 Stated objectives........................................................................................... 1 1.3 Context setting ............................................................................................. 2 1.3.1 General Project perspective ............................................................. 2 1.3.2 Concurrent relevant activity ............................................................ 3 2 Results .................................................................................................................... 7 2.1 Introduction and some general comments .................................................... 7 2.2 Evaluation of TMN Status.......................................................................... 10 2.2.1 Architectural perspective ............................................................... 10 2.2.2 Enabling technology perspective ................................................... 11 2.2.3 Standards bodies perspective ......................................................... 13 2.3 TMN Issues ................................................................................................ 15 2.4 TMN Evolution Case Studies ..................................................................... 16 2.4.1 Introduction ................................................................................... 16 2.4.2 Implications of SNMPv3 ............................................................... 17 2.4.3 Increased distribution of management functions ........................... 20 2.4.4 CORBA for Agent Process development ...................................... 22 2.4.5 Impact of Changing Technology as represented by Active Networks ....................................................................................... 23 2.4.6 Using Web technology for service management ........................... 26 2.4.7 Evaluation of the MSM methodology and architecture................. 29 2.5 Service Providers’ Needs ........................................................................... 31 2.6 Contribution on TMN Architecture Evolution ........................................... 33 2.7 Web-based Presentation ............................................................................. 34 3 Conclusions .......................................................................................................... 35 4 Annexes ................................................................................................................ 37 4.1 D1 Annex A Evaluation of TMN Current Status - Architectural Perspective ................................................................................................. 37 4.2 D1 Annex B Evaluation of TMN Current Status - Technological Perspective ................................................................................................. 37 4.3 D1 Annex C TMN Issues ........................................................................... 37 4.4 D1 Annex D TMN Evolution Case Studies .............................................. 37 4.5 D1 Annex E Telecommunications Service Providers’ Needs for Telecommunications Management............................................................. 37 References .................................................................................................................... 39 page viii (xiii) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report Acronyms Note: The following acronyms are provided for this report and its annexes. ACSE Association Control Service Element AN Active Network ANSI American National Standards Institute AP Application Process API Application Programming Interface ASN.1 Abstract Syntax Notation 1 ATM Asynchronous Transmission Mode BIB Binding Information Base CASE Computer Aided Software Engineering CIM Common Information Model CIMSIF Circuit Management System Interface (Local to Portugal Telecom) CIR Committed Information Rate CMIP Common Management Information Protocol CMIS Common Management Information Service CMISE Common Management Information Service Element CNM Customer Network Management COM Component Object Model CORBA Common Object Request Broker Architecture COTS Commercial Off The Shelf DAVIC Digital Audio Visual Council DB Database DBMS Database Management System DCE Distributed Computing Environment DCOM Distributed Component Object Model DCF Data Communications Function DCN Data Communications Network DMI Desktop Management Interface DMTF Desktop Management Task Force DN Distinguished Name DOT Distributed Object Technology DPE Distributed Processing Environment EDI Electronic Data Interchange © 1999 EURESCOM Participants in Project P812-GI page ix (xiii) Deliverable 1 – TMN Evolution Volume 1: Main Report EFD Event Forwarding Disciminator ERP Enterprise Resource Planning ETSI European Telecommunications Standards Institute EU European Union EURESCOM European Institute for Telecommunications FCAPS Fault, Configuration, Accounting, Performance, Security FTAM File Transfer, Access and Management GDMO Guidelines for the Definition of Managed Objects GIOP General Inter-ORB Protocol GRM Generic Relationship Model GSM Global System for Mobile Communications GSMP General Switch Management Protocol GUI Graphical User Interface HTML Hypertext Mark-up Language HTTP Hypertext Transfer Protocol IDL Interface Definition Language IETF Internet Engineering Task Force IIOP Internet Inter-ORB Protocol IP Internet Protocol ISDN Integrated Service Digital Network ISO International Organisation for Standardisation IT Information Technology ITU-T International Telecommunication Union - Telecommunication Standardisation JIDM Joint Inter-Domain Management JMAPI Java Management API LAN Local Area Network LLA Logical Layered Architecture MAF Management Application Function MCF Message Communication Function MF Mediation Function/Management Function MIB Management Information Base MIT Management Information Tree MO Managed Object MOF Management Object Format page x (xiii) Research and Strategic Studies in © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report MSA Multiple Software Agent MSM Multimedia Service Management NAU Network Addressable Unit NE Network Element NEF Network Element Function NMF Network Management Forum NO Network Operator ODA Object Database Adapter ODBMS Object Database Management System ODP Open Distributed Processing OLE Object Linking and Embedding OMA Object Management Architecture OMG Object Management Group OMT Object Modelling Technique OO Object Oriented OOA Object Oriented Analysis OODBS Object Oriented Database System OODBMS Object Oriented Database Management System OOSE Object Oriented Software Engineering OQL Object Query Language ORB Object Request Broker ORDBS Object Relational Database System OS Operations System (TMN) OSF Operations System Function OSI Open Systems Interconnection OSS Operational Support System OT Object Technology PC Personal Computer PDH Plesiochronous Digital Hierarchy PDU Protocol Data Unit PNO Public Network Operator POA Portable Object Adapter POS Persistent Object Service POTS Plain Old Telephone System PVC Private Virtual Circuit QOS(QoS) Quality of Service © 1999 EURESCOM Participants in Project P812-GI page xi (xiii) Deliverable 1 – TMN Evolution Volume 1: Main Report RDB Relational Database RDBS Relational Database System RDN Relative Distinguished Name RFC Request for Comment RFI Request for Information RFP Request for Proposals RMI Remote Method Invocation ROSE Remote Operations Service Element RPC Remote Procedure Call SA Software Agent SD Service Delivery SDH Synchronous Digital Hierarchy SG Study Group SLA Service Level Agreement SM System Management SMF System Management Function SMI Structure of Managed Information SMK Shared Management Knowledge SNMP Simple Network Management Protocol SONET Synchronous Optical Network SP Service Provider SQL Structured Query Language T1M1 The name of the North American Standards Body that deals with TMN. TC Technology Committee TCP Transmission Control Protocol TIM Technology Integration Map (TMF) TINA Telecommunications Information Networking Architecture TINA-C Telecommunications Consortium TMF TeleManagement Forum TMN Telecommunications Management Network TOM Telecom Operations Map (TMF) UDP User Datagram Protocol UML Unified Modelling Language UMTS Universal Mobile Telecommunications Service page xii (xiii) Information Networking Architecture © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution VAR Value Added Reseller VPN Virtual Private Network WAN Wide Area Network WBEM Web based Enterprise Management WDM Wavelength Division Multiplexing WWW World Wide Web XML Extended Mark-up Language © 1999 EURESCOM Participants in Project P812-GI Volume 1: Main Report page xiii (xiii) Deliverable 1- TMN Evolution 1 Introduction 1.1 Purpose Volume 1: Main Report In the first year of EURESCOM’s operations, it sponsored a Project, P108 - TMN Prestudy, which described the fundamentals of Telecommunications Management Network (TMN) at the time (1992) and defined a number of Projects that would explore some topics which it said required further study. In 1997, this Project (P812 – TMN Evolution) was proposed which was intended to take a similarly broad scope recognising that TMN was under pressure to change and had changed to some extent in the previous 5 years. For example, the OMG had emerged as a driving force in the area of Object Technology by establishing CORBA as a key middleware technology (and as one of the most used acronyms of the decade). Individuals in the TMN community saw CORBA as a solution to some of their problems and worked towards the target of having CORBA recognised as an optional technology in a TMN context. This Project adopted the perspective that TMN was changing. It had the mission of describing what the prime features of TMN would be in the next millennium (not all of it, just the first few years of it). At the same time it would define what TMN-related Projects were needed to meet the implied goals of TMN1 under the rapidly changing conditions that prevail in the telecommunications industry. The Project proposers added a sub-title to the Project, namely, Service Providers' Needs for the Next Millennium, which also gives a flavour to the purpose of the Project. The Project kicked-off in January 1998. 1.2 Stated objectives At Project initiation, the following objectives were agreed: Review the role of TMN in the PNOs’ application of IT to run and manage networks and services Identify issues regarding the refinement of TMN in the light of emerging network service providers’ needs including the use of COTS (commercial off the shelf) technology Formulate recommendations which refine TMN principles and development approaches Outline further studies that may be appropriate for the EURESCOM workplan to address These objectives were satisfactory to Project participants from the points of view that they were General enough to allow the Project to adapt its approach and adjust the set of topics on which it would focus in light of what was happening outside the Project. Allowing for detailed work to be undertaken if the need and opportunity presented themselves. 1 The goals of TMN are to make the task of managing telecommunications networks and services more economical and less challenging by reducing the complexity in the associated tasks. This is not spelled out briefly in the standards text about TMN. © 1999 EURESCOM Participants in Project P812-GI page 1 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution The Project, like all EURESCOM Projects, also had the objective of disseminating its results within the organisations of the contractors and to wider audiences as opportunities arose. The reader can evaluate section 2 of this document and the material (annexes and web pages) supporting it to judge if the above objectives have been adequately met. This should not be the primary test of the Project’s results. The Project participants aimed to produce information, which will allow the readers to be better prepared to make decisions related to telecommunications management, and the ambitions they set for themselves in this regard. Many important decisions relate to telecommunications management systems, a relationship which creates the link to TMN. Questions such as the following arise: Does TMN have a broad strategic importance for planning and development of telecommunications management? What is the current and likely meaning of following the TMN standards? What benefits/costs will TMN give in the short vs. the long term? Persons dealing with the development and acquisition of management systems will face such questions in the future if they have not done so already. The results of this Project can be a resource for such people. 1.3 Context setting 1.3.1 General Project perspective This sub-section is included to allow the readers to understand some of the thinking that conditioned the production of results by the Project contributors. Any broad perspective study in the field of telecommunications management/network management/TMN will ask itself, what is TMN? TMN prompts thoughts of managed objects, use of OSI protocols, layers of management visualised as a pyramid, standards for network management, Q3 interfaces, etc. TMN as a term in itself turns out to be deceptive as the N stands for Network, but few people think of it as a network because it appears to be much more (see previous sentence). The following are possible answers to the question ‘what is TMN?’ A vision of an integrated approach to telecommunications management (the activities performed by telecommunications service providers’ staff to monitor and control the establishment and delivery of telecommunications services) An architecture for service and network management systems A set of state-of-the-art telecommunications management systems The recommended approach to management of telecommunications equipment using the OSI approach - CMIS/P (Common Management Information Services/Protocol) A set of documents issued by standards bodies which describe recommended solutions in the field of network management. page 2 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report There are arguments in favour of the veracity of each answer. In other words, TMN is/has become an ambiguous term. Interestingly, one company, Vertel, calls itself The TMN Company. If TMN is an ambiguous term, then the words TMN Evolution must also be ambiguous. To combat this within the Project, we put forward the following definition: TMN is the standardisation by ITU-T and ETSI of telecoms management of classical Public Networks and Services. TMN lives within an environment which is changing at an ever faster pace. For TMN to continue to be relevant, it must adapt to such changes including those of an organisational, technological and economic nature. It must strive for an acceptable level of stability within the stormy climate created by the IT business. TMN evolution is the process which strives to harmonise TMN with its environment. It is a non-deterministic process in the sense that nobody knows where it will end with any degree of certainty. These definitions were useful to some extent within the Project but there was still a lot of scope for ambiguity. On the basis that another EURESCOM Project, P610, had just finished and had addressed management of multimedia services [P610D4], we decided that sufficient had been said about service management at the time2 and tried to concentrate on element management and network management as they are defined in ITU-T recommendation M.3010. During discussions, we concluded that TMN is best suited to these lower layers of management, and that business and service management (at least some aspects of it) are candidates for being phased out of TMN - more about that in section 2. 1.3.2 Concurrent relevant activity It is evident that telecommunications management is a dynamic subject which is not very well co-ordinated. While P812 was progressing its work, a number of other bodies were making changes, issuing documents, etc., which have a bearing on TMN evolution but no individual or body keeps track of the various changes and reports on their interdependencies. The following briefly describes results of these bodies as background to the work of this Project. The bodies in question here are TMF, ITU-T, TINA, and IETF. The recent results of the TeleManagement Forum are presented at some length here because they fulfil one of the aims of this Project at the proposal stage. This was an aim concerning a Technology Roadmap. We did not pursue this aim because we were confident that TMF would provide as good a roadmap as was feasible on this subject. TeleManagement Forum The TeleManagement Forum used to be called the Network Management Forum (NMF). It has issued many important high-level documents relevant to TMN in the course of its lifetime. The following provides an overview of recent important work. 2 P610 had defined an architecture and methodology associated with the development of service management systems, albeit targeted at multimedia services, which we did not wish to explore further. P610 did not reflect a TMN approach in their results but produced replacements for aspects of TMN. © 1999 EURESCOM Participants in Project P812-GI page 3 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report Technology Map Framework The TMF work programme is developing a Technology Integration Map (TIM) and a Telecom Operations Map (TOM), and a framework has been designed to show the relationship between the various elements (see Figure 1). The framework has adopted a top-down approach starting from the business needs, which contrasts with the bottom-up technology frameworks of many other industry and standards bodies. A business scenario represents specific telecommunication needs which use the various layers to obtain the necessary components to meet the needs represented in the scenario. Given a top-layer business need, the framework provides the means to consider the application models and component designs to be adopted, the technology components to support the application models and the off-the-shelf components appropriate for the context. Business Service Network ‘Layer’ Issues Element Applications Direction (how system solutions are formed ) (re-usable application components) Technology Direction (technology selections) (systems infrastructure services) Procurement Guide (SPIRIT - extended) (Standards selections) • FCC issues • CSM • etc... Systems Management (supplying Management services) Security Specific Business Scenario Business Drivers Telecom Operations Map SM / NM / EM • business processes • process interactions • associated information models • atomic • client server models (peer-to-peer / master - slave paradigm) • 3 tier / 2 tier Architecture • component granularity • objects • TMN (framework / reference points) • TMN (protocols - CMIP / Q3 /Qx • CORBA / DCE / DCOM, OLE • Distr. Transaction Processing • SQL - Net • JAVA (mobile code) • Internet / Intranet • Distribution • Communications • User Interface • Language selection / internationalization • etc... Other Industry Organizations • relationships • gap analysis (e.g OMG, ITU, TOG, etc.) Figure 1: Technology Map Framework Technology Integration Map (TIM) The TIM is intended to identify basic implementation technologies which can be used to build operational support systems and is composed of a Technology Direction Statement, an Applications Components Direction Statement, and a Procurement Guide. The latter is very detailed and does not warrant description here. In the case of the Application Components, sufficiently stable work was not available to be reported at the time of writing. The Technology Direction Statement discusses the technologies required to support the operational support systems of telecom service providers and network operators. Various technologies have been identified for different system roles based on responses given in interviews with service providers and from workshops held to discuss the issue. As several technologies have been selected, a number of technology integration points have been identified where different technologies will need to be page 4 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report integrated (see Figure 2). The integration points support the integration of various technologies, such as Web browsers, Java, CORBA, CMIP and SNMP, by providing mappings between appropriate technologies. Internet Application Objects CORBA Facilities Web Browsers Domain I/Fs 3 1 2 GDMO / SMI CMIS / SNMP Java 4 CORBA Services Object Request Broker Manager 5 Manager / Agent Environment Agents Figure 2: Technology Integration Points Telecom Operations Map (TOM) The TOM is based upon results from the Service Management Business Process Model and the Network Management Business Process Model. It presents a model of telecommunications management based on the processes required for network and service management and provides a "process" view of "operations". The idea behind the TOM is to show the processes comprising "operations" and how they can be automated. Figure 3 provides an overview of the contents of the TOM. Fulfilment Assurance Order Handling Sales Problem Handling Customer QoS Management Billing Invoicing/ Collection Customer Care Processes Service Planning/ Development Service Configuration Service Problem Resolution Service Quality Management Rating and Discounting Service/Product Development and Maintenance Processes Network Planning/ Development Network Provisioning Network Inventory Management Network Maintenance & Restoration Network Data Management Network and Systems Management Processes Figure 3: TMF Process Model The Map is intended as a framework for further TeleManagement Forum work and provides a common vision and perspective across the teams. More detailed work on the individual processes has started and will further extend the TOM as required. The first stable draft of the TOM has been issued, even though it is recognised that further work is needed, notably in the areas of commonly agreed definitions for concepts such © 1999 EURESCOM Participants in Project P812-GI page 5 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution as process, policy, and in the business model, for modelling roles as opposed to legal entities. The relationships between the roles/legal entities have not yet been adequately modelled and there are proposals to adopt some modelling concepts from TINA in the business modelling area. ITU-T Section 2.2.3 below deals with the relevant ITU-T activity. TINA Telecommunications Information Networking Architecture (TINA) Consortium has addressed management as part of their architectural approach. This approach has many components that stimulate an evolution of thoughts about telecommunications management and associated support systems. These include a Business Model which uses reference points as a boundary between industry players such as consumers and service providers. Earlier on it made impressive strides with computational modelling and information modelling principles which have been influential in promoting an ODP-based approach. This consortium has been in existence since 1991 but its impact has not been as significant as originally thought. It is considered to be more important at the service management level rather than the lower levels of management. It is a possibility that TINA will influence TMN via its inputs to the OMG rather than directly to ITU-T SG 4. However, it can be difficult to clearly identify influences as many of the same companies participate in all 3 bodies and internal influences in organisations are rarely visible. Internet (IETF) Operations and management activity in the IETF has made progress with the specification of SNMPv3 (Simple Network Management Protocol version 3). This development makes it more likely that the large investment in SNMP-MIBs made by ATM technology vendors will be recognised as an acceptable way of performing management of public networks. As the IP protocol is increasingly being favoured as a part of the delivery of multimedia communications in public as well as private networks, it will become important that SNMP is seriously considered within the framework that can be termed the Evolved TMN. It is also worth noting that IETF is concerned with Active Networks. Active Networks represent a new paradigm for creating, integrating and managing services that makes use of techniques not available when conventional networks and their management were designed. [Tennen97] page 6 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution 2 Results 2.1 Introduction and some general comments Volume 1: Main Report The results of this Project are a reflection of its technical approach. This followed a classical organisation with the Project in three separate phases: Gather information to determine the current situation; Analyse this information, collecting information of a greater depth where required, to identify issues that needed to be addressed to fulfil the Project’s remit; Address a number those issues in greater depth The organisation of this chapter follows that of the Project itself. Firstly we present some information that whilst not fitting into the structure of the majority of the results is pertinent to the subject and was central to the later results. This includes some of the various opinions held about TMN and some hard facts about TMN not discussed elsewhere. Section 2.2 considers the current situation, from 3 different perspectives, Architectural, Enabling Technologies and Standards bodies. Section 2.3 discusses the issues that in the Project’s view are the most pressing for near term TMN evolution. Section 2.4 presents the Evolution Case Studies. It was felt that rather then trying to explore all the issues identified a better way forward would be for each Project participant to consider one or two of the issues in depth in the form of case studies. As an adjunct to determining the current TMN situation and future evolution, a study was conducted that aimed to identify the needs that a Telecom Service Provider has in fulfilling their role. This is presented in Section 2.5. Finally Section 2.6 discusses the contribution that was made by the Project to ITU-T SG4 suggesting changes to M301X/Y and Section 2.7 explains how to access the full results via the WWW. The progress of the Project did not mirror this ideal plan completely because there was some overlap between the phases. In fact, as a means of starting the Project, we initially brainstormed some issues as a way of ensuring a common understanding among the participants. Essays were written to explore some of the issues, resulting in some very valuable tutorial material for the Project participants. Opinions about TMN It was clear that the Project participants had views about the shortcomings of TMN and what needed to be done to improve the situation. Rather than rely on our own, possibly biased, views on TMN, we interviewed non-Project participants employed in the contracting organisations. Attempts were made to include both developer and purchaser roles among the people spoken to. There were attempts to make the information collection systematic but this was only moderately successful. Distilling opinions that were offered, it was found that: Early experiences of attempting to apply TMN were not encouraging TMN was associated with complex expensive solutions The presentation of information on TMN was fragmented and hard to navigate Purchasers are not willing to demand TMN-based solutions as the only solution TMN layering causes confusion when applied in system implementations © 1999 EURESCOM Participants in Project P812-GI page 7 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution There was the feeling that TMN was making progress but slow in doing so Some people with real responsibilities in the area of telecommunications management had only a hazy idea of what TMN might do for them Newer technologies such as CORBA are hoped to be able to provide a better alternative. Even though we could not say that these were widely held opinions, we found them useful as they accorded with our own understanding. This we would summarise as, TMN is a far distance from fulfilling the expectations that people had of it five years ago. Hard Information about TMN We envisaged developing a deep understanding of TMN in terms of its practical application. We thought we would be able to find out data such as: How many of the big vendors provided certain Q3 interfaces according to particular standards? What calls for proposals have been issued by service providers and are they usually specifying TMN standards? What TMN systems have been deployed in recent years? However, we did not find such information readily placed in the public domain or available to purchase. You can find information about certain TMN-focused companies’ intentions and offerings in the area of TMN support technologies, but even this information becomes outdated very quickly as these companies merge with each other and make deals to use each others modules. The Project did identify two reports available for purchase that we believed could add to the quality of our work, while saving time for the Project. The first of these reports is produced by Dittberner Associates, entitled PROJECT ESS Update 36, "Operational Support Systems- An Operator's Perspective, 1998". Among the principal findings and conclusions presented in this report, and which are relevant to TMN evolution, are the following: A completely new generation of Operational Support Systems has been developed by a number of both competing and co-operating OSS system suppliers, largely conforming to the TMN model, and often embodying some aspects of object-oriented technology. * Telecom users are unwilling to accept full object-oriented technology in their mainstream of OSS capabilities to date, since there have been significant failures of such systems in middleware and database applications. Telecom operators are proceeding cautiously with a gradual introduction of object-oriented technology, but are gradually introducing TMN architectural concepts into their legacy systems. * Most large telecom operators with legacy systems are moving toward a 3-tiered processing architecture, retaining or even increasing their mainframe capacities to provide support for billing and provisioning systems. * Telecom operators are demanding that OSS vendors work together either in strategic alliances or joint ventures to insure that their OSS module offerings are compatible with each other, reducing the amount of effort and delay experienced by the operator in attempting to use their separate modules. page 8 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report These conclusions are not the only valuable information in this report from a TMN perspective. See also www.eurescom.de/public/Deliverables/wwwdeli.htm. [Dittberner] includes a study of OSS TMN compliance among the data collected. Seventy OSS product vendors were surveyed. Between them they reported on the compliance of 251 OSS products to TMN. 24 companies claimed Full TMN compliance3 in at least one of their products, while another 24 claimed Partial TMN compliance in at least one of their products. This means that nearly 70% of these vendors support TMN. They may differ in their interpretation of what TMN compliance is, but it is clear that TMN is important to OSS vendors. Out of the 251 systems, 70 (28%) claim to be fully TMN compliant while another 69 claim to be partially TMN compliant, i.e., more than half the systems are at least partially compliant. The survey also enquired about NMF and CORBA compliance. Forty companies claimed some CORBA compliance in their products with 35 claiming some NMF compliance. Regarding the systems and CORBA and NMF compliance, 77 (31%) are said to be CORBA compliant to some extent, while the equivalent figure for NMF compliance is 76 (30%). These percentages indicate that TMN is the most influential standard in the OSS world at the moment and it has made significant inroads into the product plans of the majority of vendors. There are still many OSS products (95) which do not comply with any of the standards referred to here. This data on compliance is very superficial and only serves to convey the idea that TMN is still relevant. It is difficult to plot a reliable course for future TMN development work when concrete data on its uptake is not available. EURESCOM Headquarters has a full copy of the Dittberner report. The second report is fully targeted at TMN. It is published by Probe Research and entitled TMN: The Pivotal Technology for the Multi-Network Future. Its publishing date is 1997. See www.proberesearch.com for information on the authors. The following extract from the report supports our understanding of the current TMN situation: A year ago, there was concern about the viability of TMN, but today there is a broad recognition of the value provided by TMN-based solutions for managing complex, global telecommunications networks with millions of nodes. Even though simple network management protocol (SNMP), TCP/IP-based solutions and other proprietary protocols in the enterprise local area network (LAN) have been extensively used, carriers have experienced first-hand the inadequacies of these protocols when trying to use them with ATM backbone switches. Two years ago, there were few TMN projects, but today the amount of activity has increased by a factor of four. This year, U S WEST alone has a dozen TMN projects and is funding a significant amount of research work through Bellcore. There has also been a commitment to TMN from equipment manufacturers as well, particularly transmission systems and access nodes, and all next-generation 3 The precise meaning of full and partial compliance to TMN is not defined. © 1999 EURESCOM Participants in Project P812-GI page 9 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report telecommunications equipment (GSM, synchronous optical network/synchronous digital hierarchy (SONET/SDH), and ATM/intelligent networking (IN]), with more than half of the activity in GSM and less than 20% in fixed telephony. There are currently few benefits in moving plesiochronous digital hierarchy (PDH) switches or older technologies from legacy to TMN. The current generation of voice switches do need standards and TMN will help here. Carriers are increasingly letting manufacturers know that TMN compliance is a requirement in purchasing decisions. Reaching TMN’s goals requires co-operation between the service providers, the OS vendors, the network element vendors and the vendors of mediation devices, Qadapters and network integration devices to manage today’s networks and pave the way to TMN. The full Probe report is available via www.eurescom.de/public/Deliverables/wwwdeli.htm. It provides some interesting material in identifying reasons why TMN must evolve, and is not shy regarding problems with TMN. An overview of its views in this regard is presented in its executive summary under the headings Obstacles to Implementation and TMN Limitations and in the main body of the document. Readers of this document are strongly recommended to access this report as it contains material that we consider conveying important views about TMN which we felt we should not waste time repeating. The provision of the Probe report is as much a part of this Project’s result as any other part. The results are presented here starting with three sub-sections describing the current TMN situation from three perspectives, one architectural, another technological and another from the standards viewpoint. Next, TMN issues are presented. This is followed by descriptions of TMN Evolution Case studies performed by the Project participants. Finally, the work which defines a set of needs attributable to service providers as they face the turn of the century is previewed. 2.2 Evaluation of TMN Status Three perspectives are taken in this section: architectural, technological and standardisation. This section summarises D1 Annex A and Annex B. Standardisation is not elaborated upon in either Annex. 2.2.1 Architectural perspective Many think of TMN only in architectural terms being familiar with some well-known diagrams (the layered pyramid, OS-DCN-NE, etc.) presented at conferences, and so on. ITU-T Recommendation M.3010 sets out three TMN architectures (functional, information and physical) as a way to establish the principles of a TMN. While this material has attracted a lot of attention, it paints but a part of the picture. One important dimension of the TMN problem space not addressed so far by ITU-T is the architecture of Operations Systems/Management Applications. We took the perspective that architectures from non-ITU-T sources are likely to fill the gaps in TMN and are coming to the surface as influencing the evolution of telecommunications management systems and, as a consequence, the evolution of TMN. In D1 Annex A of this report, we briefly describe a selection of such architectures and evaluate them. The Web site www.eurescom.de/public/Deliverables/wwwdeli.htm contains detailed information about each of the architectures evaluated. The selected architectures are: OMG (Object Management Group) page 10 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report DMTF (Desktop Management Task Force) TINA (Telecommunications Information Networking Architecture) IETF (The Internet Engineering Task Force) - SNMP DAVIC (The Digital Audio Visual Council) TeleManagement Forum (formerly NMF) In cases where the full architectures are not relevant to management, only management-related aspects are considered. Each architecture has been examined from two points of view: attributes of the architecture relevance to TMN evolution. In the case of attributes, we reflect on the maturity of the architecture in question, whether it’s complementary to TMN or not, the implementation support it provides, its ease of use and its likelihood of survival. High scores on these attributes mean that it could be worth investing in for itself. In the case of relevance to TMN evolution, each architecture is considered in terms of its impact on non-architectural aspects of TMN, which are methodologies, functionality (management applications level), enabling technologies and the needs and drivers for TMN evolution. Scores on these aspects indicate how the architecture is expected to impact. The result of these deliberations is to highlight OMG results as being the most significant architectural influence outside of ITU-T on telecommunications management systems. CORBA and other aspects of the OMA (Object Management Architecture) seem to be the means of closing significant gaps in the architectures for telecommunications management systems at the OS (Operations Systems) level. The TeleManagement Forum is also highly influential but does not define new architectures per se, rather it shows how the external architectures may be combined to produce solutions that the industry can use. In doing so, it is likely to be influential in shaping future ITU-T and OMG work. The evaluations are made to provide some food for thought and further investigations rather than to promote or demote the architectures in question. They are all important but they are not equally important to all aspects of the greater TMN environment. See D1 Annex A for a more detailed summary of the architectural perspective and Web site www.eurescom.de/public/Deliverables/wwwdeli.htm which contains even more detailed information about each architecture evaluated. 2.2.2 Enabling technology perspective Technologies are a critical part of the successful implementation of a TMN. A number of technologies are needed to realise a complex set of systems such as those that constitute a TMN. Such technologies we refer to as TMN enabling technologies. In the early 90s, it was typical that network elements were built using technologies that were proprietary to the vendors of such elements. Many OSs were built using technologies that could be generally classified as information processing systems using development methods such as structured analysis. It was common that procedural languages such as C or COBOL were the programming languages chosen © 1999 EURESCOM Participants in Project P812-GI page 11 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report for management applications. ISO-OSI Reference model based software was the recommended communications technology and OSI management technology (CMIS/CMIP) became synonymous with TMN. The range of technologies to be used has been a feature of TMN evolution. From the outset, TMN embraced object orientation but the tools to underpin the use of this technology (paradigm) have only matured recently. We have examined a number of enabling technologies and presented information related to them as part of this Project in D1 Annex B and in more detail at URL www.eurescom.de/public/Deliverables/wwwdeli.htm. The enabling technologies evaluated are: CMIS/CMIP SNMP CORBA UML WEB -http.v1 Java Relational Databases Object Oriented Databases You will immediately recognise that these technologies do not substitute for more than one or two others, so they are not comparable in that sense. They play different roles in the TMN development life cycle. Some technologies are left out which you might expect to be included. In particular, Agent Technology may come to mind. There are two reasons for its omission, (a) it is not yet developed such that it is influencing TMN evolution though it may well do so in the future, and (b) there are two EURESCOM Projects (P712 and P815) devoted to exploring Agent Technology in a telecommunications management context. In a similar vein to the evaluation of architectures, enabling technologies are evaluated in terms of inherent attributes (stability/maturity; ease of use; and likelihood of survival) as well as in terms of their contribution to TMN evolution, which is decomposed as follows in this case: Evolution of the early life cycle phases of management application development Evolution of the later life cycle phases of management application development Evolution of TMN Run-time platforms Evolution of development platforms typically used by telecommunications management system developers Service and Network management applications Element management applications TMN standards Significance (which tries to summarise the overall impact of the technology). The evaluations are made to provide some food for thought and further investigations rather than to elevate or deflate the technologies in question. They are all important but they are not equally important to all roles in TMN development. page 12 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report According to our reckoning, the technologies that will have most influence on the evolution of TMN in the short term are CMIS/P, SNMP and CORBA. It is likely that the co-existence of these three technologies will become the predominant feature of TMN in the near future, but the possibility exists as well that other technologies, such as Java and Web-based technologies, will also play an important role in the medium term. The reader may benefit from referring back to Figure 2 to appreciate the relationship between the technologies. As a final remark, we wish to say that we have omitted a technology which came to our notice after the Project had agreed its plans for the evaluation of the status of TMN, namely ERP (Enterprise Resource Planning) see www.sap.com/products/industry/tele/index.htm. This is a type of solution that is being considered by telecommunications operators as a means of automating the flow of work throughout the organisation. It looks like ERP could have a major impact on the general business and service management functions of a service provider. Will this mean that ERP will become a TMN enabling technology? It would seem unlikely which will mean that TMN will not be as significant for higher levels of management as was originally envisaged. 2.2.3 Standards bodies perspective a) ITU-T P812 was performed during the ITU-T study period starting in 1997 and ending in 2000. ITU-T had started making changes to TMN standards according to the work programme for that period. ITU-T Study Group 4, which is charged with TMN related work, had no fewer than 10 questions addressing TMN developments as follows (x/4 indicates the question number): 12/4 Quality assurance for TMN specifications 13/4 TMN Principles, Architecture, and Methodology 14/4 OSI system management 15/4 Requirements Integration and Management Information Models for TMN Interfaces 16/4 Requirements for the TMN F interface 17/4 Requirements for the TMN X interface 18/4 Network level management of transmission systems 19/4 Protocols to support operation, administration and maintenance at F, Q.3 and X interfaces 20/4 Protocols for the remote operation of management applications 21/4 Managed object definitions for management of telecommunication services, for network management and for network elements, based on TMN interfaces Much of the work under these questions can be seen as a consolidation of TMN 1996 style rather than an evolution of TMN. However, there have been changes of a semiradical nature. These include: © 1999 EURESCOM Participants in Project P812-GI page 13 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution Addition of OMG’s IIOP (Internet InterORB Protocol) as an optional component of the X-interface specification. Use of ODP (Open Distributed Processing) viewpoints and ODP viewpoint specification languages for network level management of transmission systems. An agreement at working group level to use UML (Unified Modelling Language) as adopted by the OMG as part of a revision of the Recommendation M.3020, Methodology for TMN Interface Specification. These are noteworthy because they show that ITU-T SG 4 is starting to endorse the use of standards other than ITU recommendations and ISO standards. Perhaps the most interesting development has been the work to make a substantial change to the key recommendation M.3010, Principles for a Telecommunications Management Network. It is well known that this recommendation describes the TMN from an architectural perspective. The prime aim of the revision is to define the architectures in terms such that they do not lead directly to using the ISO-OSI Systems Management approach to the practical exclusion of other approaches. This work is not completed at the time of writing (February 1999) but it is confidently predicted that it will be brought to a successful conclusion and that we will have a protocol-neutral TMN architecture for the year 2000. As an indication of the progress of TMN work in the years 1997 and 1998, the following revised or new recommendations have been published in those years. Addendum 1 (06/98) Recommendation M.3010 - Principles for a Telecommunications Management Network Addendum 1: TMN conformance and TMN compliance Recommendation M.3016 (06/98) - TMN security overview Corrigendum 1 to Recommendation M.3100 (07/98) - Generic network information model Recommendation M.3200 (04/97) - TMN Management Services: Overview Recommendation M.3208.1 (10/97) - TMN management services for dedicated and re-configurable circuits network: Leased circuit services Recommendation M.3300 (06/98) - TMN F interface requirements Recommendation M.3320 (04/97) - Management requirements framework for the TMN X interface Recommendation M.3400 (04/97) - TMN management functions Recommendation M.3611 (04/97) - Test management of the B-ISDN ATM layer using the TMN Recommendation M.3650 (04/97) - Network performance measurements of ISDN calls. It can be seen that some of the gaps in TMN recommendations are gradually being filled but the criticism that most of the recommendations are verbose and open to ambiguous interpretation still applies. Is it good enough to agree generic requirements in a strictly prose format? b) ETSI TMN-related activity within ETSI has been almost dormant during 1998. However, studies have been ongoing in the area of UMTS (Universal Mobile page 14 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report Telecommunications Service) Management applying the principles of TMN. So far this work has not given indications of how the new requirements of UMTS management will stimulate the evolution of TMN. 2.3 TMN Issues This section summarises D1 Annex C. Work in this EURESCOM Project P812 has examined many aspects of TMN as it exists today. This examination, combined with open debates within the Project, has raised concerns about the progress towards the creation of a reasonably complete set of high-quality specifications for TMN. We feel the goals are not clear, particularly in terms of their eventual achievement. The reasons particular items are being progressed (while others are not) are hard to determine and the quality of what has been produced is hard to judge. Uncertainties about TMN and its progress are the subject of this study which we say addresses TMN Issues. How do we define this term? Project participants formally defined a TMN issue as: A question, or other expression of an uncertainty, about desirable or undesirable aspects of TMN which needs to be tackled in order that TMN-related knowledge can reach a state which is stable and of significant value to its intended users. In particular, an ‘issue’ is a problem or uncertainty that stops, or will stop progress on TMN within the next three years. Excellent work has been done by the TMN community but we feel that the time is ripe for an appraisal of the current gaps between the perceived situation and a more ideal situation. This critical analysis of TMN as it is today is done only in light of dramatic changes in the market and business climate. The aim of the TMN Issues document (D1 Annex C) is to identify issues which should be addressed in Projects or through other means such as study groups, working parties, etc. The reason for addressing them is to provide a less confusing environment in which the important work of telecommunications standardisation should continue. In other words, the identification and understanding of these issues is a crucial part of TMN evolution which we define as adapting TMN to the changes in the environment in which it exists. The issues as defined can be thought of as a menu from which work items can be selected. A small number of the issues that have been raised are explored in some depth as reported in section 2.4 of this document. The issues covered in D1 Annex C are broadly grouped into the following categories: Issues traceable to service provider needs Issues with respect to current ITU-T TMN architecture and standards Issues with respect to standards bodies and the standardisation process Issues with respect to future TMN standards Issues with respect to new and emerging technologies. The issues are phrased as questions and text is provided which explains each question. A sample of the questions giving expression to the issues is presented in the next few paragraphs. © 1999 EURESCOM Participants in Project P812-GI page 15 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report What are the technical challenges to be faced when an integrated management environment is to be made from older mainframe based systems (legacy systems) and systems based on TMN and distributed object technology? How valuable would a Common Network Management Information Model be? Are the TMN information modelling techniques (ASN.1, GDMO and OSI-GRM) sufficient for specifying requirements of present day management systems? If not, what are the shortcomings? What are the best 'partitioning' principles for TMN functions? What is the best process for producing timely TMN standards? How should a multiplicity of information models be coped with? How can the TMN standards be future-proofed to ensure that future developments in technologies and services can be accommodated within the TMN standards? What are the impacts of increased distribution of management functions in the OS-NE interface? We have not prioritised the issues we have raised because doing so within the Project would not have produced reliable results and we did not have a means to gather outside opinions on these issues. (Most people are too busy to respond quickly to a request that 20 or more pages are examined.). However, it is worth noting that when a number of individuals involved in EURESCOM Projects were asked what priority they would give to a number of possible work items, the top score was given to the production of interface specifications, both between service provider domains and within the one provider domain. A detailed presentation of the issues can be found in D1 Annex C and at the Web site www.eurescom.de/public/Deliverables/wwwdeli.htm. 2.4 TMN Evolution Case Studies This section summarises D1 Annex D 2.4.1 Introduction As mentioned elsewhere in the annexes to this Deliverable, TMN needs to make steadier progress and we wish to contribute to this. Identifying the more challenging aspects of TMN, describing them and sharing them within the TMN community can enhance such progress. Doing so raises awareness and may motivate the deployment of additional resources, particularly if the problems highlighted are interesting. Another means of making progress is to suggest solutions to problems. This can be done in the form of recommendations (according to the more general meaning of the word). However, we try to link our recommendations to ITU-T TMN recommendations in some cases by suggesting how such recommendations could be improved. Finally, there is a tutorial aspect to making progress, in the sense that if those interested in TMN have a wide range of knowledge about matters that are currently outside of TMN but relevant to it, they will be aware of a wider range of options. For example, IN (Intelligent Networks) is outside of TMN but it can have functionality which can complement management functionality and so reduce the functionality required of TMN. As network technology evolves, it affects the evolution of TMN. For this reason, we have not shied away from providing tutorial material as part of our results even if tutorials cannot be regarded as recommendations. page 16 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report Scope It is easy to imagine that a large number of studies on aspects of TMN evolution might be performed in order to provide a vision and road map of where TMN could be improved and brought to a stable situation. The resources are not available within EURESCOM to conduct a large number of studies of this nature and indeed, it can be argued that this is not the role of a single organisation such as EURESCOM. The Project participants undertook to make some recommendations related to TMN evolution in order to give the TMN community the benefit of its thoughts on the subject in a general sense, and to give EURESCOM management indications of work related to TMN that might performed within its programme. It was decided that the contractors should perform a set of case studies that were within the scope of their interests and knowledge and were indicative of key aspects of TMN evolution. A set of case studies was undertaken addressing the following: Implications of SNMPv3 Increased distribution of management functions CORBA for agent process development Impact of changing networking technology Using the Web for service management Evaluation of the MSM (Multimedia Service Management) methodology and architecture The following important aspects of TMN evolution have been touched on by the case studies: Protocols Architecture Enabling technologies Standards Methodologies Editor’s Comment: If you intend to read D1 Annex D which has more extensive information on the case studies, perhaps you should go there directly and save yourself reading 10 pages which you may not need to read. The full-length versions of the reports on these studies can be reached via the access page for the EURESCOM TMN Evolution Web site, www.eurescom.de/public/Deliverables/wwwdeli.htm. 2.4.2 Implications of SNMPv3 2.4.2.1 Trends and Forces in Telecommunications Management: The IP Datawave and the SNMPv3 Management Framework IP networking is growing at phenomenal rates. Carrier size Voice over IP (VoIP) offerings from manufacturers like Cisco and Lucent are bringing the traditional © 1999 EURESCOM Participants in Project P812-GI page 17 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution telecommunications telephony market into close reach of new operators, expecting to be able to offer cheaper services transported over IP networks. The telecoms world is looking at the IP datawave as an opportunity to attract customers and reach new markets. IP networking has traditionally been managed through the work of the Internet management framework, i.e., the Simple Network Management Protocol (SNMP) architecture. If telecom companies are going to offer IP services, it becomes necessary to investigate SNMP as a technology for managing these networks. On the other hand, TMN represents the efforts of telecom companies around the globe to standardise their management systems framework in order to achieve much desired interoperability. The study evaluates the SNMP framework as a constituent of an evolved TMN, as an enabler of fast and low-cost development of effective network management solutions for managing IP networks. The IETF is completing a new version of SNMP – SNMPv3 – which is claimed to address many of the failings of SNMPv1, including its ability to scale up to handle large networks. The question is whether SNMPv3 is adequate to be included as a protocol choice for communication in TMN standards. 2.4.2.2 Impact of SNMPv3 on TMN Development Activity: Considerations For SNMPv3 to be considered adequate for use in TMN, it must be able to perform the function required from a management protocol (i.e., transfer of management information) and it must satisfy a minimum set of core non-functional requirements namely security, scalability, reliability and low cost. This is in contrast to the ideal solution of a protocol choice satisfying all the non-functional requirements of TMN, at an appropriate cost. The goal of the report is not to judge whether SNMP is as good as CMIP/S (the management protocol normally associated with TMN). Note that there isn’t any clear and consistent source of information available stating the requirements for a protocol to be used in TMN. If TMN recommendations do not change to accommodate SNMP as a protocol choice for managing IP networks, or else if they fail to provide a real alternative to SNMP (i.e., which is accepted by the manufacturers of IP equipment), then it is probable that SNMP will dominate the IP network management market until one of the following happens: 1) SNMP fails to deliver suitable large-scale management systems, over technical shortcomings, and the rollout of IP services by telecommunications operators is hindered. 2) SNMP succeeds in delivering scalable solutions to network management problems, and CMIP/S and TMN become solutions to shrinking and solved problems, ultimately resulting in the ceasing of TMN evolution. From a purely technical perspective, it is clear that SNMPv3 is weaker than CMIP/S from the viewpoints of modelling, flexibility and power. However, it offers security services and low development cost. page 18 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report The security work in SNMPv3 is still incomplete, although only minor changes and clarifications are being performed on the respective Internet drafts4. The IETF SNMPv3 Working Group believes that SNMPv3 will be adequate to provide effective security services for network management over IP networks. 2.4.2.3 SNMPv3 Related TMN Initiatives and Changes: Recommendations The recommendations arising from this study are as follows: 1) This study has revealed no theoretical reasons why SNMPv3 should not be used as a protocol for building TMN-based systems satisfying the core requirements of security, scalability, reliability and low cost. However, as in all large systems, good engineering practice derived from experience is vital. Therefore, we recommend that the network management community in view of scalability investigate the use of SNMP for large-scale management systems, mainly addressing the following: a) The need for polling the network elements and its implication on scalability – anyway, in many cases, periodic polling is advisable, e.g., in a performance management context. b) Providing adequate support for building decentralised management architectures – how adequate that support is presently is not clear and can impact on scalability. c) Complexity of the Manager side of the architecture – if the Manager side is too complex it might pose scalability problems, however this problem might be attenuated by setting adequate support for decentralised management architectures. 2) For small-scale management systems, SNMPv3 is adequate and it is recommended that it is included as a protocol of choice for TMN in the M.30xx set of recommendations. Recommendations Q.811 and Q.812, which deal explicitly with protocols, will also have to be changed. 3) A study needs to be carried out to produce criteria to describe and enable comparison between management protocols in terms of their adequacy for use in TMN (such as, requirements for large-scale systems including scalability, reliability, security, etc.). 4) Finally, if SNMPv3 proves not to scale to large management systems, it is recommended that the IETF and the ITU-T work together in order to promote work on other protocols for managing large-scale IP networks. Alternatively, an effort will be required within the IETF to further modify the SNMP architecture in order to address potential problems. In spite of this, it is likely that SNMP evolution will continue beyond SNMPv3, building on the experience acquired on the implementation and deployment of this new version. 4 Note: at the time of writing, the SNMPv3 specifications are in WG last call with the closing date of 9th Feb. 1999. The documents will then be forwarded to the IESG for the IETF last call, around 26th of Feb, to be approved to Draft status prior to the next IETF meeting (March 15-19). After approval as Draft, there is a minimum wait time of four months or one IETF meeting. If the specifications were to advance to full Internet Standard on this minimum timeframe, this would occur sometime around July 1999, at best. [Information supplied by Russ Mundy, chair of the SNMPv3 WG, personal e-mail communication with authors] © 1999 EURESCOM Participants in Project P812-GI page 19 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report 2.4.3 Increased distribution of management functions 2.4.3.1 Introduction Here we provide an overview of a study addressing the impact of increased distribution on NE-OS interfaces. This study report begins by acknowledging the trend in implementing management functions as a set of small-scale software units Software Agents. It then explores how current TMN architectural concepts (M.3010) and the interface technology CMIS/P can be used to adapt to this trend. Finally, recommendations are given to facilitate incorporating the approach proposed in this study into TMN work. 2.4.3.2 Increased distribution: trends and forces There are emerging trends in implementing management functions as a set of 'Software Agents' - SAs. These software agents are units of software with independent control threads whereby a management function is built as a set of such agents that cooperate to achieve the goal of that management function. In one particular approach, Multiple Software Agents - MSA, many small-scale software agents, often interacting in a peer-to-peer fashion, are used to implement a management function. This is in contrast to other approaches where SAs are organised in a hierarchy. This study has taken the MSA approach and has explored its implementation options when TMN architectural concepts (ITU M.3010) and TMN interfacing technology (CMIS/P) are used to implement them. To quantify the size and degree of distribution in existing systems, current ATM networks are used as an example. This indicates that typically ~10 software systems are used, each managing various aspects of ~100 network elements, with each software system realising an OSF of M.3010 implemented as an OSI-SM application process (AP) on a workstation. When the MSA approach is used in conjunction with the TMN architecture, there will be a drastic increase in the number of application associations (set up using the OSIACSE) and quantity of EFD objects. The next section examines how TMN can adapt to these changes. 2.4.3.3 How TMN can adapt to increased distribution To model a management system of this size, in the MSA approach, approx. 1000 SAs are required (in contrast with 10 management systems in current systems). This study has then looked at three ways of modelling the management system as a set of SAs. In the first approach where a strict interpretation of TMN is used, each SA is modelled as an OSF of M.3010. In this case, it is shown that the number of application associations set between SAs in a workstation to a NE increases sharply. Also, the number of EFD objects to be set up in NE agent processes increases manifold. As SAs each manage a very small set of MOs, it is reasonable to assume that scoping and filtering will not be required. This implies that NEs need not implement full functionality of CMIS (CMIS capability is defined in terms of functional units which can be negotiated at association set up time). Furthermore, with such a large set of SAs and the increased dynamism (creation and modification of existing SAs), the use of a directory service (by the agent processes and management processes administering creation and deletion of SAs) is mandatory. In existing systems with a small number of software systems, name-address translations can be ‘hand-coded’. page 20 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report In the second approach, to overcome the overhead of a large number of associations to NEs and also to minimise the number of EFD objects in NEs, one SA (interface SA) within each workstation can act as a Mediation Function (MF) for all other SAs in that workstation. In this case, the interface SA uses a single association and a single set of EFDs is set up in NEs to transfer the events of interest of all SAs. Since SAs still represent OSFs, the inter-SA communications will be modelled as inter-OSF interfaces which are specified by M.3010 as q3 reference points. In the last approach, we can keep the interface SA to minimise connections and SAs, but we choose to implement SAs using non-OSI application processes. In this case, their interfaces will be totally internal to a workstation and thus inter-SA interfaces will be non-standardised. Note that in these latter approaches, the objective of increased distribution is defeated by the fact that each interface SA needs to keep a large MIB of all NEs being managed (at least the names of MOs need to be maintained by interface SAs). 2.4.3.4 Recommendations In order to accommodate the MSA approach, TMN architecture and the current interpretations of it and its technology need significant revisions. With this regard, recommendations of the study are: Recommendation to ITU-T for TMN Architecture: ITU-T SG 4 should give more accurate and precise definitions of functional and physical models and how they are related. Recommendation for further study within ITU-T TMN architecture: ITU-T SG 4 should allow support for small-grain as well as large-grain OSFs and should give guidelines on when OSFs with different granularities should be used. Recommendation for further study by TMN research community5: Substantial research should be done in specification of Q interfaces for peer-to-peer OSFs together with guidelines on how to use them. Recommendation to TMN designers and developers: Designers and developers should be aware that some agent processes may not support filtering and scoping of CMIS/P. Further research may be necessary to investigate how APs (Application Processes) cope with these situations. Recommendation for further study by TMN research community: Research should be done in the combined use of synchronous and asynchronous operations in a TMN, and guidelines should be produced on when and where these two modes of operation access should be used in a TMN. Recommendation to TMN designers and for further study by TMN research community: Research should be done in the co-existence of centralised and distributed approaches in a TMN and inter-working between these two approaches. Guidelines should be produced as to when and where these approaches are suitable. Recommendation for standard bodies: In the context of a combined distributed approach and centralised approach to TMN, ITU-T SG 4 should investigate what should be standardised by TMN and what should emerge as good practice for the development community. 5 EURESCOM as well as other organisations. © 1999 EURESCOM Participants in Project P812-GI page 21 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report 2.4.4 CORBA for Agent Process development 2.4.4.1 Introduction CORBA is seen as a key enabling technology in the arena of telecommunications management systems and we were motivated to evaluate its potential in a practical way and share our findings with the EURESCOM community. Literature on this subject to date has taken a very optimistic viewpoint of CORBA’s expected success in this regard. We hoped to take a neutral stance on CORBA’s applicability to telecom management, thus providing a more balanced view of the situation. The objective of this study was to assess selected OMG results’ applicability to Telecom Management. Superficially, CORBA is a great idea in a Telecom Management context but what could be the pitfalls? The OMG results focused on here are the CORBA Services. 2.4.4.2 The Rationale - Advantages of CORBA Telecommunications presents three key requirements on management systems: support for the constant delivery of newly created products, coping with technological changes by reducing the need for re-design of software and the ability to manage from a chosen location resources that are geographically distributed. The provision of solutions in such circumstances is what CORBA is reputed to be really good at because CORBA makes it easier to migrate from older systems to newer systems without having to discard existing solutions. Existing legacy systems that need to become part of an integrated solution can still be used wrapped in an IDL interface. This may be a non-trivial challenge but the prospects of using CORBA to do this are regarded as being more favourable than other alternatives (e.g., use of Remote Procedure Calls alone). Management systems will need to be frequently upgraded. CORBA provides a vehicle for creating an extensible distributed application framework. The main reason for this is that CORBA has adopted object-oriented principles and as a result supports the advantages of such an approach6. One can reuse GDMO specifications such as ITU-T Recommendation [M.3100] to aid system design to create CORBA objects that represent network resources that need to be managed by CORBA clients CORBA is programming language and operating system independent, hence it provides an effective framework to accommodate standardised interfaces, thereby being a strong candidate for implementing the principles of TMN. For maximum benefit, CORBA-IDL (a very widely accepted specification) will increasingly be used to specify interfaces to managed resources. Last, but not least, much of the information technology industry is supporting OMG results, such as CORBA, which brings a number of benefits: prices in keeping with a mass market, popularity among developers, availability of expertise, etc. 2.4.4.3 Challenges and Recommendations This section documents the challenges that CORBA developers may encounter when designing a system and, where possible, a means of facing them is suggested. Some of these means are formulated into recommendations. It is outside the scope to give a 6 It is not within the scope of this document to address the merits of OO technology page 22 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report complete framework for designing CORBA architectures for telecom management, moreover, we assume that the reader can solve basic design problems and thus we concentrate our commentary on discussing more contentious issues. Challenges and recommendations have been made under the following headings: Naming Modelling Classes Communication Efficiency Object Creation/Deletion CORBA Services Presenting the recommendations here would not be appropriate because the text needed to make sense of them would also have to be provided. This text would be unbalanced compared to the rest of the document. The details can be found in D1 Annex D. 2.4.5 Impact of Changing Technology as represented by Active Networks 2.4.5.1 Introduction Here we provide an overview of the case study investigating the potential impact of networking technology changes on TMN and examining where TMN should be future-proofed to enable it to encompass such changes more easily. Active networking technologies7 were selected as being indicative of future networking developments that may challenge the suitability of TMN for emerging networks. The goals of the case study also included consideration of emerging software technologies, such as design patterns, as a solution for supporting a variety of telecommunications network management paradigms. The results of the case study include recommendations about where the TMN standards could be evolved if active networking technologies are to be adequately managed by these standards. 2.4.5.2 The Rationale Changes in the market and in network usage, together with forecasts of even greater and more diverse usage to come, are suggesting that current telecommunications network architectures and management will be confronted with many new demands being made upon them. An increasing number of services, all with differing QoS requirements, as well as changes in user behaviour imply a much greater complexity to be managed. They also imply an increasing dependence on telecommunications management systems to provide the support that providers need. Research into active networking technologies has proceeded in an attempt to improve the flexibility of networks by supporting more dynamic types of networking. Combined with modern distributed systems tools, the aim is to provide a greater degree of flexibility, re-configurability, programmability and management to aid 7 Active networking technologies are defined in the case study as networking technologies composed of active, or programmable, network nodes that allow users or applications (in addition to the provider's internal management) to access the nodes’ resources and customise communication services dynamically, so allowing flexible runtime extensions to the network service environment. © 1999 EURESCOM Participants in Project P812-GI page 23 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution dynamic and rapid service creation to meet the demands of a competitive open service market. Active networks represent a new paradigm for creating, integrating and managing services that makes use of techniques not available when conventional networks and their management were designed, which is why they were selected for this case study. 2.4.5.3 Active Networking Technology Implications for TMN An investigation was undertaken to determine where the TMN standards do not easily apply to managing active networking technologies. First various aspects of the TMN standards, such as the architecture, the manager/agent paradigm and the management information model, were investigated in order to establish the extent to which the TMN approach is valid for managing emerging and future networking technologies such as active networks. This included ascertaining where problems might arise if the TMN model is not changed to take account of such technologies. It was concluded that the challenges to TMN posed by the use of active networking technologies are particularly relevant to the manager/agent model of communication represented by CMIS/CMIP and to the static approach to defining management information models. The following recommendations were made after this general examination of the TMN standards: Distributed OSs should be investigated and incorporated into the standards and no longer just considered “for further study”. It should be possible to distribute the TMN OS functions and data to a greater extent than is currently allowed for. Examine the logical layered architecture from the perspective of future networking technologies and investigate alternative approaches that take into account the possibilities of technological and software advances and that would provide a framework for more flexible and efficient management functionality. Investigate the manager/agent interaction of CMIP in the light of the active network technology paradigm and propose alternatives based on different interaction models and co-operative management solutions. The idea of centralising intelligence in a manager that initiates all request/response interactions with agents is no longer always appropriate and to maintain such centralised control could hamper the future effectiveness of conventional management systems. In connection with this, the possibility of a balanced CMIP enabling both manager and agent roles to be adopted during a single association should be examined. This would remove the restrictions currently being experienced in limiting a management process to adopting only one of the two roles in an association. Investigate how dynamic specifications can be incorporated into management information modelling and how shared management knowledge can take account of dynamic updates. Review the definition of a network and network element in the light of the greater significance of software at the network and network element layers. Finish considering the “other concepts supportive of distributed applications” referred to in M.3010 and investigate alternatives to CMIP, make proposals based on the API approach and the use of modern distributed object-oriented technologies. As the emphasis continues to be less on protocols and more on page 24 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report APIs and other distributed software engineering techniques, TMN should be updated to reflect these trends. The current restructuring of M.3010 by ITU-T SG 4 is the first step towards acknowledging the existence of such techniques. Investigate new approaches to protocol adoption, such as the deployment of new protocols by mutual agreement among interested parties, rather than standardising all protocols in a centralised manner. This could allow systems to remain TMNcompliant while selecting from those protocols that most suit the particular environment of what is to be managed. Investigate extensions to TMN to enable virtual networks to be managed within a TMN management system. Logical networks may be the most suitable way of meeting user and provider requirements in the future. More concurrency is required in TMN to enable this to be undertaken. Extensions to the management information model may also be required. Specific aspects of TMN information modelling were then examined in more detail. Since TMN information modelling is relevant to the managed side of a TMN system, only the static nature of a managed system, particularly the MIB, is discussed and compared with active networking technology requirements where real-time changes in the network result in the need to dynamically update the information model. The recommendations resulting from this examination are as follows: The dynamic nature of active networks raises two questions about information modelling used by the TMN information architecture: How will the naming scheme change as new types of resources are dynamically created? How will the consistency and completeness be maintained as new services are dynamically created at a resource? Therefore, research is needed to dynamically construct the name of new types of resources, keep the status of the MIB and the managed network consistent with each other, and to maintain completeness (to check whether the services offered by a particular resource are really available). A network architecture built on active network technologies will be able to change its composition and configuration according to user demand. On-line information on topographical interconnection and configuration of network elements should be able to reflect the dynamically changing network status. The suitability of active networking technologies for supporting TMN management was also explored. In particular we explored the greater participation of active nodes in network management, support for the TMN network element management layer, and in the use of technologies such as protocol boosters to ease the adoption of new protocols within a TMN. The ability to distribute processing and decision-making throughout the network can provide a flexibility and adaptability to network management that could prove useful when managing extremely large telecommunications networks of the future. The potential for deploying such active networking technologies may be constrained by the use of CMIP and the manager/agent paradigm of TMN and thus points to the need for protocols other than those based on this paradigm. A final section examines the implications of expanding TMN to encompass a wider range of paradigms that can all coexist under the TMN umbrella. The use of design patterns and pattern systems is briefly investigated as a means of overcoming some of © 1999 EURESCOM Participants in Project P812-GI page 25 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report the problems now being experienced in the TMN area. The following recommendations were made as a result of this brief investigation: Investigate the appropriateness of design patterns as a means of documenting standard approaches to solving telecommunications management problems Examine the use of pattern systems for specific management paradigms and propose a set of pattern systems for the most commonly occurring paradigms in the telecommunications management area. We can conclude that the consideration of how to manage future networking technologies, such as active networks, can act as a contributing trigger in the trend towards adopting open distributed environments for telecommunications management. 2.4.6 Using Web technology for service management 2.4.6.1 Introduction Here we provide an overview of a study which investigated the use of Web technology as a means of providing access to service management information and compared it to a traditional TMN solution. For this purpose, a case study was built around a real service case, using some of the specification of an internal PT (Portugal Telecom) Project– CIMSIF - Circuit Management System Interface. It aims to allow customers and customers’ managers in PT to access management information of the leased circuit networks provided by PT. Web technology is part of the CIMSIF implementation and some conclusions have been drawn from its use in contrast to other approaches. We consider specifically Web-Based Enterprise Management (WBEM)8, which is an initiative based on a set of management and Internet standard technologies developed to unify the management of enterprise computing environments. Within this context, the main objectives of the work reported here are the following: 2.4.6.2 To analyse some of the advantages and disadvantages of using a Web-based technology, namely to provide customer and operator access to service management information To analyse different implementation solutions for the CIMSIF application, namely, a) DMTF, b) a pure TMN solution based on M.3000-series recommendations, and c) a solution using the Web merely as a way of implementing user and operator access to management information. The Rationale Many challenges have been posed to TMN since its creation resulting in several detailed studies to investigate the best way to cope with them. Web technology has increasingly been gaining acceptance as an interesting option to give access to management information, because it is cost-effective and widespread. Another benefit of Web-based technology is its feasibility to be integrated in several management systems. 8 Now part of DMTF (Desktop Management Task Force) page 26 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report Several driving forces have been identified which push generic IT as a platform for TMN. Not surprisingly most of them were identified in other results within this Project. Notably recall the need to allow end-users in the customer domains access to management information to improve quality of service. Web technology has attributes that make it one of the most interesting options for use within the telecommunications management domain and a number of companies have committed resources to arriving at a scheme (WBEM) to exploit and enhance the Web in a systems management context. 2.4.6.3 Results and recommendations The main body of the case study presents three implementation approaches: pure TMN and two Web-based approaches. The Web-based solutions concern two paradigms: using the Web as a way to implement access to management information, and using DMTF solutions. In the DMTF section, its main features are introduced and the applicability of DMTF technology to TMN is analysed. Emphasis was particularly placed on the mapping between DMTF and CMIP services. Moreover, to integrate TMN with DMTF, many questions still need to be answered, and most of these questions were also analysed. Pure TMN approach and Simple Web access For this implementation exercise, “pure TMN approach” is understood to mean the use of TMN standards as defined in the core TMN document, namely M.3010 [M.3010] as published in 1996. This approach is used here to illustrate how fruitful, or limited, the TMN perspective has become, when applied today to the growing demands of management information access and manipulation by customers, as is the case in the CIMSIF problem domain. In the pure TMN world, the automated (direct on-line) access to management applications, sharing management information between two different administrative domains (TMNs), is via an X interface based on the CMIP protocol. The implementation solution using the Web to enable user and operator access to service management information appears to be much more attractive, when compared with the pure TMN approach. It was used in practice in CIMSIF and proved to be much simpler and cheaper to develop and implement. The customer only needs a simple PC with a browser to access all the intended functionality. The key to scalability challenges resides in the Web module, which allows every user access to the application features. In cases where a direct connection between management systems in the Provider and Customer domains is envisaged, a hybrid solution might be required, integrating the SP’s service management with the customer management system based, for example, on SNMP. In this case, an architecture with an SNMP agent would be needed or, alternatively, the integration might be done using the DMTF architecture. In the CIMSIF problem domain, the key objective is to provide the customer with access to relevant management information in the SP domain. This may mean several approaches depending on the customer requirements and objectives for the service. As an example, a simple user interface to access network status information directly from a provider operation system may be an adequate solution for specific customers. Another possibility, required by more demanding customers, is to directly interface a customer management system with a CIMSIF provider’s operations system and to allow for management applications on each side to interact. © 1999 EURESCOM Participants in Project P812-GI page 27 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution There are no theoretical reasons why Web-based approaches should not be used as a solution for building operator and customer access to TMN-based systems satisfying the core requirements of scalability, reliability and appropriate cost It is judged that conventional TMN models are not easily applicable in the CIMSIF customer–provider relationship and, as such, TMN needs to accommodate both types of customer interactions in the Service Management level. This is an area in which the TMN recommendations need to provide the right level of openness to accommodate IT technologies and to provide an efficient and standard interface solution. The recommendations derived from the study of the pure TMN approach are the following: In the fast moving arena of telecommunications business, more and more efforts are being made world-wide on how to achieve electronic interfaces between service providers that link their operational processes via the exchange of management information (electronic commerce is a powerful example here). These efforts and industry agreements should be recognised and incorporated into the TMN body of standards, models and protocols because such implementations activities will improve the viability of TMN-based approaches for management interactions in a multi-provider situations. A recommendation emerging from the CIMSIF pure TMN approach is to make sure that the next set of TMN recommendations, especially a new version of M.3010, do not inhibit the use of new technologies and concepts (like Web-based technology), namely for customer access to management information. It is then recommended that the TMN standard architecture introduce a clear split of perspectives at the external access to management information: 1. The existence of the current X interface based on CMIS/CMIP transactions between management systems; 2. The existence of a new multi-protocol interface between end-user systems (maybe using just a browser as client software) and service provider’s management systems; 3. The existence of a new multi-protocol interface between management systems in different service providers’ domains, specially targeted at distributed applications interactions related to Service Management activities; To consider the introduction of new management information models and their relationship with current TMN MIBs (for example, the mappings between the models), so that such models are capable of supporting the multi-protocol management interfaces mentioned above. Special attention should be devoted to Web-based approaches and technologies for the access and manipulation of management information. DMTF solutions The DMTF was established to harmonise standards related to the management of resources used for desktop computing and is supported by many significant IT players (Microsoft, Intel, etc.). Web-based enterprise management (WBEM) is an ongoing industry initiative (under DMTF since June 1998) to integrate current enterprise management technology with the latest advances in web technology and interoperability, providing organisations with an easy-to-use, cost-effective, updated and automated method for managing enterprise systems. page 28 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report TMN could take advantage of DMTF solutions. The standards will support a broad range of management solutions and will build on Internet innovations to meet the demanding requirements of the most complex heterogeneous computing environments. Another issue is the increased choice in applications and greater functionality enabled by a standardised approach. The proposed DMTF standards offer a single foundation on which to build management applications, eliminating the need to design different versions for different management platforms and making applications more efficient and cost-effective. They provide a common data model and access protocol for management information that may be managed by a diverse set of underlying management systems. These underlying systems can implement standards such as SNMP, DMI (Desktop Management Interface), or TMN. In the medium term, it is predictable that the classic TMN systems will become more integrated systems with ‘Business Support Systems’ following the DMTF approach, hiding TMN to the user. We would recommend: TMN standards bodies should investigate the possible use of DMTF solutions and other technological solutions using Web technology, namely the Java Management API (JMAPI). Although it is difficult to predict the future development and impact of the DTMF initiative in the industry, at present it looks likely that TMN cannot afford to ignore the opportunity of using Web technology to solve some of the intrinsic problems of delivering effective implementations of telecommunications management solutions. 2.4.7 Evaluation of the MSM methodology and architecture 2.4.7.1 Introduction and Rationale This section briefly summarises an investigation into the use of an object-oriented application development methodology and architecture recommended by EURESCOM9 for service management applications. It is called the MSM (Multimedia Service Management) architecture/methodology in the following text. Many challenges have been posed to TMN since its creation resulting in several detailed studies to investigate the best way to cope with them. One investigation has been the search for the right methodology and architecture to enable TMN developers to rapidly and effectively create and reuse TMN applications. Therefore, we have considered this aspect of the future of TMN to be important and engaged in a case study to check whether or not the MSM methodology and architecture could be judged to be flexible enough to be used in TMN Projects. The Portugal Telecom (PT) project CIMSIF has been the basis of this case study also (see 2.4.6.1). This document presents some of the results of our experiences: In using MSM architecture and methodology for a leased circuit management service (a non-multimedia service); Investigating if SPs can profit from reusing MSM methodology and architecture when implementing future service management applications; 9 Which originated in EURESCOM Project 610, Management of Multimedia Services. © 1999 EURESCOM Participants in Project P812-GI page 29 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report 2.4.7.2 Briefly considering how well MSM architecture and methodology can adapt to an open environment where we could have several off-the-shelf products to implement a management application with an interface between the service provider’s telecommunications management system and an external system. The case study The case study starts by describing the driving forces that prompted this work. In this section, the need to have good methodologies and architectures is addressed via an analysis of the current SP’s needs. After that, the methodology10 used in the case study is introduced followed by the service description. Next the methodological steps are followed one by one up to the mapping to the architecture11. The results of this experience are presented as conclusions and recommendations. The next sections briefly summarise the study undertaken, as well as the derived conclusions and recommendations. There is some consensus that service management has different requirements, when compared with network and network element management, and might require different methodologies and architectures. Service management has been researched in many projects in the past five years. One of the Projects, which produced some results in this area, is EURESCOM Project P610. P610 D4 states: “The process utilised in this Project guarantees that the results are valid not only for one multimedia service, but for a broad range of multimedia services. Moreover, the results will help to provide integrated solutions for several multimedia services, i.e., composition of services”. We decided that the EURESCOM Project P610 output is a resource that could be leveraged for TMN evolution if suitable. This begged the question: Are the results valid in a TMN context? 2.4.7.3 Conclusions and recommendations Architecture The MSM architecture has proven very flexible: although very simple, the service that was modelled has nothing to do with the original multimedia flavour of the architecture. Yet, the architecture was applied only by cutting and leaving out the parts of it that did not have any relevance for the modelled service; its use was very straightforward and resulted in a good comprehension of the problem and in a good organisation of the classes and objects. 10 The methodology is structured in three steps. The first step is requirements capture. This first step in the P610 methodology comprises three sub-steps: service description, business modelling and use case analysis. The other two steps identified in the P610 Methodology are object-oriented analysis, and architecture mapping. The second step is performed along two threads: domain analysis and application analysis. In the third and last step, architecture mapping is performed, distributing classes following the previously defined architecture and identifying those pieces of the system that could reuse one or more existing systems. 11 The architecture has some similarities to the architectural work of TINA-C (Telecommunications Information Networking Architecture Consortium). Objects are allocated to UML packages reflecting a modularity partly designed according to TMN functional areas. The novelty appears in the creation of groups of packages to host objects modelling Service and Network Abstractions as well as Actor profiles. page 30 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report The generic aspect of the architecture might lead to a more complex application design than the one that was specifically developed for the application. We noticed this when we compared both solutions, a generic one and one tailored for CIMSIF. Therefore, it is recommended that very specific guidelines for architecture design should be defined, ideally addressing quality metric guidelines as well. Methodology Like many object-oriented approaches, the MSM methodology calls for a lot of iteration on the developer’s part. This iteration is particularly challenging for those who are not used to this dynamic aspect of systems design. This iterative nature requires the use of a UML modelling tool with strong configuration management capabilities to avoid labour intensive redrawing of figures as more details are added to them. During this case study, we have noted some difficulties for people who have not been exposed to the methodology in the execution of tasks such as Domain Modelling, Application Modelling, Design Patterns usage, etc. This suggests that a more detailed task definition and/or examples and guidelines should be available as methodology companions, to make usage easier. The package concept has raised some doubts among users and readers of the architecture. Work is needed to tell developers how to use the package concept correctly. How to group classes into packages is not thoroughly defined. This step also needs further guidelines to clarify its use. More work applying the P610 results is needed before a firm recommendation can be made on their potential as part of TMN evolution. It should be noted that the main benefit of this study is that it provides an example of the use of the MSM architecture and methodology for those who intend to apply them. Summary Six case studies were performed which addressed key aspects of TMN evolution and have provided material which can be used by telecommunications management professionals, whether they be involved in purchasing, development or standardisation. It will be a good result if some of our recommendations find their way into standards bodies and other industry groupings and stimulate a renewed effort to complete TMN specifications. A useful side effect of these studies is tutorial material on SNMPv3, Software Agents, DMTF/WBEM, CORBA Services, Active Networks and OO methodologies. These tutorials can be useful for a wide audience in EURESCOM shareholder organisations. 2.5 Service Providers’ Needs This section summarises D1 Annex E. The proposal for this Project took the view that TMN evolution should mirror the needs of telecommunications service providers as they look forward to the next millennium and we have taken up this challenge. As almost every reader knows, the business environment of incumbent service providers has changed far more dramatically than TMN has in the past 6 years or so, most of the changes being attributable to competition and new technologies creating new opportunities. They live in a highly diversified market place which has major implications for the way they manage their affairs. © 1999 EURESCOM Participants in Project P812-GI page 31 (39) Deliverable 1 – TMN Evolution Volume 1: Main Report It was beyond the capabilities of a Project such as this to be able to produce a model which unequivocally predicts the shape of TMN in the future, particularly the future shape as a direct response to the needs of the service providers that will use it or find it wanting and select an alternative. Nevertheless, it was seen as a worthy goal in its own right to come up with a definition of service providers’ needs which may impact on telecommunications management and the systems supporting it. The needs are described in some detail which can be seen in D1 Annex E. It has to be borne in mind that these needs are not the needs of any particular company but may apply to many companies. They are not detailed enough to be used without considerable specialisation to a given situation. The merit of this set of needs is in the breadth of their coverage. In this part of our work we echo what has been summarised succinctly by the TMF when it reports that the main business drivers for European Public Network Operators are: cost reduction in the provision of services improved process flow across provider organisation management systems greater management process automation greater customer management control improved quality of service management greater range of management services. The structure used to present the needs is inspired by a vision of the goals that a service provider is likely to set for itself in order to provide a satisfactory return on investment. The goals are expected to fit into the areas presented as follows: Revenue Increase: Increase usage of existing services New Services Billing and Payments Cost Containment: Operational staff Service Delivery Infrastructure Purchases of Services Telecommunications Management Systems Ownership In the main, we have tried to describe only needs that have a bearing on the purchase and usage of telecommunications management systems. We do not address business questions such as money borrowing, property management, and civil works. Our position is that the way that a service provider approaches telecommunications management systems can have a significant influence on the revenue generating aspects and cost control aspects of the business. We also propose that there are a substantial number of forces working in parallel to influence decisions about telecommunications management systems. Such decisions are therefore very complex and we are not in a position to say how optimal decisions can be made in these circumstances. page 32 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report In the presentation of the needs, we have stated needs at two levels: first order needs and second order needs. This sub-division is not very precise and has not been tested to any extent. The purpose of the split is to arrive at (first order) needs which express top business level concerns (e.g., get increased usage of existing services) and another set of (second order) needs that are the concerns of systems architects (e.g., collect and analyse service usage data). The latter needs are intended to be those that will be a starting point for requirements analysis in the context of telecommunications management systems. The value we have tried to add is to establish links between business cases and technical requirements. It would be pointless to summarise the needs here. You are invited to examine the details in D1 Annex E. 2.6 Contribution on TMN Architecture Evolution We had been following the progress of the work aimed at splitting the ITU-T recommendation M.3010 into two parts (initially called M.301x and M.301y). The former is intended to be the fundamental principles for a TMN while the latter included some guidelines on the handling of different TMN cases, such as management of IN, and the application of certain implementation approaches. Based on the work we had done on TMN issues, we made a submission to ITU-T SG 4 meeting in Tokyo in October 1998. This input proposed a complete re-write of M.301x. Many previous versions of M.301x had existed at the time and it had become very difficult to read and difficult to see what new contributions were replacing old contributions. The objective we set ourselves was to only retain text in the document that had a clear architectural message as the version we were commenting on was very unbalanced in terms of the volume of words in the introductory sections compared to the parts that were attempting to be prescriptive. We did not shy away from being radical in that we proposed: Only two architectures were needed rather than three. With the elimination of the OSI management material from the document, the role of the information architecture seemed dubious and we recommended that it is dropped as a separate architecture and the text associated with it be pruned and added to the section on interfaces in the physical architecture section. From a standardisation perspective, there would be no difference between the Network Element Function and the Q-Adapter Function and that they be merged into one. To eliminate some of the so-called functional components (such as the Message Communications Function) and retain only components that were fulfilling a specific telecommunications management role. That the WSF be left behind when the revised architectural recommendations are issued because the separate identity of the Work Station Function (WSF) and the associated f – reference point were deemed to no longer have a validity in light of practices when building management systems. That all references to the Business Management Layer as a subject for standardisation within TMN are dropped and that the Logically Layered Architecture be considered to be just one of many possible partitioning principles. Our submission was instrumental in provoking considerable discussion within the meeting but it was considered to be too revolutionary to be taken on board to any © 1999 EURESCOM Participants in Project P812-GI page 33 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution serious extent. Informally, we have been informed that many participants to such meetings find it very difficult to remove concepts that they have lived with for a long time even though they (the concepts) have vastly diminished relevance to the current situation. Arising from this situation, we forecast12 that the revised version of M.3010 will not be as clear and concise an architectural statement as should be the case due to the possibilities that exist in such study groups to fudge issues in the interests of compromise. Such a situation can only weaken the respect that the users of TMN standards have for such documents. 2.7 Web-based Presentation The information resulting from EURESCOM Project P812 has been presented in HTML format to allow dissemination through a Web site. The URL for this site is www.eurescom.de/public/Deliverables/wwwdeli.htm. Go there and look for the TMN Evolution link. The layout of this site is fairly simple and intuitive with the home page listing all available information, divided into two sections; main Project results and extra information. Main Project Results This section first presents the main Deliverable from the Project under the heading ‘TMN Evolution’. Below this are three sections describing the current status of TMN from architecture, technology and issues perspectives. In the first section, D1 Annex A is presented which gives both a brief and an in-depth evaluation of TMN status from an architecture perspective. The second section represents D1 Annex B which evaluates TMN status from a technology perspective, and the final section is D1 Annex C which reports on TMN issues. There follows a link to ‘Service Provider Needs’ which is D1 E, Telecommunications Service Providers’ Needs for Telecommunications Management. Finally, in the main Project results there is a link to ‘Case Studies’, D1 Annex D, where various documents are stored, relating to evaluations completed during the Project, of CORBA, implications of SNMPv3, NE-OS interfaces and Web technology, and so on. Extra Information The Web site also contains a link to ‘Other Interesting Material’ which includes information such as an evaluation of OSS deployment, and some external information on OSS experiences, taken from Dittberner [Dittberner]. A conference paper, ‘A Practical Perspective on TMN Evolution’ is also made available here, as is a link to information from a report conducted by Probe Research, Inc. and entitled ‘TMN - The Pivotal Technology’ [PROBE]. A generic acronyms page is also provided in this section of the home page. This acronyms page is a definitive listing of all acronyms appearing in all papers held on this site and should therefore represent a comprehensive listing of all the acronyms relevant to this topic. 12 Writing in February 1999. page 34 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution 3 Volume 1: Main Report Conclusions Telecommunications Management is a more complex subject than it was when the first TMN standards were issued in 1988. The vision ascribed by some industry players for TMN was a single virtual management system and network to cater for all the management needs of a telecommunications service provider. This vision coincided with a vision for the public network formed around Broadband ISDN as the virtual single network that would carry all telecommunications traffic. Both of those visions have turned out to be flawed. They both placed a large reliance on the power of ITU-T standardisation. In retrospect it was too high an expectation to place on such a body that it would guide the evolution of telecommunications into the next millennium via standardisation. The rate of technological change has disrupted this assumption, as has the extensive commercialisation of the telecommunications service supply industry through competition in its market. It is possible to be critical of TMN. Parts of the output of this Project point out deficiencies and a lack of progress in some areas. We have written about the status of TMN, raised issues about TMN, made recommendations and stated the needs of service providers for telecommunications management. In doing so, indications have been given about how the TMN situation could be improved but there are so many of them that it is hard ‘to see the forest for the trees’. So what are the conclusions to be highlighted here? 1. Service providers are not likely to delay system acquisition decisions until standards are agreed which will result in a mixture of standards based and proprietary solutions in the domain intended to be served by TMN. Such a situation requires operators and vendors to be skilled in the architecting of ‘mixed’ systems. 2. Service providers will favour telecommunications management solutions that offer prospects of revenue increase as well as cost containment. This will require the specifiers of TMN systems to take a broader than traditional perspective on the requirements they take into account. 3. The interconnection of separate management domains for purposes of enabling co-operation and competition between service providers has emerged as the main challenge for international and regional standardisation. ITU-T SG4 activities could more clearly reflect this priority and should recognise that IP-based technologies are likely to be a convenient means of meeting this challenge. 4. TMN is likely to continue to be dominant when it comes to standardised management of transport (WDM, SDH and Public ATM networks) at the element management level. SNMP is likely to continue to be dominant for the management of IP networks and devices. Therefore we can expect several dominant styles of telecommunications management to co-exist in service providers domains which roughly equate to TMN – CMIS/P, SNMP and DMTF. Strong liaisons between ITU-T, IETF and DMTF will be required to minimise the friction caused by the interdependencies among these styles that occur. 5. Management information modelling is an area that should have top priority. It needs to be done in a manner that does not bias the solutions towards a particular protocol for the transport of management messages. While ITU-T has recognised this need, it has been slow to arrive at a viable solution in the area of ‘neutral’ information modelling – a situation it is urged to address. © 1999 EURESCOM Participants in Project P812-GI page 35 (39) Volume 1: Main Report Deliverable 1 – TMN Evolution 6. Web, Java, CORBA and Microsoft technologies will be found in combination in many telecommunications management systems. Individual vendors can be expected to cope with (encapsulate) this complexity without much involvement from service providers (who are their customers) when such technologies are mixed in the systems (products) that they offer. Vendors and service providers need to work together to find an effective means of integrating ‘products’ into a coherent management systems environment. 7. Generic IT solutions will be adopted in telecommunications whenever possible to increase the likelihood of mass-market prices for technologies. Therefore, service providers will need to ensure that their staff is adequately knowledgeable on such solutions. 8. Proposed changes to the TMN architecture (ITU-T Rec. M.3010) remove references to ISO-OSI Management as the management paradigm. While this is good and necessary, what remains is currently insufficiently precise to be of any real benefit. Text on TMN architecture needs to be clear about its intention – description or prescription? 9. Emerging approaches to network architecture are likely to have a large impact on the traditional meaning of telecommunications management as distinct from network control (signalling). This is likely to mean that dealing with management issues (particular real-time management) and signalling issues as loosely connected subjects will be present significant risks of redundancy and conflict between the two areas. In other words, management and control of networks needs to be addressed in a more integrated way by standards bodies and operators 10. Various national and international Telecom Watchdogs and Competition authorities are putting pressures on network management users/systems/standards etc. by insisting on functionality such as open and fair access gateways to allow competitors to have “equal” access to certain information and processes that the original owner of the information enjoys. Vendors need to address this area in their product plans; operators, particularly in Europe, need to consider its impact on present and planned systems and standards bodies need to either address this area with some urgency or to accept a role of codifying whatever emerges as the industry’s solution. 11. The ITU remains slow in revising TMN as evidenced by the 4 years taken to split Recommendation M.3010. Although it seems capable of adding new ideas into the TMN architecture it does not seem able to remove old ideas leading to confusing standards. It is clear that those involved in standards production recognise that parts of their output are of dubious value and quality but this is not recorded where a naïve reader can access it. 12. Customer access to network management is unlikely to favour the X-interface approach (according to the 1996 version of the TMN architecture) except in exceptional cases. When Customer access is performed according to the TMN Xinterface it will use the same guidelines/practices/standards as provider-provider OSS interfaces. Clarity is needed on who will do what in this area when it comes to standards. page 36 (39) © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report 4 Annexes 4.1 D1 Annex A Evaluation of TMN Current Status - Architectural Perspective This annex provides additional details on the current status from an architectural perspective. It does not provide real depth on the subject, more information can be found at www.eurescom.de/public/Deliverables/wwwdeli.htm. 4.2 D1 Annex B Evaluation of TMN Current Status - Technological Perspective This annex provides additional details on the current status from a technological perspective. It does not provide real depth on the subject, more information can be found at www.eurescom.de/public/Deliverables/wwwdeli.htm. 4.3 D1 Annex C TMN Issues This annex presents the TMN Issues proposed by the Project. The same information can be found at www.eurescom.de/public/Deliverables/wwwdeli.htm. 4.4 D1 Annex D TMN Evolution Case Studies This annex expands on the information from the TMN Evolution case studies presented above in section 2.4. The same information and additional case study material can be found at www.eurescom.de/public/Deliverables/wwwdeli.htm. 4.5 D1 Annex E Telecommunications Service Providers’ Needs for Telecommunications Management This annex lists and discusses the needs of telecommunications service providers in the context of telecommunications management as they face the turn of the century. The same information can be found at www.eurescom.de/public/Deliverables/wwwdeli.htm. © 1999 EURESCOM Participants in Project P812-GI page 37 (39) Volume 1: Main Report page 38 (39) Deliverable 1 – TMN Evolution © 1999 EURESCOM Participants in Project P812-GI Deliverable 1- TMN Evolution Volume 1: Main Report References [Dittberner] Dittberner Associates, PROJECT ESS Update 36, "Operational Support Systems- An Operator's Perspective". Bethesda, MD 208143488 USA, 1998 [P610D4] EURESCOM P610 Project: Management of Multimedia Services, “Management Framework and Methodology (final version)”, Deliverable 4, 1998 [PROBE] Probe Research, “TMN: The Pivotal Technology for the MultiNetwork Future” 1997, www.proberesearch.com [Tennen97] D.L. Tennenhouse, “A Survey of Active Network Research”, IEEE Communications Magazine, 35 (1), January 1997, pp. 80-86. Note: For a guide to TMN recommendations (M.3000, etc) go to www.itu.int/publications/itut_bookstore.html for a complete listing – go to M series or Q series links. You can also look at www.itu.int/TMN for more information but it is not fully up to date. © 1999 EURESCOM Participants in Project P812-GI page 39 (39)
