Tài liệu Mạng và viễn thông P27 pdf

The T M N 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 netwo

PART 5

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

The goal of the ‘telecommunications management network’ o r ‘ T M N is to provide for consistent and efficient management of complex telecommunications networks The T M N 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 T M N 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 a n 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

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 ( N M S ) 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, NM S l

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, NM Sl

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 NM S l 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 ( N E M ) 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 ( T M N ) 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 T M N model (Figure 27.4) are the operating system ( O S ) ,

the network element (actually the network element manager) and the workstation ( W S )

The key interfaces are the Q3-interface, the X-interface and the F-interface The data communications network ( D C N ) merely provides a means for connecting together network management devices and network components in different locations

The operating system ( O S ) 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 ( N E ) 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

mediation device network element operations system

interface of TMN to NE

workstation interface between TMNs

Figure 27.4 TMN model: defined functions and interfaces (courtesy o f ITU-T)

482 TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN)

network manaaer

l

Figure 27.5 4 3 - 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 ( Q A ) 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 ( W S ) 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 ( N E M )

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

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, C M I P )

0 the definition of standardized network status information and control messages for

particular standardized types of network components (so-called managed objects)

C M I P (common management information protocol) delivers the common management information service ( C M I S ) 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

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 ( M Z B ) 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

residentialuser serviceAccessPoint

Figure 27.6 A simple managed object inheritance hierarchy

THE I S 0 MANAGEMENT MODEL 485

The definition of managed objects ( M O ) and managed information bases (MIBs), like other OS1 layer 7 protocol objects, is carried out in the abstract syntax notation 1

( A S N 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 f o r the dejinition of managed objects ( G D M O ) 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 I S 0 MANAGEMENT MODEL

I S 0 (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 T MN system users security of data