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.
Network Management summary
TMN (Telecommunication Management Network) is ITU-Ts 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).
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.
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.
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.
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.
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.
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.
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


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
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?
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.
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.
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.
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.
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.)
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.
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)
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.

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.

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.
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
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.
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 DMTFs 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.
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.
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.
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.
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.)
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.