Mạng và viễn thông P27

Chia sẻ: Hug Go Go | Ngày: | Loại File: PDF | Số trang:15

Thêm vào BST

Báo xấu

59
lượt xem 5
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Telecommunications Management Network (TMN) The goalof the ‘telecommunications management network’o r ‘ T M Nis to provide for consistent and efficient management of complex telecommunications networks. The T M N model describes the basic operating and management functionswhich a network operator has to conduct and the standard interfaces to be used between network components and network managementsystems.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Mạng và viễn thông P27

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) 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 goalof the ‘telecommunications management network’o r ‘ T M Nis to provide for consistent and efficient management of complex telecommunications networks. The T M N model describes the basic operating and management functionswhich a network operator has to conduct and the standard interfaces to be used between network components and network managementsystems. Key elements of the T M N concept are the management model, the Q3-interface and the CMIP (commonmanagementinformationprotocol).We discuss them allinthis chapter, whichin 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 analternative 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, buteachprovided by different manufacturers.Theyeachhave 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 componenttypes shown are 0 data switches, managed by a ‘proprietary’ network management system, NMSl 0 SDH (synchronousdigitalhierarchy)transmissiontechnology(linkssome 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
478 (TMN) NETWORK TELECOMMUNICATIONS MANAGEMENT 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 andNMS2. 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 the adjoining switches has a malfunctioning of port and the other adjoining switch is isolated.Otherswitchesmayreport ‘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 amountof 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 colleagueat the isolatedswitch site. Having done so, he is able to rule out a local cause. next he calls his SDH colleague and, of So 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 peacehis SDH as Q alarm $( line failure Figure 27.1 A typical telecommunications network
NETWORK PROVISIONING 479 Figure 27.2 Recognizingthatanetwork islikespaghettiandthealarms 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 just as complex and labour-intensive as fault is finding. Imagine trying to up a single permanent connection (say a frame relay PVC) set 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 connectionand let a computer coordinate and execute the rest. Enormous savingineffort is possible,togetherwithhigherquality and faster installation work. . . . And by being able quickly to trace the complete path or trailof a single connec- tionthroughthenetwork (e.g. Figure 27.2) usingsophisticatedcomputernetwork managementtools,operationsstaffcanmorequicklydiagnosefaultsandresolve
480 TELECOMMUNICATIONS MANAGEMENT NETWORK (TMN) problems if they arise later. Furthermore, by computer ‘filtering’ of the alarms, it may be possibleto reduce the ‘Christmas tree lights’ the one or two alarms are most to which 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 MANAGEMENTSYSTEMS 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 typeof network element.) A single command issued to the umbrella systemby a human operator would be all that is needed to configure a new trunk between any two of the switches Figure 27.1. of 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
NETWORK UMBRELLA 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 TMN 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 communicationsnetwork ( D C N ) merelyprovidesameans for connectingtogether 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 variousnetwork operations, administration and management functions pro- (e.g. 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 operatingsystems(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 methodsof 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 data communications network F-interface interface OS to WS MD mediation device NE network element os operations system (&-interface interface of TMN to NE QA Q adaptor ws workstation X-interface interface between TMNs Figure 27.4 TMN model: defined functions and interfaces (courtesy o f ITU-T)
482 (TMN) TELECOMMUNICATIONS NETWORK MANAGEMENT network manaaer l Figure 27.5 4 3 - and X-interfacesaretheimportantinterfacesbetweennetworkmanagers 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 sent be 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 mediationdevice is applied to anydevicecarrying 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 intothe manager(operatingsystem) 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 4 enquiries and commands 3 and translating them as necessary into the proprietary formatof the particular network component.
THE Q3-INTERFACE 483 27.4 THE Q3-INTERFACE, THECOMMON MANAGEMENT INFORMATION PROTOCOL(CMIP)ANDTHE CONCEPT OF MANAGED OBLECTS (MO) Crucial the for successful communication between manager agent the and over 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 allowinga CMISE (common managementinformationservice entity, i.e.asoftware function)inthemanager to communicatestatusinformationandnetworkcontrol 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, CMISandCMIPdonot conveyanyusefulinformation from manager to agent. They are simply the ‘rules orderly conversation’. In the same way of that theproject manager of a major building projectcan make sure that instructions are Table 27.1 The basic CMISE (common management information service entity) services Service name Function M-ACTION service This requests an action to be performed on managed a object, defining conditional any statementswhich be must fulfilled before committing to action M-CANCEL-GETThisserviceisused to requestcancellationof an outstandingpreviously requested M-GET command M-CREATE service This is used to create new instance of a a managed object (e.g. a new port now being installed) M-DELETE service used This is to delete an instance of amanagedobject a (e.g. 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 requests This service status information values) (attributeaof given managed object. Certain filters may be set limit the scope of the reply to M-SET requests This service modification the of a managedattribute object value (i.e. is a command for parameter reconfiguration)
484 (TMN) NETWORK TELECOMMUNICATIONS MANAGEMENT issued to the electrician, the brick layer and the plumber and thateach 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 codedaccording totheappropriate managementinformationbase ( M Z B ) of managed objects. A managedobject isastandardizeddefinitionofaparticulartype of network component, and thenormalized 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 itis, 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 buywhichever device is mostaesthetically 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 not do exist. They usually grouped are 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 componentsis 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 viceAccessPoint residentialuser Figure 27.6 A simple managed object inheritance hierarchy
MODELTHE I S 0 MANAGEMENT 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 definedin ITU-Trecommendation X.722. These are the guidelines f o r the dejinition of managed objects (GDMO). They includestrictrules about the naming and spelling conventions and the hierarchical structure. There are a number of commercial software products availableto help with the task (so-called GDMO browsers). Figure 27.6 illustrates a relatively simple managed object inheritancehierarchy, 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 Performancemanagement,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. Conjigurationmanagement is themaintenance of networktopologyinformation, routing tables, numbering, addressingand 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 andTMN system users 0 security of data
486 (TMN) TELECOMMUNICATIONS NETWORK MANAGEMENT 0 confirmation of requestednetworkmanagementactions,particularlycommands creating or likely to create major network or service upheaval 0 logging of network management actions (forrecovery purposes when necessary, and also for fault auditing) 0 maintenance of data consistency using strict change management 27.6 TMNMANAGEMENTFUNCTION 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, N E L ) are the networkelements 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 ( E M L ) 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 ( N M L ) are managers which control the main aspects of a given network type (e.g. ISDN or ATM). management 1 layer management layer management layer management layer element layer Figure 2 . The functional layers of TMN 77
THE NETWORK MANAGEMENT FORUM (NMF), OMNIPOINT AND SPIRIT 487 The service management layer ( S M L ) contains service managers which monitor and control allaspectsofa given service, onanetwork indepdndentbasis.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 a of given customersconnection line needs onthe appropriate network(s) and monitors the service delivered against a contracted frame relay service level agreement. The business management layer ( B M L )contains functionality necessary for the man- agement of a network operator’s company organization as a whole. Thus purchasing, or 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 initiativeshave been commencedoverthelast six years to speedprogressinthe development of umbrella network management systems. The firstmajorinitiative,startedin 1989, wasthe NetworkManagementForum ( N M F ) . 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, N M F in its OMNIpoint specifications aims to provide further clarifying specifications. A number of hardware and software manufacturers claim alreadyto have OMNIpoint- compliantsystems.These,inthemain,aresystemscompliantwith OMNIpointl. Unfortunately, compliance to OMNIpointl not mean much. Compatibility com- does of 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 N M F has been the SPIRIT (service providers integrated requirements f o r informationtechnology) 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 ATMN How does this all fit together? Figure 27.8 shows a possible layered software configuration of a TMN system, based on a client/server computer hardware platform
488 (TMN) TELECOMMUNICATIONS NETWORK MANAGEMENT TMN applications TMN platform components and software development platform and test ORB (CORBA) environment computer hardware and operating system software {7 11 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 theamount of software which hasto be writtenfor specific services or network operators. The layered approach leads to more rapid development, greater sharing with 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 telecommunicationsmanagement network ( T M N ) . 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 networkand systemreconfiguration(includingautomaticchangeovertobackup facilities) 0 fault localization
NETWORK SIMPLE MANAGEMENT PROTOCOL (SNMP) 489 In addition to TMNinterfaces, some earlyATM equipment is likely to offer the S N M P (simple network management protocol), because this is the basis of the ATM interim local management interface ( I L M I ) . 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 ( M I B ) . 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 ATMnetwork 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 work must be applied to the definition of of the standard M I B (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. 27.10 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) The simple network management protocol( S N M P ) is a protocol in many ways similar to TMN’s common management information protocol ( C M I P ) . It also allows for creation of umbrella network management systems by allowing for communication of status information and commands (i.e. management information base, M I B 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 ( I E T F ) and is defined in its specification RFC 1157. Although ITU-T was developing CMIP asa 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 S N M P 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. 27.11 SUMMARYOFTMN BENEFITS Assimilation of the various functions and interfaces of the TMN architecture into the network management plans network operating organizations has a number of of benefits 0 the opportunityto develop quality high networkmanagement methods and processes supported by industry-standard products
490 (TMN) TELECOMMUNICATIONS NETWORK MANAGEMENT 0 the scope to force suppliers of network switches and other components to develop new functionality crucial to effective network management and TMN as a whole 0 in particular, Q3-interface CMIP the and (common management information protocol) are already widely adopted standards 27.12 TELECOMMUNICATIONS INTELLIGENT NETWORK ARCHITECTURE (TINA) Finally,the telecommunicationsintelligentnetworkarchitecture (TINA ) should be mentioned before leaving the subject of TMN, because there are some areasof overlap. TINA is a relatively new initiative, based upon the observation that both intelligent networks (Chapter 11) and T M N areaddressingtheproblems of management of complex networks. TZNA is an attempt to combineTMN and intelligent network ideas and to re-define the ideal network architecture of future networks.