Communications Management. 3ICT12 (with thanks to Prof. George Pavlou, University of Surrey)

Transcription

1 Communications Management 3ICT12 (with thanks to Prof. George Pavlou, University of Surrey) 1

2 Communications Management Network Management Overview What is Network Management? Manager Agent Model OSI Management: Comparison to Internet Management Telecommunications Management Network Other approaches to integrated management 2

3 Typical problems for a network administrator What is actually connected to the network? Which nodes should be able to communicate? Why is user traffic performance poor? Why can t these users connect? Where is the fault? How much network capacity is being used? How much capacity is needed? A network manager is a person responsible for the operation and management of a network to ensure to meets its required function, typically connecting users to each other or to some other machines. In managing a network of any size the following problems are typically encountered: Determining the current configuration of the network, what nodes exist in the network, what terminals are attached to the network, which nodes and terminals are actually supposed to be able to communicate with each other. In addition the network manager needs to be able to control such configuration in more precise ways than simply plugging and unplugging wires. Users often experience network response that is less than what would be expected given the capacity of the network nodes and lines connecting them. This is often due to some partial failure or misconfiguration of the systems, and determining the reason for this may sometime require performing measurements at different points in the network. As well as poor performance users can often be cut off completely. This is often the result of a fault somewhere in the network, that has to be located before it can be rectified. Ideally the network manager would like to do this before the user is effected. If a network is not centrally funded, then often it is essential to record the usage of the network from different entities, so they may be charged for this. Equally network planners need to know how much a network is used over time in order to plan changes in network capacity. 3

4 Concerns for Communications Management Systems Geographical separation of systems Concurrent operation of systems Heterogeneity of systems Organisational autonomy of systems and (sub) networks Scale of the system Minimising impact of management on communications systems Network managers often turn to some form of software system to aid them in performing their tasks, which may become very difficult in large, complex networks. Some of the issues faced when designing network management systems are: The systems that are to be managed are by their nature distributed, so network management Software must operated in a distributed manner. The different network nodes being managed all operate concurrently, and it is therefore impossible to determine absolutely the state of all node at any one point in time. The systems being managed come from different vendors and will possess different data representations, different data management techniques, different operating systems etc. Different nodes in networks are often under different administrative authorities, so no-one person may have overall control over all nodes in an end-to-end data path. The network management system will itself be using network resources, but this should not impact too heavily on the availability of those resources for use the networks primary users. The scale of the network to be managed has a major impact on the management systems. The manager of a telecommunications systems with 1,000s of nodes and millions of users has different requirements in terms of performance than the manager of an office LAN. 4

5 The Manager-Agent Model MIS-user (manager role) Communicating Management operations Notifications MIS-user (agent role) Performing management operations Notifications emitted Managed objects TISO Management needs a model to enable it to interact with network elements in an open, network and technology independent fashion. All management models today are based on object-oriented design principles and follow the manager-agent model. According to that model, every network or other equipment that needs to be managed offers an abstract view of its resources as managed objects and enables the co-ordination of access to them through an agent. Applications on manager roles access those objects and perform operations on them in order to implement management policies. All the interactions between a manager and an agent are realised through a network management protocol, which essentially conveys the parameters of operations on objects and returns the results and/or errors. The managed objects in an agent emit notifications according to the operation of the underlying resource they model. These notifications may be forwarded to interested managers. Thus the manager to agent communications is initiated by the manager for all operations apart from the forwarding of notifications. The separation between manager and agent roles serves only the purpose of the model. It is not strong in engineering terms as many applications may be in both roles. This is particularly true in hierarchically organised management environment such as the Telecommunications Management Network (TMN). 5

6 Management Terminology Manager Managing System Management system Workstation Agent Managed System Managed Node Network Element Management Application Operations System There are many terms that are used interchangeably with respect to the roles of the management model. The terms manager and agent are used in most cases while the following terms may be also used: In the OSI management model, the terms managing and managed system are commonly used to denote the manager and agent roles respectively. Occasionally, the term managing application is also used to denote a manager. In the Internet management model, the terms management station and managed node or managed device are used for the same purpose. In the TMN model, the terms workstation and network element are used for much the same purpose. Finally, the term management application is a generic term that describes any application with management responsibilities, in manager, agent or both roles. This is the role of most TMN Operations Systems. 6

7 Elements of Open Communications Management Structure of Management Information + Formal MIB Specifications + Management Protocol + Common underlying protocol stack = Open interoperable framework for multi-vendor, multi-technology management systems Open Interoperable Management The purpose of a well defined management model and a set of specifications for the management protocol and management information related to all types of network resources is to provide an open, interoperable management interface to those resources. In this case, network management technology is vendor independent with network elements and managing applications from different suppliers able to interoperate. The exact requirements for open interoperable management are: A well known set of rules for dictating the structure, definition and naming of management information - this is known as the Structure of Management Information The former provides the framework to formally specify information related to the management of a particular network resource - the formal MIB specifications. A common set of rules for communicating management information between management applications - the management protocol A common agreed set of protocols that support the transport and presentation needs of the management protocols- the underlying protocol stack. If these are common, open interoperable management is possible independent of the vendor and implementation technology. 7

8 Managed Objects Abstractions of Physical or Logical Resources to be managed Encapsulate the underlying Real Resource Enable manipulation of Real Resource through well defined operation Exhibit behaviour at the object boundary - hiding resource access details Managed objects are abstractions of the physical or logical resources to be managed and can be thought as encapsulating the real resource. This means that access to the real resource for the purpose of management is performed through the managed object, which hides the real resource access details. The concept of managed objects is borrowed from the object-oriented specification and design principles and brings a common method of access through a common set of operations, also termed methods. That way, the associated real resource behaviour to management operations is only exhibited at the object boundary, completely hiding any internal realisation aspects. Managed objects can be used to model physical entities such as multiplexors, concentrators etc. and logical ones such as virtual circuits, associations etc. 8

9 The Managed Object Abstraction ABSTRACT VIEW operations notifications MO RR CONCRETE VIEW operations notifications MO interaction RR The figure above shows the view of a real resource through a managed object for the purpose of management. The interaction with the real resource, which is always implementation specific, is hidden but its manipulation is enabled through a set of abstract operations on the managed object. The associated behaviour is exhibited through the attributes (information) the managed object contains, the actions it may perform and the notifications it may emit. Operations on the attributes and actions are always initiated through well defined methods that operate at the object boundary to trigger its behaviour (encapsulation). In an actual implementation of a management agent, the relationship between the managed object and the associated real resource is shown in the second part of that figure. The managed object is a data structure in engineering terms while the real resource may be the contents of a piece of memory in the operating system's kernel, a communications board etc. The view though for the purpose of management is always through the managed object that encapsulates it and triggers the associated behaviour. For example, a "delete" operation on a virtual circuit managed object may delete the actual virtual circuit, according to the specified behaviour in the managed object definition. 9

10 Managed Objects for Support Not all Managed Objects (MOs) represent resources Some exist to support the needs of the management system itself E.g.: MOs to control notification, logging and access control etc Not all objects in a management system relate to managed real resources. There is a need for managed objects which are needed by the management system itself. As an example, the forwarding of notifications as event reports should be controlled by managing applications. This can be achieved through special managed objects which will enable control to the level of reporting according to criteria that could be altered by the managing system. The benefit of making these managed objects as well is that they can be configured and manipulated remotely using exactly the same mechanism as for those that model real resources. These objects are usually termed management support objects and are used, in varying degrees, by all the management models. The most common support objects are those used for event reporting and logging, access control and workload monitoring (metric objects). 10

11 The Management Information Based (MIB) A virtual information store of all managed objects A highly distributed object-oriented database Dynamic database - MOs are live entities reflecting the current state of the real resource they encapsulate Each application in the agent role handles part of the MIB, i.e. the agent MIB The Management Information Base (MIB) is a virtual information store that comprises all the management information in a managed network. It is in essence a highly distributed object-oriented database of dynamic nature, as the objects reflect the state and operation of the underlying real resource. The term management information base is also sometimes used to describe the portion of the global information base handled by a particular application in agent role. The same term is also used to describe a collection of specification of management information (objects) pertaining to the management of a particular protocol or type of network element. For example, one may refer to the ATM Element MIB meaning the specification for the management of ATM network elements. 11

12 Access Method: The Management Service/Protocol Provides access to Management Information Enables distributed management applications to exchange information Defines a set of operations that can be applied to MOs Management Protocols are typically application layer protocols The management protocol enables the communication between applications in manager and agent roles in a distributed environment. This communication enables the interactions that realise specific management policies. The management protocol carries essentially the parameters of operations to be applied to managed objects and the results and/or errors. It also carries the information of notifications emitted by managed objects when the former are forwarded to interested managers. Since the management protocol defines the operations on managed objects, it is dependent on the set of rules that govern the structure of management information in a particular model. This means that the two have to be defined in accordance and it is not possible to interchange one management protocol for another from a different model, though they may appear similar in functionality. For example, aspects such as naming, the parameters of operations, the structure of results and errors have some similarities in different management models but are different enough to restrict the scope of application within that model. All management protocols are application layer protocols in the sense that they need presentation facilities and enable manipulation of management information related to all the protocol layers in a network. There may however be protocols specific to the management of a particular layer through applications which have a restricted view - these are termed layer management protocols as opposed to the systems management protocols which provide a global view. 12

13 Management Protocol Operations Read: Retrieve MO state for monitoring/awareness Traverse or Discover: Retrieve in Bulk, Check the existence or MOs Write: Change to Configure and Control Action: Imperative command to control MO Create, Delete: Configure and Control Notify: Reporting exceptional events All the management protocols have in essence a set of operations which are similar as they enable to manipulate managed objects remotely. These operations are broadly the following: read which enables to read the information (attributes) of managed objects, providing the capability of monitoring and obtaining management awareness traverse or discover which enables to find out dynamically which objects are supported by a management agent; it may also be used to retrieve management information in bulk write which enables to change the information (attributes) of managed objects, possibly triggering some associated behaviour action which enables to perform an imperative action, affecting possibly the associated resource create which enables to create a managed object e.g. a table entry or other delete which enables to delete a managed object, again possibly affecting the associated resource notify which enables an agent to notify an interested manager that some exception happened Not all of these operations are present in all the management protocols, but the basic ones i.e.. read, traverse/discover, write and notify are. 13

14 The ADI Management Model Management activities can be seen as having three phases: Awareness through read, discover, notify Decision making the Management Intelligence Implementation: intrusive management/control through write, actions, create delete All management activities can be thought as having three phases according to the ADI model: awareness - the phase in which awareness about a management problem is generated decision - the phase in which a decision is made for some action according to the management policy to be carried out implementation - the phase in which the decision is actually implemented In terms of the manager-agent model, awareness is acquired by managers through event reporting or polling mechanisms, the decision phase reflects the application's intelligence and the implementation is achieved by performing operations on managed objects (write, action, create, delete). 14

15 Management Communication Paradigms Connection-Oriented Guarantees reliable delivery, requires connection set up e.g. OSI CMIP/S Connectionless Management applications provide reliability through retransmission e.g. Internet SNMP Connectionless with guaranteed delivery No connection set up, a RPC protocol undertakes retransmission e.g. OMG CORBA There are three different communication paradigms that may be used by different management models to support the management protocol in communicating management information: connection-oriented - in this case the management traffic is guaranteed reliable delivery offered by a connection-oriented transport protocol; connection establishment needs to take place before any instance of actual management communication connectionless - in this case management traffic may be simply lost, it is up to the management applications to provide reliability through retransmission connectionless with guaranteed delivery - in this case communication is connectionless but an underlying application protocol undertakes retransmission; this is the case with Remote Procedure Call based management protocols Each of the above mechanisms has its advantages and drawbacks. The first provides reliability through complex retransmission mechanisms that take into account the state of the network as is the case with current sophisticated transport protocols (OSI TP4, Internet TCP). Connection management is needed though to avoid connections staying open unnecessarily as they may tie up network resources and also to avoid the burden of establishing them too often. An application knows immediately that connectivity is lost. The second mechanism has the advantage of leaving retransmission to the management applications which may have a better global view of the network than a transport protocol and avoiding connection establishment. The problem though is that sophisticated retransmission schemes are very difficult to implement and they duplicate transport layer functionality. Finally, the third has the advantage of being easy to program because of its RPC nature but usually the retransmission schemes used are simplistic; this method is best for highly reliable environments e.g. LAN, MAN etc. 15

16 Management Application Paradigms Event Driven Agents notify exceptions, notifications are configurable by management, e.g. OSI Management Polling based Manager detect changes through periodic polling, e.g. SNMP Mixed approaches are also possible Trade off between management traffic, timeliness and complexity of management applications There are two fundamental approaches to network management: an event driven approach and a polling one. They may be both used by to make management stations aware of extraordinary events. With the event-driven approach, it is the responsibility of the management agent to send an event report to a management station when an extraordinary event occurs, e.g. such as a link going down. Of course this means that after the event the node is still operational (i.e. has not crashed) and reachable. The advantage of such an approach is that it provides an immediate notification. There are disadvantages though: if many extraordinary events occur, a lot of effort may be spent in producing the event reports. With the polling-based approach, the managers periodically poll the agents to know how things are going. The obvious question though is what the frequency of polling should be: if the interval is too small, too much network bandwidth is wasted while if the interval is too long, response to problems needing attention urgently may be slow. The major advantage of this approach lies in the fact that management agents are very simple, exercising an "access-upon-management-request" regime with respect to the real resources they handle through managed objects. Mixed approaches are also possible which could be characterised as event-directed polling. There can be many schemes in between the two extremes, it all depends on the number of notifications that are defined in the management information model for a particular resource. Depending on the level of event-reporting, different requirements on the complexity and power of the managed and managing systems are imposed by these models. In the polling model, agents are very simple and managers quite complex in order to tailor the polling frequency, while in the event-driven model agents are much more complex while managers can concentrate on the management policies they implement. 16

17 The Global Picture Many manageable network elements, services and users Many Management Applications effecting policies A M-N relationship between them Flat or Hierarchical Management System Organisation In a management system related to the management of a large enterprise network, there are a lot of agents providing management capabilities to the real resources that need to be accessed for the management policies to be met and fewer managers implementing those policies. The relationship between managers and agents is many-to-many as the same managed objects may be accessed by different managers for different or even the same reasons. In general, there will be more than one application in a given system that has "manager" (as opposed to "agent") capability. There are essentially two reasons why multiple managers might be required. The first is that it may be desirable to partition the system for management purposes, either physically or logically, based on factors such as the ownership of equipment, the distribution of (human) management responsibility, or the capacity of a particular management station. The second is that it may be desirable to provide spare management capacity (redundancy) to cater for component failures or system expansion. The general structure of the management applications realising the management policies can be flat or hierarchical. 17

18 Centralised Management Organisation manager to agent relationship network element (agent) management station (manager) In this model there is only one centralised management station above the network element level where there exist agents for all the managed elements. This is the typical model of private network (LAN/MAN) management. In telecommunications environments until now is not uncommon to have management stations dedicated to one managed network element. 18

19 Flat Management Organisation manager to agent relationship network element (agent) management application (manager) In this model there is only one level of managers above the network element level where there exist agents for all the managed elements. Those managers may communicate with each other to agree on policies and they may even offer an enhanced information model to each other in terms of management capabilities. For example, a manager from one domain may need to remotely monitor objects within agents in another domain. In this case, it may request the manager of that domain to do that on its behalf and receive notifications upon important changes only. Typically, distribution in the flat model is according to geographical (different subnetworks) or functional (Fault, Configuration, Accounting, Performance, Security - FCAPS) considerations. 19

20 Hierarchical Management Organisation manager to agent relationship network element (agent) management application (manager-agent) In this model there may exist many levels of managers, or better, management applications as most of them are both managers and agents: they offer an agent interface to peer and superior managers and they may act themselves as managers with respect to peer or subordinate agents. In such a hierarchy, there are agents only at the lowest level and hybrid units in the other layers, while managers only are also possible. The advantage of such an organisation is that management responsibilities and policies may be organised in such a way as to build on those offered by the layer below. Layered information models offer also the advantage of increased abstraction and scope for higher layers. Such a hierarchical management system organisation is suggested by the ITU-T Telecommunications Management Network (TMN). Hierarchical separation of concerns is according to element, network and service management. Within each layer, there is also horizontal separation following functional (FCAPS) considerations. 20

21 Integration of Foreign Agents through Multi- Stack Managers M API stack1 stack2 A1 A2 element1 element2 Manager to Agent relationship Interworking between manager applications and foreign agents that do not conform to the agreed management model can be achieved by solutions that can be classified into two broad categories: integration in the manager end; and integration in the agent end of the manager-agent model. The integration in the manager end means that one accepts the diversity in the supported technology by managed elements and tries to provide element management applications that understand the different underlying information models and access mechanisms. This approach is often referred to as dual stack manager, since these applications will need to understand both the OSI and Internet management models. However, such an approach is suspect because it is difficult to conceal which model the managing application deals with since both the underlying information models and access mechanisms have important differences. For example, the nature of objects and the naming schemes are different in the two models. This is also the case with respect to the supported communication and access paradigms. Of course, this does not mean that such an approach is not feasible but simply that integration cannot be seamless, increasing significantly the development effort and investment for dual manager applications. 21

22 Integration of Foreign Agent through Protocol Adaptation M A1 ICF A2 application-gateway ICF: Information Conversion Function Manager to Agent relationship element The gateway approach provides the most promising solution for integrating foreign agents. In this, an application acts as a gateway (proxy or adapter are two other terms often used ) for one or more agents, exporting converted information models and providing service conversion from one access method to the other. The Information Conversion Function (ICF) realises the mapping between the information model in the standard framework, e.g. the TMN, to the information model in the foreign framework. Note that this assumes that the foreign element provides a management interface with the functionality required by the standard framework. 22