S-38.118 Network Management

1. S-38.118 Network Management • Why do we need network management? OSI-management defines the subareas of management: (The famous five, FCAPS) • Fault management • Configuration management • Accounting management • Performance management • Security management • While there are other more operator oriented classifications, the FCAPS show, that there are areas to be managed. • It is necessary to manage these aspects for services, networks and network elements. If these areas are not managed, commercial offering of network services is very difficult - who would buy them. • Usually there are network management centers which manage the services, networks and network elements 24 hours a day. Management as a service, like managing configuration of a company Firewall as a service by an operator, may be only for a limited time of a day.

2. Network Management summary • TMN (Telecommunication Management Network) is ITU-T’s network management concept (M.3010). TMN talks of two management interface protocols Q3 and Qx. • OSI-management is CMISE (Common Management Information Service Element), CMIP (Common Management Information Protocol). It is defined as joint ISO, ITU-T standard. • Often TMN is meant to be the synonym of OSI-management as CMISE was selected as Q3. Then Qx meant CMISE with shortened stack, i.e., not on the OSI-stack X.25, Transport, Session, Presentation. • Currently TMN does not see OSI-management as an essential part of TMN and Q3 may be some other protocol. One possibility is TMN where CMISE is on top of CORBA. This is included in the Open Distributed Management Architecture ODMA. • Another possibility is to put network management applications on top of the XOM/XMP interface which can use CMIP or SNMP. • TMN MIBs (Management Information Bases) are defined using GDMO (Guidelines for Definition of Managed Objects).

3. Network Management summary • GDMO definitions contain ASN.1 data types. GDMO is a template language. Templates are ASN.1 macros, i.e., they extend ASN.1 by defining new reserved words. GDMO has the following templates: Managed object contains Packages. Packages contain Attributes, Attribute Groups, Actions, Notifications. Actions, Notifications and Attributes may contain Parameters. Behavior is described in free form text by Behaviour templates. There are compilers for producing code from GDMO and ASN.1 definitions. However, you have to code by hand Behaviour and connection to the Real Resources. • CORBA version of TMN has CMISE MIBs defined in IDL. • CMOT is an unsuccessful RFC of IETF which puts CMISE on top of TCP/IP. • SNMP is a simplified version of CMISE for internets. It has MIBs defined by SMI (Structure of Management Information). These MIBs are ASN.1 macros, but much more simple and limited than GDMO templates. ASN.1 data types can be of limited types. There are MIB compilers for SNMP. SNMP does not support actions, not create/delete of Managed Objects (MO). SNMP Traps are not defined in MIBs.

4. Network Management summary • SNMP has versions SNMP v1, v2 and v3. SNMP v1 and v2 have security problems, fixed in SNMP v3. Distributed management concept in SNMP can be e.g. SNMP v3 manager managing SNMP v1 managers which manage network elements. • Web based Enterprise Management (WBEM) defines a protocol on HTTP with CIM (Common Information Model) defined PDUs (Protocol Data Unit) coded with XML (eXtendible Markup Language). WBEM management operations are not so compact as CMIP or SNMP operations. One can also manage class definitions with WBEM calls. • The CIM model has UML (Unified Modeling Language) defined class diagrams which can be converted to MOFs (Managed Object Formats). MOFs are then coded in XML. UML is more powerful than GDMO,it adds relations between the objects. Whether you need the relations in network management object definitions may be questioned. There are automatic tools for creation of MOFs and XML DTDs (Document Type Definitions). • Mobile agents have been applied to management as well. They may suit to some service management tasks. No special tools offered.

5. Network Management conclusions • There are basically three approaches to network management, plus mobile agent based experimental systems. • There are currently many different proprietary management systems. The purpose of agreeing on a management protocol is to unify the situation. The five areas of management are not covered by an interface protocol, there are the actual systems for performance, accounting, security. Agreeing on an interface is only to ease management of these systems and to enable interworking. • TMN tries to provide a unified interface to all network elements, networks and services to be managed. TMN builds traditionally on OSI-management but may be using CORBA in the future. TMN is a rather heavy system. It is not in fashion but it is not dead yet. • SNMP is a popular management interface, but it is a limited solution basically for monitoring configuration and faults in internets. SNMP will continue to be used, but it will not cover all systems to be managed. • WBEM is the most recent solution and there is a lot of interest to this method. It is not simple but all management tasks can be made with it. The model looks less clear than the traditional manager-agent paradigm.

6. TMN Telecommunication Management Network • Management of services is often a part of network management. • The former and still present situation is that there are very many different management systems which are centrally managed by a small group of people. It becomes complicated and the need for a standard solution for management was seen in late 80-ies. TMN standards M.3010 Principles of Telecommunications Management Network from ITU-T and CMISE/CMIP recommendations X.700-series from ISO (called the OSI-management) were seen as the solution in the beginning of the 90-ies.

7. TMN • Currently TMN is not the only, and certainly not the most fashionable, solution, but the setting should be remembered. Network management is a very large task and the situation is still that there are several partly automatic, partly manual management systems. Java-based management can only be a partial solution. To solve the big picture requires a big system. • TMN is being developed by ITU-T,ETSI, NMF (Network Management Forum). • JIDM (Joint Inter Domain Management), joint activity of OMG and NTF puts TMN on CORBA setting. • There is new work going on in ISO: ODMA Open Distributed Management Architecture which applies ODP to TMN and basically puts CMISE on top of CORBA translating GDMO/ASN.1 MIBs to IDL. • We can still say that TMN may be the future solution.

8. TMN • TMN does not need to use CMISE in the future. The communication protocol is not an essential feature. That is, Q3 is not always CMIP, Qx is not always CMIP with a shortened stack. Still the investment on the MIBs is a relevant factor and one must admit, that GDMO is a good way to describe MIBs (there is work going on to describe MIBs using ODP concepts). • Basic concepts: • OSF Operations System Function • WSF Work Station Function • MDF Mediator Function • DCF Data Communication Function • NEF Network Element Function • QAF Q-Adaptor Function • Logical Layered Architecture (LLA) • Notice,this is a logical division to business,service, network, network element management. There may be interfaces (Q3) between the layers, or they may be simply logical constructs.

9. TMN • TMN defines reference points and interfaces to the reference points: • q3 -- Q3 (CMISE usually) • qx -- Qx (CMISE with a shortened OSI-stack usually) • x -- X (CMISE with security additions, FTAM, X.500) • f -- F interface to WSF • m -- propriatory management interface to a network element • g -- interface to WSF, user interface, outside TMN • Trials, Eurescom P408 PET-lab pan-European trials for SDH management using TMN. Xcoop-interface

10. SNMP • Year 1990, while CMISE/CMIP was being standardized IETF introduced RFCs specifying a simple CMISE-like management protocol for internets. • SNMP Simple Network Management Protocol • SMI Structure of Management Information • MIB Managed Information Base • SNMP v1 RFC 1157, RFC 1213, RFC 1155 • RFC 1155 Structure and identification of management information for TCP/IP-based internets, May 1990 • RFC 1157 Simple Network Management Protocol, May 1990 • RFC 1212 Concise MIB definitions, March 1991 • RFC 1213 Management Information Base for Network Management of TCP/IP-based internets: MIB-II, March 1991 • RFC 1643 Definitions of Managed Objects for the Ethernet-like Interface Types

11. SNMP • Official claim was that SNMP would be replaced by CMISE/CMIP “when the OSI-protocols work”, but naturally there was no such intention. • CMOT, that is, CMISE on top of TCP was proposed as one possibility, but it did not become popular. • One reason is a general dislike of OSI-protocols by IEFT. • I think, another reason is, that CMOT suffers from security problems, just like SNMPv1. Notice, that the security of CMISE is based on the following aspects: • X.25 network is in a way closed, you can buy a connection from an operator but the network does not contain unknown routers. • ACSE has authentication of users and CMIP uses ACSE for connection establishment for every operation. • There could be added optional digital signature to every operation like in X.500, but it is not necessary, X.25 makes the security. • Replacing X.25 by TCP/IP makes a difference: you need to crypt data. • Security was among the main problems of SNMPv1. CMOT would not fix it, so why move to CMOT?

12. SNMP • An often quoted reason is heaviness of CMISE/CMIP compared to SNMP. What about this statement? • CMISE runs fine, but it is complicated for the following reasons: • you need an X.25 connection, this cost money unless you are an operator owning the X.25 network, TMN is for such a usage, Internet is not a community of partners who own X.25 networks. • You need an X.25 card. The obvious question is, if you already have a LAN connection, why more connections? • There are two more protocol layers. In network management this causes no performance problem as management operations are done in a rather slow pace, max one operation in 5 min to any network element, and this would be for performance measurements, currently not supported by SNMP any way. But the OSI-solutions are somewhat more heavy for email and for file transfer, so an OSI-solution can be called heavy even when there is no real reason. • The memory requirements increase, but not importantly. • XOM/XMP interface is difficult to use.

13. SNMP • These reasons make it perfectly understandable why you do not what to use CMISE/CMIP for management of e.g. routers in an internet. • SNMP is based on the same manager agent solution as CMISE. The operations are simplified: • Get M-Get • Set M-Set • Trap M-Event-Notification • missing M-Create • missing M-Delete • missing M-Action • SNMP is on top of UDP. No connection establishment before the operations, like in CMIP.

14. SNMP • Get-operation consists of • GetRequest • GetNextRequest • GetResponse • there is no seach filter • Set-operation consists of • SetRequest • GetResponse • Variable bindings: it is possible to bind together into the same message a number of operations (get, set, trap) so that there is one request and one response. All PDUs contain a variable bindings field. It is a sequence of references to objects, together with the value of those objects.

15. SNMP • Proxy agent • Basically the same as TMN Q-Adaptor • If the network element does not talk SNMP, then use a proxy agent which talks SNMP to the manager and some nonstandard protocol to the network element. • Content of the management information. • Defined in SMI (RFC 1155). The managed objects consist of attributes and they have a name. • The name is given by an object identifier. There is no separate containment tree. The class hierarchy tree (the inheritance tree) is also the containment tree. This (and the lack of create,delete,action) means, that SNMP SMI is not at all object oriented. • The attributes can only be simple scalars of a small number of ASN.1 types, or two dimensional tables of scalars.

16. SNMP • There is no create or delete. You can try to implement something like this by using a table where the entries are managed objects (in SNMPv2 or SNMPv3), but it will most probably not work. • (Set is quite often not implemented in SNMPv1 or SNMPv2 agents because of the lack of security, so setting a table entry will not work.) • Scalar data types in SNMPv1 SMI are: • Application specific: Basic data types: • NetworkAddress INTEGER • IpAddress OCTET STRING • Counter NULL • Gauge OBJECT IDENTIFIR • TimeTicks SEQUENCE,SEQUENCE OF • Opaque CHOICE • (like: Counter is an INTEGER (32-bits) which wraps around.)

17. SNMP • Compare: in CMISE you can define any data types in the GDMO definitions. What do you gain from restricting the data types? • If you have an ASN.1 compiler, nothing, you can compile any definitions to encoding/decoding code and link the code to your software. • Actually you make it more difficult, there are ready GDMO compilers, with SNMP MIBs you end up coding manually (but it is simple and nice to code manually). • You cannot avoid coding manually the use of the real resource. (We have made this using scripts.) • You can arrange the basic data types into groups or into tables. A table cannot contain tables as entries.

18. SNMP • Problems with SNMPv1 • security • only by using the uncrypted password “community name”, the community name is plain text in the packet • there is no way to see the origin of an SNMP request. • compare to the use of ACSE in CMISE,ACSE supports credentials (uncrypted password, password crypted with a one-way function, strong credentials with a unsymmetric cryptosystem) • manager-manager communication • why do you need this? For a distributed management concept. • bulk data transfer • this is caused by the solution GetRequest, GetNextRequest resembling some Unix calls. • CMISE does not have this problem (there is another problem, ROSE response may get too big. TCAP has the best solution with TC-Continue fragmenting too big answers to several messages)

19. SNMP • SNMPv2: SNMPv2 tried to fix the problems of SNMPv1, • The solution for security did not get supports and was left out. The security solution in SNMPv2 is the same as in SNMPv1. • Improvements to Get: • GetBulk - get more values in one request • GetBulk is limited by the Maximum Transmission Unit size. • nonatomic Get -this is partial results (included in CMISE) • Some improvements to SMI: • New types:Counter32, Counter64, UInteger32 • Differences in the definitions, new ASN.1 macros. • It is possible to put more information to MIBs.

20. SNMP • SNMPv2 distributed management concept • One primary manages station which can manage several secondary manager stations. Secondary manager stations manage agents. • This enables the primary manager to use SNMPv2 and the agents to use SNMPv1. • This “3-tier architecture” may reduce network load. (small in any case) • Inform-Request - message between the secondary and the primary manager.

21. SNMP • SNMPv2 RFCs • RFC 1901 Introduction to Community.based SNMPv2 • RFC 1902 Structure of Management Information for SNMPv2 • RFC 1903 Textual Conventions for SNMPv2 • RFC 1904 Conformance Statements for SNMPv2 • RFC 1905 Protocol Operations for SNMPv2 • RFC 1906 Transport Mappings for SNMPv2 • RFC 1907 Management Information Base for SNMPv2 • RFC 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework • In the mappings, there is also specified mapping of SNMPv2 to OSI CLTS (Connectionless Transport Service) and to COTS (Connection Oriented Transport Service). These are used in some operator environments. Usually the transport is UDP.

22. SNMP • SNMPv2 is generally viewed as a minor success and major failure • Spring 1996 work for SNMPv3 was started. • SNMPv3 main improvement is better security features. • Uses MD5 (Message Digest 5), Secure Hash, and DES • can verify that the message is not replayed, messages are crypted • messages are authenticated, message integrity can be checked. • Access rights solution is as in SNMPv1 and SNMPv2. • The basic concept of a manager and an agent is modified, but in practice there is not much difference here. SNMP object can contain functionalities of both a manager and an agent. Modular structure. • RFC 2271 An Architecture for Describing SNMP Management Frameworks • RFC 2272 Message Processing and Dispatching for the SNMPv3 • RFC 2273 SNMPv3 Applications • RFC 2274 User-based Security Model (USM) for SNMPv3 • RFC 2275 View-based Access Control (VACM) for SNMPv3

23. SNMP • Some observations of SNMP in performance management. • A project (Tekes-project Ilias) tried to implement QoS-monitoring using SNMP. • SNMPv1 is widely used, but mainly for monitoring of routers and switches. The monitoring is basically only monitoring of configuration and faults. • We made a survey of content of MIBs for QoS monitoring. There are some definitions, but no implemented MIBs for performance monitoring of FORE ATM switches or CISCO routers. • We tried commercial SNMPv1 products (SNMPv3 not available at that time) MG-SOFT. It had a MIB Compiler. • There is a problem that Set was not supported for security reasons, we had to use get as a set.

24. WBEM Web-based enterprise management • Distributed Management Task Force Inc (DMTF) introduced first standards 1997 for DMI (Distributed Management Interface) and CIM (Common Information Model). See http://www.dmtf.org/ for whitepapers, tutorials and power point presentations. There are quite good overviews. • Why was this made? TMN development seems to have come to a dead point and SNMP is insufficient, even with versions 2 and 3. WBEM claims not to intend to replace CMISE or SNMP but to coexist with them to preserve the investment on these more traditional systems. This is likely to happen, management does not seem to be unified soon. • WBEM work was started by MicroSoft, IBM, BMC Software, Compac and Cisco, has large support and is collaborating with IETF. The Open Group will adopt DMTF’s CIM as an open standard. • Notice, that the force is mostly vendors, not operators. In general, the approach is not aiming to the same goal as TMN. DMTF is not providing one fixed commonly agreed interface like Q3 or SNMP which would enable an operator to manage equipment from many vendors in the same way, but discusses modeling of management systems.

25. WBEM Web-based enterprise management • CIM uses UML (Unified Modeling Language) for representing the class and object structure of a system. That is, objects, classes and their relationships. • Compared with GDMO, UML mostly adds the relationships between the objects. (in TINA there was an extension Quasi-GDMO with GDMO+General Relation Language which is equally powerful as UML, but never much used. • There is another addition: try to use Object Oriented Design methodology. There are books written on OOD and tools supporting it. Is it needed for management? Hard to say, why do you need the class structure for management purposes? • If you do not know UML, see the tutorial of CIM in DMTF pages. • Management information represents data. Data representation principles have been elaborated in relational data bases. These rules include identifying objects with a key instead of an object identifier and rules for relations.

26. WBEM Web-based enterprise management • MOF Managed Object Format • What corresponds to CMISE GDMO MIBs or SNMP SMI MIBs is MOF database • MOF is a simple language resembling IDL (Interface Definition Language) or CORBA. • It probably depends on your background if you find the MOF specifications more readable than GDMO or SMI MIBs. • Any case, you write MOF and there is a MOF compiler which produces definitions which are put to the repository of the CIM Object Manager. • The problem of naming objects and registering classes must be solved also here. There is no global naming system like the distinguished name and the object identifier. CIM OM has a namespace. Naming is based on keys. It is hard for me to see any benefits in this naming system, if not the connection to relational data base methodology.

27. WBEM Web-based enterprise management • WBEM system contains a CIMOM (CIM Object Manager). It is not using the manager-agent paradigm, but more like CORBA (actually DCOM), there is a platform with CIMOM. • The concept of an TMN Q-Adapter is in a way included: there are so called Providers which can use other protocols than CIM/XML over HTTP. In this way WBEM can combine SNMP or CMISE managed subsystems to a larger system. • The name Distributed Management is here motivated in a similar way as in ODMA (Open Distributed Management Architecture) of ISO and in the SNMP concept of distributed management. Naturally, in all management systems there is a managing system and managed systems, but a distributed management is either on a platform removing the task of locating the agents, or it is a multi-level management system. WBEM is distributed management in both meanings.

28. WBEM Web-based enterprise management • The PDUs are transported on top of HTTP over an internet. The PDUs are coded according to xmlCIM, that is XML (eXtendable Markup Language) definitions according to the CIM model. • The WBEM operations (=service primitives) over HTTP are defined and grouped into the following types: • Data, Meta Data, Queries, Methods. • There are more operations than in CMISE because there has not been an effort to select a small set of operations and because the CIM class schema can be modified. (In CMISE you cannot modify the GDMO definitions.)

29. WBEM Web-based enterprise management • Conclusions: is this the solution? • It is hard to say (for me). There is a large vendor support for the time being (but which major effort does not have a large support while new) • The main problem has been connection to real resources. If vendors make it for WBEM, then this may be solved. • There are solutions for installation of new software applications by management. This is an old problem not treated by TMN. • Web is a success, so is HTTP. XML may be good, it is popular at least. • But: This is not simple and the solution details are not quite the best. • It is unclear what problem this solution solves. It does not seem to provide a simple common interface for a network operator. • UML classes have methods (actions), how are notifications handled? They can be made as methods and there is the Indication mechanism but the model is less clear. • MOF naming solution seems poorer than in the competitors. • Relationships in the UML class and object diagrams, why? • XML probably it is not very efficient in number of bytes transported.