PART
5
RUNNING
A
NETWORK
Networks and Telecommunications: Design and Operation, Second Edition.
Martin P. Clark
Copyright © 1991, 1997 John Wiley & Sons Ltd
ISBNs: 0-471-97346-7 (Hardback); 0-470-84158-3 (Electronic)
27
Telecommunications Management
Network
(TMN)
The goal
of
the ‘telecommunications management network’ or ‘TMN is to provide for consistent
and efficient management of complex telecommunications networks. The TMN model describes
the basic operating and management functions which a network operator has to conduct and the
standard interfaces to be used between network components and network management systems.
Key elements
of
the TMN concept are the management model, the Q3-interface and the
CMIP
(common management information protocol). We discuss them all in this chapter, which in
parallel gives an insight into the problems
of
managing complex networks. At the end, we also
briefly discuss the
SNMP (simple network management protocol), which is used as an alternative
to CMIP in many corporate and Internet/router networks.
27.1
THE
PROBLEMS
OF
MANAGING
NETWORKS
Figure 27.1 illustrates a typical telecommunications network of today. It provides a
valuable insight into the complexity of managing even relatively simple telecommunica-
tions networks. The figure shows a simple data network composed of four different
component types, but each provided by different manufacturers. They each have
independent
network management systems
(NMS).
Each NMS is capable
of
monitoring
and controlling every aspect its manufacturer’s network equipment, but
is incapable of
monitoring or controlling other manufacturers’ devices. The component types shown are
0
data switches, managed by a ‘proprietary’ network management system, NMSl
0
SDH (synchronous digital hierarchy) transmission technology (links some of the
switches and is managed by NMS2)
0
TDM (time division multiplex) transmission technology (links some of the switches
and is managed by NMS3)
477
Networks and Telecommunications: Design and Operation, Second Edition.
Martin P. Clark
Copyright © 1991, 1997 John Wiley & Sons Ltd
ISBNs: 0-471-97346-7 (Hardback); 0-470-84158-3 (Electronic)
478
TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)
0
direct leaselines provide for remaining switch links. These are supplied by another,
public telecommunications network operator, for which there is no management
system available to our operator
A simple line failure is illustrated in Figure 27.1. An SDH connection has failed. The
result is
a
plethora of alarms generated by both NMSl and NMS2. The network status
screens of both NMS are likely to light up like Christmas trees in all sorts
of
colours.
The SDH network management system, NMS2, will pinpoint the root cause of the
problem, probably with the appropriate link alarm indicated in red. Meanwhile, NMSl
is also showing red alarms, because one of the adjoining switches has a malfunctioning
port and the other adjoining switch is isolated. Other switches may report ‘yellow
alarms’ as connections to the isolated switch have been lost. The exact cause of the
problem, however, will not be clear from the information that appears on NMS1. Un-
fortunately, this is likely to lead to a certain amount of confusion and wasted effort.
.
.
.
.
.The human operator managing the SDH network naturally starts about his
repair.
. . meanwhile. . .
.
.
.His colleague, the switch network manager watching the screen of NMSl is
unaware of the root cause. Instead he addresses what appears to him to be the urgent
problem of the isolated switch. Perhaps there has been a power failure? Maybe the
switch needs to be restarted?.
.
.
He calls his colleague at the isolated switch site. Having
done
so,
he is able to rule out a local cause.
So
next he calls his SDH colleague and, of
course, discovers the most likely cause of his
own
alarms. He hands over responsibility
and starts to get on with something else.
But, you might ask, why did the switch manager not call the SDH manager to start
with? The answer is that he is unable to determine easily the single cause of a lot of
alarms. He must therefore address each alarm in turn, diagnosing the most critical
alarms first.
Considerable effort may go into checking each alarm and concluding a single root
cause. Only afterwards can the human network manager truly rest in peace as his SDH
Q
alarm
$(
line
failure
Figure
27.1 A typical telecommunications network
NETWORK PROVISIONING 479
Figure
27.2
Recognizing that a network is like spaghetti and the alarms are like Christmas
tree lights
colleague gets on with the job of network
restoration.
Afterwards, despite his clear
conscience, the alarms on his own screen do not go away
.
So
when another fault
arises before the first is cleared, the diagnosis becomes more confused and difficult as
the alarms inter-mingle.
In real networks, many simultaneous faults are likely to be present at any point in
time, even if they are of a non-critical nature. Working out which alarm belongs to
which bit of network equipment is a complex task, like finding the knot in spaghetti!
(Figure 27.2).
27.2 NETWORK PROVISIONING
Provisioning of new lines in the network is just as complex and labour-intensive as fault
finding. Imagine trying to set up a single permanent connection (say a frame relay PVC)
across the networks of either Figure 27.1 or Figure 27.2. First someone must sit down
to ‘design’ the connection (work out the path), allocate ports and network addresses.
Next, each of the TDM and telephone switch ports need to be programmed. The SDH
links must be configured. The leaselines must be ordered. Finally comes the hope that
all the installation staff in the chain do their jobs on-time and accurately, otherwise
the connection fails an end-to-end acceptance check. It would be preferable to define
the desired end-points of the connection and let a computer coordinate and execute the
rest. Enormous saving in effort is possible, together with higher quality and faster
installation work.
. . . And by being able quickly to trace the complete path or trail of a single connec-
tion through the network (e.g. Figure 27.2) using sophisticated computer network
management tools, operations staff can more quickly diagnose faults and resolve
480
TELECOMMUNICATIONS MANAGEMENT
NETWORK
(TMN)
problems if they arise later. Furthermore, by computer ‘filtering’ of the alarms, it may
be possible to reduce the ‘Christmas tree lights’ to the one or two alarms which are most
likely to be the direct cause of a problem. This would greatly help our fault-correcting
friends in Figure 27.1.
27.3
UMBRELLA NETWORK MANAGEMENT SYSTEMS
A
number of network operators, computer manufacturers and software developers
started during the 1980s to develop the idea of
umbrella network management
systems
(Figure 27.3). These were to be powerful network management systems capable of
controlling the network as a whole. They would be able to correlate and present the
various pieces of information from individual
network element managers
(NEM)
thus
removing this arduous coordination task from human operators. (Note: NMS1, NMS2
and NMS3 of Figure 27.1 are
network element managers
because they are network
management systems capable only of managing a particular type of
network element.)
A
single command issued to the umbrella system by a human operator would be all
that is needed to configure a new trunk between any two of the switches of Figure 27.1.
The umbrella system managers see to it that the plethora of comands needed to be
issued to the individual network elements are generated (one command to configure a
new port at one switch, a second command for the second switch, a third command to
the
SDH
NMS to establish the transmission path, etc.).
For the umbrella network management system to work properly, a defined, standard
interface between the umbrella network management system and each of the
network
element managers
is needed. Over this interface the umbrella network management
umbrella network
management system
UMBRELLA NETWORK MANAGEMENT SYSTEMS
481
system needs to be capable of receiving information on request about the status of
specific network elements and to be able to issue commands for reconfiguration or
control
of
the various sub-networks.
One of the first steps taken by CCITT (now ITU-T) in defining its standards for
telecommunications management network
(TMN)
was to define a model of the various
functions and interfaces going to make up a complete network management system.
This is laid out in ITU-T recommendation M.3010 and is illustrated in Figure
27.4.
The key components of the TMN model (Figure
27.4)
are the
operating system
(OS),
the
network element
(actually the
network element manager)
and the
workstation
(WS).
The key interfaces are the
Q3-interface,
the
X-interface
and the
F-interface.
The
data
communications network
(DCN)
merely provides a means for connecting together
network management devices and network components in different locations.
The
operating system
(OS)
is analogous to what we previously called an
umbrella
network management system,
except that there is no longer any presumption that all the
various network operations, administration and management functions (e.g. pro-
visioning, troubleshooting, etc.) can be handled by a single computer system. Instead,
a number
of
operating systems
combined together will handle the full functionality of
our previous
umbrella
system.
A
standard interface between operating systems (the
X-interface)
allows this subdivision.
Individual
network elements
(NE)
probably each have their own proprietary network
management systems
(network element managers),
which cater for the specialized func-
tions and operating methods of a particular manufacturers hardware. The
Q3-interface
provides for a standard means of communication between the
operating systems
(i.e.
‘umbrella’
managers)
and individual
NEMs.
The network element manager acts as an
m
DCN
F-interface
MD
NE
os
(&-interface
QA
ws
X-interface
data communications network
interface
OS
to
WS
mediation device
network element
operations system
interface
of
TMN
to
NE
Q
adaptor
workstation
interface between TMNs
Figure
27.4
TMN
model: defined functions and interfaces (courtesy of
ITU-T)
482
TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)
network manaaer
l
Figure
27.5
43-
and X-interfaces are the important interfaces between network managers
and agents
agent,
interpreting the commands issued across the
Q3-interface
and reacting upon them
in conjunction with the individual
network elements.
Thus status information can be sent
to the manager and control commands can be executed in the network by the
agent.
When necessary, a translation function can be used to convert
Q3-interface
com-
mands into the proprietary format needed by a specific network element. This trans-
lation function is termed the
Q-adaptor function
(QA).
Where the individual network
elements can respond directly to
Q3
commands, it is not necessary.
The term
mediation device
is applied
to
any device carrying out a conversion of
protocol or data format necessary for the interconnection of devices. The diagram
should not be taken to imply that a single
mediation device
will cater for all necessary
mediation needs.
The
work station
(WS)
is equivalent to a technicians laptop computer.
A
standard
interface (the
F-interface)
allows him to log into the
manager (operating system)
wherever he may be (in the exchange building or in the field).
Figure
27.5
duplicates the
TMN
model as already shown in Figure
27.4,
but now we
see more clearly the typical system boundaries of real network management systems.
The
manager
is a so-called
umbrella network management system,
capable
of
consoli-
dating information fed to it by separate proprietary
network element managers
(NEM).
The manager communicates with the various individual network element managers by
means of the
Q3-interface,
interpreting the standardized
43
enquiries and commands
and translating them as necessary into the proprietary format of the particular network
component.
THE Q3-INTERFACE
483
27.4
THE Q3-INTERFACE, THE COMMON MANAGEMENT
INFORMATION PROTOCOL (CMIP) AND THE CONCEPT
OF
MANAGED OBLECTS (MO)
Crucial for the successful communication between manager and agent over the
Q3-interface are
0
the definition of a standard protocol (set of rules) for communication (this is the
common management information protocol, CMIP)
0
the definition of standardized network status information and control messages for
particular standardized types of network components (so-called
managed objects)
CMIP (common management information protocol)
delivers the
common management
information service (CMIS)
to the
operating system
of Figure
21.4.
CMIS is the service
allowing a
CMISE (common management information service entity,
i.e. a software
function) in the manager to communicate status information and network control
commands with a CMISE in each of the various agents. CMIP itself is an OS1 layer
7
protocol, which sets out the rules by which the information and commands (CMISE
services) may be conveyed from
manager
to
agent
or vice-versa. These basic CMISE
services are restricted in number. They are listed in Table
27.1.
However, alone, CMIS and CMIP do not convey any useful information from
manager to agent. They are simply the ‘rules of orderly conversation’. In the same way
that the project manager of a major building project can make sure that instructions are
Table
27.1
The basic CMISE (common management information service entity) services
Service name Function
M-ACTION This service requests an action to be performed on a managed object,
defining any conditional statements which must be fulfilled before
committing to action
M-CANCEL-GET This service is used to request cancellation of an outstanding previously
requested M-GET command
M-CREATE This service
is
used to create a new instance
of
a managed object (e.g.
a
new port now being installed)
M-DELETE This service is used to delete an instance of a managed object (e.g. a port
being taken out of service)
M-EVENT-REPORT This service reports an event, including managed object type, event type,
event time, event information, event reply and any errors
M-GET This service requests status information (attribute values) of a given
managed object. Certain filters may be set to limit the scope of the reply
M-SET This service requests the modification of
a
managed object attribute
value (i.e. is a command for parameter reconfiguration)
484
TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)
issued to the electrician, the brick layer and the plumber and that each of the craftsmen
understands his instructions and completes them on time,
so
CMIS is able to ‘project
manage’ the task of managing a network. The actual content of the network manage-
ment ‘work instructions’ depends on the particular network component being managed,
and is coded according to the appropriate
management information base (MZB)
of
managed objects.
A
managed object
is a standardized definition of a particular type of network
component, and the normalized states in which it can exist. Imagining a water bottle to
be described as a standard
managed object
it might be ‘a vessel for storing one litre of
liquid’ (exactly what shape it is, is unimportant). Its top might be a screw top, a cap-top
or a cork, but as a
managed object
all three are simply ‘watertight stoppers’ which may
either be ‘secured’ or ‘opened’. Standardized states may thus be ‘full’, ‘empty’, ‘half
full’, etc., while control commands might be ‘fill up’, ‘pour out’, ‘secure stopper’, ‘undo
stopper’, etc. Provided that all manufacturers of water bottles produced products able
to respond to these commands you can buy whichever device is most aesthetically
pleasing without the concern of not being able to get the lid
off!
Managed objects are nowadays defined for most new computer and telecommunica-
tions products. They may be defined either on an industry standard basis or by the
individual manufacturer, where industry standards do not exist. They are usually grouped
into sets corresponding to individual device types or network components. These are
called
management information bases (MZBs).
Thus there is an
MZB
for
routers
used
on the
Internet.
There is also an
MZB
for the
ISDN
basic rate interface (Chapter 10).
Of course there are many other MIBs, but many more will need to be defined.
Having well-defined MIBs for each of the network components
is
key the realization
of the dream of a complete
umbrella manager,
capable of coordinating all network
components. It is thus the MIBs which provide the critical information content of the
messages. It is, after all, of no use to tell someone to ‘act on’ or ‘carry out’ something
unless you also tell him you are talking about the ‘water bottle’ and he is to ‘open it’).
address profile
businessuser teleservice
residentialuser serviceAccessPoint
Figure
27.6
A
simple
managed
object inheritance hierarchy
THE
IS0
MANAGEMENT MODEL
485
The definition of
managed objects
(MO) and
managed information bases
(MIBs),
like other OS1 layer 7 protocol objects, is carried out in the
abstract syntax notation
1
(ASN.1)
about which we learned in Chapter
9.
The procedure of definition, including
advice on how to group and subdivide MOs is defined in ITU-T recommendation
X.722. These are the
guidelines for the dejinition
of
managed objects
(GDMO).
They
include strict rules about the naming and spelling conventions and the hierarchical
structure.
There are a number of commercial software products available to help with the task
(so-called
GDMO
browsers).
Figure 27.6 illustrates a relatively simple
managed object
inheritance hierarchy,
showing the various states and attributes of a given managed
object (in this case a network service).
27.5 THE
IS0
MANAGEMENT MODEL
IS0
(International Organization for Standardization)
has developed a standard model
classifying the functional processes which must be undertaken in the management of
computer and telecommunications networks. All management tasks are classified into
one of the following five (FCAPS) categories
0
Fault management
0
Configuration management
0
Accounting management
0
Performance management, and
0
Security management
This model is referred to widely by ITU-T’s recommendations on a
telecommunications
management network,
and is reproduced in the ITU-T X.700-series recommendations.
Fault management
is the logging of reported problems, the diagnosis of both short
and long term problems, ‘blackspot’ analysis and the correction of faults.
Conjiguration management
is the maintenance
of
network topology information,
routing tables, numbering, addressing and other network documentation and the coord-
ianation of network configuration changes.
Accounting management
is the collection and processing of network usage informa-
tion as necessary for the correct billing and invoicing of customers and the settlement
with operators of interconnected networks.
Performance management
is the job
of
managing the traffic flows in a live network,
monitoring the traffic flows on individual links against critical threshold values and
extending the capacity of links or changing the topology by adding new links. It is the
task of ensuring performance meets design objective (e.g.
service level agreement).
Security management
functions include
0
identification, validation and authorization of network users and TMN system users
0
security
of
data
486 TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)
0
confirmation of requested network management actions, particularly commands
creating or likely to create major network or service upheaval
0
logging of network management actions (for recovery purposes when necessary, and
also for fault auditing)
0
maintenance of data consistency using strict
change management
27.6
TMN MANAGEMENT FUNCTION MODEL
Figure 27.7 illustrates the five layers of functionality defined by the
OS1
management
model for a TMN. The layers are intended to help in the clear and rational definition of
TMN
operating system
boundaries,
so
simplifying the definition, design and realisation
of systems, by simplifying their data and communication relationships to one another.
At the lowest functional layer of Figure 27.7
(network element layer, NEL)
are the
network elements
themselves. These are the active components making up the net-
works. Above them, in the second layer of the hierarchy, is the
element management
layer (EML)
containing
element managers. Element managers
are devices which control
single network components or sub-networks (e.g. a local management terminal or a
proprietary
network management system).
At the third layer, the
network management layer (NML)
are
managers
which control
the main aspects of a given network type (e.g.
ISDN
or ATM).
management
layer
management
layer
management
layer
management
layer
element
layer
1
Figure
27.7
The
functional layers
of
TMN
THE NETWORK MANAGEMENT FORUM (NMF), OMNIPOINT AND SPIRIT
487
The
service management layer
(SML)
contains
service managers
which monitor and
control all aspects of a given service, on a network indepdndent basis. Thus, for
example, it is possible in theory to conceive a
frame relay service
provided over three
different network types:
packet
switched-type network, ISDN and ATM. The service
manager ensures installation of a given customers connection line needs on the
appropriate network(s) and monitors the service delivered against a contracted frame
relay
service level agreement.
The
business management layer
(BML) contains functionality necessary for the man-
agement of a network operator’s company or organization as a whole. Thus purchasing,
bookkeeping and executive reporting and information systems are all resident in this
layer.
27.7 THE NETWORK MANAGEMENT FORUM (NMF),
OMNIPOINT AND SPIRIT
In addition to the standardization activities of IS0 and ITU-T, a number of industry
initiatives have been commenced over the last six years to speed progress in the
development of umbrella network management systems.
The first major initiative, started in 1989, was the
Network Management Forum
(NMF).
This is composed of major network operators (e.g. British Telecom) and com-
puter manufacturers (e.g. IBM,
DEC, SUN, Hewlett Packard), who have together formed
a common interest group to speed the realization and acceptance of common network
management standards. Valuable outputs of this group have been the
OMNIpoint
and
SPIRIT
specifications.
The
OMNIpoint
specifications are intended as a set of specifications and guidelines
for implementors of network management systems. They attempt to review standards
issued by main standards bodies and build inputs from various sources into a con-
solidated (and realisable) whole. Where standards are vague, NMF in its
OMNIpoint
specifications aims to provide further clarifying specifications.
A number of hardware and software manufacturers claim already to have
OMNIpoint-
compliant systems. These, in the main, are systems compliant with
OMNIpointl.
Unfortunately, compliance to OMNIpointl does not mean much. Compatibility of com-
pliant systems is not guaranteed. More interesting is
OMNIpoint2,
which has recently
(November 1995) been published by NMF. This aims to be a fuller set of specifications
for TMN-compliant systems.
A
second valuable output of NMF has been the
SPIRIT
(service providers integrated
requirements for information technology)
specifications. These attempt to lay out a
standard hardware and computer operating system software platform for the realiza-
tion of development and run-time platforms for TMN-compliant network management
systems. SPIRIT 2.0 was issued in November 1994.
27.8 REALIZATION OF A TMN
How does all this fit together? Figure 27.8 shows a possible layered software
configuration of a TMN system, based on a client/server computer hardware platform
488
TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)
TMN applications
TMN platform
components and
ORB
(CORBA)
software
development
platform
and test
environment
hardware and
{
71
1
computer
operating system
software
data network
ORB
=
object request broker
CORBA
=
common object request broker architecture
NE
=
network element
Figure
27.8
Possible computer hardware and software realization
of
TMN
according to SPIRIT, with the latest object-oriented computing software (CORBA)
loaded upon it. Above this, there are some generic tools and processes, thereby limiting
the amount of software which has to be written for specific services or network
operators. The layered approach leads to more rapid development, with greater sharing
of development costs and benefits.
27.9
EXAMPLE OF EARLY
TMN
REALIZATION
The operations and maintenance functions defined for ATM networks are designed
according to the principles of the
telecommunications management network
(TMN).
Specifically, the ATM standards define the following management functions
0
performance monitoring
0
defect and failure detection (by continuous monitoring and generation of alarms)
0
network and system reconfiguration (including automatic changeover to backup
facilities)
0
fault localization
SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)
489
27.10
27.11
In addition to TMN interfaces, some early ATM equipment is likely to offer the
SNMP
(simple network management protocol),
because this is the basis of the ATM
interim
local management interface
(ILMI).
ILMI enables the management of UN1
managed
objects
(switches, devices, parameter settings, etc.), thus making management control of
devices possible across the ATM UNI. Together the
managed objects
make up the UN1
management information base
(MIB).
The short term attraction of SNMP as the basis for ILMI lies in its widespread
deployment in existing corporate data networks, routers, LANs (local area networks)
and
Internet
components.
Future standardization work on ATM network management is likely to concentrate
on migration to the
CMZP
protocol (probably by integration of certain SNMP pro-
cedures into it). In addition, a huge amount of work must be applied to the definition of
the standard
MIB
(management information base)
of
managed objects
relevant to ATM
networks and devices. Without these definitions, it will be impossible to develop the
necessary tools for management of the network as a whole. At the moment these are
poorly defined.
SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)
The
simple network management protocol
(SNMP)
is a protocol in many ways similar to
TMN’s
common management information protocol
(CMIP).
It also allows for creation
of umbrella network management systems by allowing for communication of status
information and commands (i.e.
management information base,
MIB
information) by
means of an industry-wide accepted protocol. The main technical difference between
SNMP and CMIP is its simplicity. SNMP was developed by the
Internet Engineering
Task Force
(IETF)
and is defined in its specification RFC
1157.
Although ITU-T was developing CMIP as a robust protocol, conforming with all the
requirements of the OS1 model, the engineers involved in developing and installing
routers and other networks for the
Internet
and other corporate data networks were
keen to have a short term solution. SNMP was the answer. It is widely deployed in
corporate data networks, where the term
SNMP
manager
is applied to several types of
available devices capable of acting as basic
umbrella
network managers.
A new version of SNMP, SNMP2 has recently been agreed. This is significantly more
complex than SNMP. Meanwhile, SNMP and CMIP protocols are beginning to con-
verge as the work on defining common
management information bases
proceeds.
SUMMARY OF TMN BENEFITS
Assimilation of the various functions and interfaces of the TMN architecture into the
network management plans of network operating organizations has a number of benefits
0
the opportunity to develop high quality network management methods and
processes supported by industry-standard products
Không có nhận xét nào:
Đăng nhận xét