Temporal network management model Concepts and ... · Temporal network management model Concepts...

Temporal network management modelConcepts and implementation issues

Theodore K. Apostolopoulos*, Victoria C. Daskalou

Department of Informatics, Athens University of Economics and Business, 76 Patission Street, 104 34 Athens, Greece

Received 15 March 1996; accepted 2 August 1996

Abstract

Networks grow in scale and become more complex and heterogeneous as well. A lot of research effort is focused on the topic of networkmanagement. This is because nowadays a network management system is a vital component of any network installation. In this paper, wepropose an extended network management information model that includes the time dimension. This view leads us to adopt a temporal datamodel as the underlying information model. Moreover, the services provided by this model, as well as the architecture supporting them, arepresented. In addition to that, we have implemented a prototype incorporating the proposed network management view. The description ofthe prototype is also presented in this paper.q 1997 Elsevier Science B.V.

Keywords:Networks; Time dimension; Temporal data model

1. Introduction

Computer and telecommunication networks are becom-ing one of the driving forces for the progress of economicand social life. These networks are not only growing in scalebut are becoming more complex and heterogeneous as theysupport multivendor applications on a variety of underlyingtransmission facilities. Such expansion and complexity haveinduced growing challenges to efficiently manage the net-work elements according to the network providers’ andusers’ objectives and expectations. As a result, a lot ofresearch effort has gone in to solving problems arising inthis area and establishing standards that could be usedacross a broad spectrum of product types (e.g. hosts, routers,bridges, switches, telecommunication equipment) in a multi-vendor environment. In response to the need for standardstwo main efforts are underway: one from the InternationalOrganization for Standardization (ISO), namedOSI SystemsManagement, and another from the Internet EngineeringTask Force (IETF), namedSimple Network ManagementProtocol’s (SNMP) family.

The huge size and the high complexity of such networksdictate also the use of automated network managementsystems that could help the network engineer to efficientlymanage the network elements. The general architecture of a

network management system (Fig. 1) is based on a client–server architecture, where the server is called the agent,while the client is the managing process. Each networkcomponent has an agent which maintains a local manage-ment information base (MIB), and can communicate withthe management application residing in the networkmanagement station through a network management proto-col such as the SNMP [1] or CMIP protocols [2]. The MIB isa conceptual representation of the network resources thatprovides the network manager with the means to observeand control the current behaviour of network elements. Theinteraction between the management application and themanagement agents admits the retrieval and/or update ofthe MIB information in a way that enables the imple-mentation of various network management functions, frommonitoring the state of the network to changing the networkconfiguration.

Time is an attribute of most real world phenomena, and inthis paper we address the issue of time as an attribute ofnetwork management information. More precisely, weincorporate the temporal dimension in the managementinformation model proposed by the IETF, as it is describedby SMI [3]. This new temporal network management infor-mation model was built upon a temporally ungrouped his-torical data model—TRDM, as it has been named in [4]—which was proposed in [5]. The core of the proposedmanagement information model is theTemporal Manage-ment Information Base (TMIB), a conceptual representation

Computer Communications 20 (1997) 694–708

COMCOM 1237

0140-3664/97/$17.00q 1997 Elsevier Science B.V. All rights reservedPII S0140-3664(97)00063-7

* Corresponding author. Tel.: +30 1 8203173; fax: +30 1 8226204; e-mail:[email protected]

of the diachronic behaviour of network resources. The con-cept of a temporal network management information modelhas already been applied to the areas of performance andconfiguration management, as is described in earlier works[6,7].

The temporal network management model and the TMIBdesign are presented in detail in Section 2. The architectureof the network management application that implements theproposed model and the network management services aredescribed in Section 3. In Section 4 we present the archi-tecture and the main operations of the prototype we haveimplemented, while in Section 5 we summarise the mainpoints of our approach and we discuss possible applicationsof the proposed model.

2. The temporal network management informationmodel

2.1. The concepts

Two different information models were defined in order

to represent the network management information: one fromthe ISO [8] and another one from the IETF [3]. Bothmodels are centred around the so-called managed objects,which represent an abstraction of network resources andform the management information base (MIB). Theinformational model of the ISO is fully object-oriented,with managed objects being instances of managed objectclasses. The IETF’s model is less complex where managedobjects can be classified in two types:scalar objectsandtable objects. The table objects are two-dimensionalarrays of scalar objects and at a given time they consistof multiple row entries. The scalar objects are simple MIBvariables which can have at most one instance at a giventime.

Managed objects that are defined, based on either of thesetwo models, have to provide resources for all functionalareas of network management. The requirements of thefunctional areas are quite different to a large extent andnot yet well understood [9]. In order to specify the type ofmanagement information that is necessary for each of thefive functional areas we proposed a generic managementinformational model (Fig. 2). This model tries to classifythe management information contained in the MIB accord-ing to the following three criteria:

1. the intended use of the network management information2. the frequency that management information variables

change their values3. the temporal dimension of the management information.

The first criterion introduces a concept closely related tothe type of functions included in a network managementapplication in relation to the types of data that they need.According to this criterion, the management data can beclassified into three types [10]:

• Sensor data: these data represent the current network

Fig. 1. Network management architecture.

Fig. 2. The proposed network management perspective.

695T.K. Apostolopoulos, V.C. Daskalou/Computer Communications 20 (1997) 694–708

‘health’, in terms of its operational state. More precisely,they are the raw information received by the networkmonitoring and retrieval process.

• Control data: these data capture the current setting of thenetworks tuning parameters (for example, the routingtable) that are used mostly by control applications.

• Structural data: these data describe the physical andlogical construction of the network. That is, informationrelated to the network topology, the configuration ofnetwork resources, the user description records, etc.

By taking into consideration the second criterion wedefine a higher level abstraction of the management infor-mation, which adopts two broad classes of objects:

• Quasistatic objects, which describe the current networkconfiguration (e.g. the number of host interfaces, therouting table, etc.); their values do not change veryoften.

• Dynamic objects, which are related to network events(e.g. the transmission of packets); their values changevery often during time.

The third criterion we have adopted is related to the timedimension of the management information required by dif-ferent applications. For example, a network managementapplication concerning real-time performance monitoringhas radically different requirements, as far as the requireddata are concerned, from a network management applica-tion concerning the collection and usage of long-termstatistical data. The main difference lies in the time horizonrequired by both applications. So, we have to consider net-work management as a concept that incorporates temporalinformation in relation to the type of network managementapplication. We can distinguish three regions for the timeparameter related to network management operations. Thereal-time regionwhich is related to real-time operations, thetime non-critical regionwhich is related to operations thatare based on information in a given time window and finallytheglobal time regionwhich is related to operations that arebased on long-term information. Usually, the different timeregions reflect the difference in the point of view of variouspeople involved in a system (for example a networkengineer, people with financial responsibilities etc.). Itshould be clear that the time parameter has a meaningdirectly related to the type of application, and not anabsolute meaning.

According to this point of view any network managementapplication has to be defined in a suitable area, described byspecific values of the three parameters defined above. Forexample, taking into account the five OSI functional areas,we can have the following considerations as far as the usedsubspace is concerned:

• Configuration management: for example, a simple con-figuration management tool that provides only a centralstorage for generic network information, e.g. name ofdevices, system physical location, system administration,

etc., network address assignments and other pertinent datafor network elements, uses a subspace defined asglobaltime 3 quasistatic information3 structural data. Amore complex configuration management tool, that auto-matically gathers and stores information from all manageddevices, that compares the system current running con-figuration with control data stored in the tool and enablesthe user to change the running configuration of the device,uses a subspace defined astime non-critical3 quasistaticinformation 3 control data.

• Performance management: for example, a performancemanagement tool that measures the current network uti-lisation and compares its value with a user-definedthreshold in order to generate an alarm uses a subspacedefined asreal-time 3 dynamic information3 sensordata.

• Fault management: for example, a fault managementtool that checks the number of packets received inerror for every interface of managed routers in an enter-prise network, so as to generate an alarm when the valueincreases up to a predefined level, uses a subspacedefined asreal-time 3 dynamic information3 sensordata. A fault management tool that checks the operatingand the administrative status of every interface of allmanaged objects in an enterprise network in order todetect an interface failure uses a subspace defined asreal-time 3 quasistatic information3 sensor data.

2.2. The model

The temporal management information model proposedin this paper represents the past, current and future networkstate in a temporal management information base, TMIB.This new information model uses as a basis the IETF’smodel and it extends it in order to include the temporalnature of the management information. The incorporationof the temporal dimension in the network managementinformational model admits the adoption of a temporal data-base model. This model is augmented by the appropriatenetwork monitor procedures in order to gather the historicalnetwork behaviour and store it in the TMIB, and by theappropriate network executors in order to change the currentnetwork state. Moreover, it is augmented by prediction andsimulation procedures in order to provide information aboutthe future behaviour of network resources. As a conse-quence, the TMIB is a temporal database whose design istailor-made for network management.

The TMIB is the core of a network management system,as it provides the interface between the network adminis-trator and all the functions of network management. Oneimportant parameter of the TMIB design is to have the net-work administrator interact solely with the database, byusing a temporal query language, so that from the user’spoint of view the TMIB embodies the network diachroni-cally. As a result of this TMIB design, whenever the net-work administrator wishes to make changes in the network

696 T.K. Apostolopoulos, V.C. Daskalou/Computer Communications 20 (1997) 694–708

objects, such as changing the routing scheme, the adminis-trator updates the appropriate variables in the database byusing a temporal replace statement.

The adoption of a temporal database model is quite adifficult task because over the course of the past decadevarious relational data models have been proposed inorder to include the temporal dimension. Generally, thesedata models extend the standard relational data model byincluding a temporal component. This incorporation of thetime parameter has taken a number of different forms.Among these we can distinguish two main approaches: theincorporation of the temporal dimension at the tuple level(by timestamping each tuple) or at the attribute-value level(by including time as part of each value). For the firstapproach, the termsfirst-normal-form (1NF) relations ortemporally ungrouped(TU) data models are also used.For the second approach, the termsnon-first-normal-formrelations ortemporally grouped(TG) data models are alsoused [4].

Among the temporally ungrouped data models we candistinguish TRDM, a temporal database model presentedin [5]. The main advantage of this model is its querylanguage, TQuel (Temporal QUEry Language), which canbe used for the manipulation of temporal databases. TheTRDM provides for two types of historical relations. One,called aninterval relation, is derived from a standard rela-tion through the addition of two temporal attributes,valid-from andvalid-to, both of whose domains are sets of timesT. The values of the nontemporal attributes of a tuple in sucha relation are considered to be valid during the beginning ofthe interval of time starting at thevalid-fromvalue and end-ing at, but not including, thevalid-to value. This intervalthus denotes thelifespanof the tuple. The second type ofrelation, anevent relation, is defined by extending a stan-dard relation by a single temporal attributevalid-at, indi-cating the time instant that a specific event took place.

According to the new temporal management informationmodel proposed in this paper, the TMIB is a collection oftemporal table objects that represent a diachronic view ofmanagement information. There are two cases: according tothe first case, a TMIB table consists of a set of explicitcolumnar management information objects and of twoimplicit time objects. These time columnar objects,valid-From andvalidTo, represent the time interval [validFrom,validTo) during which the state of the management

information is valid. We call this type of object an intervaltable. According to the second case a TMIB table consists ofa set of explicit columnar management information objectsand of one implicit time objectvalidAt. This time objectrefers to the instant that an event described by the explicitcolumnar objects took place. We call this type of object anevent table. The MIB table objects in every group aremapped onto temporal table objects, with their columnarobjects representing the explicit non-temporal columnarobjects of the derived TMIB table. Moreover, the scalarobjects of each group are mapped onto the explicit non-temporal columnar objects of TMIB tables. The values ofthe implicit time columnar objects, e.g.validFrom, validToandvalidAt, represent the time at the manager site. More-over, values of explicit columnar objects that are derivedfrom MIB objects related to time, for example in MIB-II[11] the sysUpTime, ifLastChange, etc. and in SNMPv2M2M MIB [12] the snmpEventLastTimeSent, etc., repre-sent the time at the agent site in a highly centralized archi-tecture and/or at the intermediate manager site in adistributed architecture. This mapping is designed in away to permit the representation of all the SNMPv1 MIBsand new SNMPv2 MIBs, such as SNMPv2 M2M MIB, thatinclude objects related to time at the agent or at the inter-mediate manager level, in TMIB tables and give an opencharacter to our model.

Taking into consideration the criterion that classifies thenetwork management information into quasistatic anddynamic managed objects we define two types of TMIBtables, quasistatic and dynamic TMIB tables. The non-temporal columnar objects of a quasistatic TMIB tablerepresent only the quasistatic part of the correspondingMIB table or quasistatic scalar objects of MIB groups.Dynamic TMIB tables represent only dynamic managedobjects. The non-temporal columnar objects of a dynamicTMIB table represent only the dynamic columnar objects ofthe corresponding MIB table or only dynamic scalar objectsof MIB groups. The explicit columnar objects of a dynamicTMIB table represent delta values of the corresponding MIBobjects.

An example of a quasistatic TMIB table representing thehistory of a quasistatic part of the ipRouteTable for router‘pegasus’ is depicted in Fig. 3. For example, the row withvalues {pegasus, 193.92.156.0, 1, 3,…, 193.92.96.95,…,100, 120} means that during the past time interval [100, 120)

Fig. 3. Part of the quasistatic ipRouteTable TMIB table object.


the routing entry for the destination 193.92.156.0 had thevalues mentioned in this TMIB table row. In this table, thecurrent management information, that is the routing entriesthat are still valid, has a value equal tofor the validTocolumnar object.

An example of a TMIB table representing the history ofsome scalar dynamic objects of the ip group of the host‘phaethon’ is depicted in Fig. 4. Each row of this table repre-sents the delta values of the dynamic objects for a givenmanaged node during the interval [validFrom, validTo).

An example of a part of the tcpConnTable TMIB objectof host ‘dias’ is illustrated in Fig. 5. In this figure we can seethe history of different states of the TCP connection in host‘dias’ between the tcpConnLocalAddress¼ 193.92.99.60,tcpConnLocalPort ¼ 21 and tcpConnRemAddress¼193.92.99.80, tcpConnRemPort¼ 3223.

According to the nature of the information included in thetwo categories of TMIB tables the operations that can beperformed in each category are quite different. The infor-mation included in quasistatic TMIB tables can be the argu-ment in a retrieve, append, delete or replace databaseoperation, while the information included in dynamicTMIB tables can be an argument only in a retrieve opera-tion. The TMIB model is illustrated in Fig. 6. In the lowerlayer we can see the network monitors, which use pollingprocedures in order to gather and store the historical net-work management information in the quasistatic and dynamicTMIB tables, and the network executors, which are used inorder to implement the append, delete and replace data-base operations in the current network management

information included in quasistatic TMIB tables. In themiddle layer we can see the dynamic and quasistatic TMIBtables that provide the historical (past and current) manage-ment information. Finally, in the upper layer we consider anumber of prediction and simulation algorithms that provideinformation about the future behaviour of networkresources.

Finally, we have to consider the issue of choosing thevalue of the polling interval used by network monitors inorder to gather and store the historical management infor-mation in dynamic and quasistatic TMIB tables. This choiceapparently depends on various factors such as the number ofagents, the network delay, the processing time implementingthe polling mechanism, etc. The values that are appropriate fora given configuration have to be determined in practice. In thesequel, we just give some indications and constraints that thechoice of the polling interval has to satisfy.

The polling takes place in a non-blocking way, that is theprocess first issues the whole number of requests and then itwaits for the replies. In this way the network latency doesnot play a crucial role. LetT be the value of the pollinginterval in seconds and letdi be the time required to processthe request/response for theith agent. The last quantitydepends on the processing power of the workstation onwhich the polling process is running, on the specificTMIB structure (how many MIB objects are required perrequest), and on the number of requests/responses processedat the same time. For a given number of agentsn let

d¼ max{di} i ¼ 1,2, :::n

Fig. 4. Part of the dynamic scalar TMIB table object of the ip group.

Fig. 5. Part of the quasistatic tcpConnTable TMIB table object.


Thus by imposing an upper boundUBcpu of the CPU utilisa-tion for the polling process we have that the following musthold:

n·dT

, UBcpu

Let RQ and RSbe the total size in bytes of a request andreply respectively in every poll, and letC be the capacity ofa virtual line used by the network management station tocommunicate with each managed node separately.Obviously,C depends on the topology of the network andindirectly on the number of agentsn. By imposing an upperboundUBnet for the network utilisation dedicated to networkmanagement we have that it must hold:

(RQþ RS)·8T 3 C

, UBnet

Let NDB andRDBbe the average number of rows insertedin the TMIB after a poll and the size of each row in bytes,respectively. Imposing an upper boundUBdb in bytes on thedaily added amount of data in the TMIB, we have that itmust hold:

n24·3600

TNDB·RDB, UBdb

Note that the type of MIB, quasistatic or dynamic, deter-mines that the value ofNDB varies between 0 and 1.

For a given implementation the polling interval must bechosen so as to satisfy all the above constraints. More pre-cisely, the bounds must be set not as single values but aspairs of values, for quasistatic and dynamic objects for agiven configuration and TMIB respectively. The fulfilment

of the above constraints leads to the minimum value of thepolling interval that can be selected. In practice, the pollinginterval may be any number greater than or equal toTdepending on the nature of the application and the desiredaccuracy of network management information.

3. Architecture and services

In this section we will present the architectural model thatincorporates directly the proposed network managementperspective. We define network management applicationobject (NMAO) as an object consisting of data and proce-dures. Each NMAO is referred to a specific network element(simple object) or network (aggregate object), it is physi-cally located in a specific host and it is totally independentof any other NMAO. It has the responsibility of collectingnetwork management information for all the network com-ponents and/or the networks belonging to the area of respon-sibility of this particular object. Each NMAO maintains aTMIB describing the network state. More precisely, the net-work state is mapped to a generic temporal database schemathrough a preselected and user-adjustable use of filters. Byusing these filters the NMAO can choose the right resolutionas far as the time (how often) and/or the space (what infor-mation) is concerned.

As we have already seen, the TMIB structure is an exten-sion of the MIB structure. It is implemented through a data-base approach that adds some new attributes, namely thetime attributes, but maintains the MIB semantics. In thisway each NMAO database can communicate with other

Fig. 6. The type of network management information contained in the TMIB.


NMAO databases following the common TMIB semantics.The NMAO databases may cooperate among themselves bynegotiating what information they should exchange and bydeciding how they will exploit the results. In this way, thenetwork management of a generic internetwork may takeplace through the cooperation among completely autono-mous systems. This approach may be implemented byusing a distributed database model. The use of a local data-base in every NMAO saves communication bandwidth incollecting network management data, at the expense of nothaving available a central global state of the system. Theabove described concept is depicted in Fig. 7.

All the well-known techniques and protocols borrowedfrom the distributed databases era may be used in order toachieve a consistent global state of the overall networkmanagement application. For example, the two-phase com-mit protocol (2PC) may be used to modify routing tables in away that ensures atomicity. Another example concerns thedata replication concept found in the distributed databaseapproach. Consider the case of problems arising from tem-poral network disconnections. They can be minimised byusing appropriate network management tools for restoringnetwork connectivity. In order to do so, it is necessary to beable to access the appropriate MIB information. This infor-mation can be available through data replication.

By using the aforementioned temporal database modelwe can implement basic network management services astemporal database operations. In what follows TQuel hasbeen adopted as the data manipulation language. In thesequel, we will consider the ‘retrieve’ operation only. Wewill describe the incorporated extensions as far as the timecomponent is concerned. The other TQuel operationsbehave similarly. A skeleton for the TQuel retrieve state-ment that we use with our model can be the following [5]:

retrieve target_list

valid clausewhere clausewhen clause

The target list specifies the specific columnar objects ofthe retrieved rows and thewhereclause specifies constraintsthat apply on the values of the explicit columnar objects inorder to restrict the underlying rows that participate in thequery. Thewhenclause is the time analogue of thewhereclause: it specifies a predicate on the implicit time columnarobjects of the underlying rows that must be satisfied forthose rows to participate in the remainder of the processingof the query. Finally, thevalid clause serves the same pur-pose as the target list, specifying the value of an attribute inthe derived table; but in this case, the values of the implicittime columnar objects of the derived row are being speci-fied. Note how easily the network engineer can acquire anduse network management information.

In order to present the retrieve statement we give someexamples of the queries that the network manager couldissue. More precisely, with regard to the representation ofthe part of the quasistatic TMIB table object in Fig. 3, wepresent a number of queries in order to discuss the TQuelretrieve statement. First, the two examples of QUERY 1retrieve the current state of the routing table of the host‘pegasus’, as a whole or as a specific part. Then, the twoexamples of QUERY 2 retrieve the state of the routing table(as a whole or a specific part) of the host ‘pegasus’ at aspecific past time span. Moreover, the two examples ofQUERY 3 retrieve the history of the routing table (as awhole or a specific part) of the host ‘pegasus’, during apast period of time. Finally, the example of QUERY 4 isused to retrieve the time when specific changes to the valuesof MIB objects were detected by the polling mechanism.

QUERY 1

(a) Which is the current routing table of node ‘pegasus’?

range of R is ipRouteTableretrieve (R.all)where R.hostID ¼ ‘pegasus’when R overlap present

Fig. 7. Distributed architecture of network management application objects.


(b) Which is the last value of the ipRouteNextHop for theipRouteDest ‘193.92.156.0’ of node ‘pegasus’?

retrieve (R.ipRouteDest,R.ipRoute-NextHop)where R.hostID ¼ ‘pegasus’ andipRouteDest ¼ ‘193.92.156.0’when R overlap present

QUERY 2

(a) Which was the routing table of node ‘pegasus’ at noonon May 5, 1995?

retrieve (R.all)where R.hostID ¼ ‘pegasus’when R overlap |12 PM May 5, 1995|

(b) Which was the value of the ipRouteNextHop for theipRouteDest ‘193.92.156.0’ of node ‘pegasus’ at noon onMay 5, 1995?

retrieve (R.ipRouteDest, R.ipRoute-NextHop)where R.hostID ¼ ‘pegasus’ andipRouteDest ¼ ‘193.92.156.0’when R overlap |12 PM May 5, 1995|

QUERY 3

(a) Which was the routing table of node ‘pegasus’ duringMarch 1995?

retrieve (R.all)where R.hostID ¼ ‘pegasus’when R overlap [March 1995]

(b) Which was the value ipRouteNextHop for the ipRoute-Dest ‘193.92.156.0’ for node ‘pegasus’ during March1995?

retrieve (R.ipRouteDest,R.ipRouteNextHop)where R.hostID ¼ ‘pegasus’when R overlap [March 1995]

QUERY 4

When was it detected by the management application thatthe ipRouteNextHop for ipRouteDest ‘193.92.156.0’ fornode ‘pegasus’ changed its value to ‘193.92.98.9’?

retrieve (R.ipRouteNextHop)valid at begin of Rwhere R.ipRouteDest ¼ ‘193.92.156.0’and R.ipRouteNextHop ¼ ‘193.92.98.9’

The proposed view of the network management concept,already described above, can be implemented in a layeredstructure in a control plane as is depicted in Fig. 8. EachNMAO consists of the following layers and elements.

3.1. Layer 1

This includes the SNMP protocol. This layer provides theraw service of transmitting network management informa-tion based on the SNMPv1 primitive operations get-request,getnext-request, set-request, get-response and trap. The net-work management protocol that can be used is not limited toSNMPv1. The SNMPv2 [13,14] can also be use in this layer.The key enhancements of SNMPv2 are that we can supporta distributed architecture and manage a set of intermediatemanagers, new protocol operations, as getbulk-request andinform-request, and specific security services as privacy,message authentication and access control. The CMIP orany other network management protocol can also be usedfor this type of service.

3.2. Layer 2

This provides three types of service.Type 1 provides the service of changing/updating the net-

work management information and is based on the SNMPprimitive service set-request. This service concerns theoperations used for configuration changes in order to main-tain the prescribed levels of performance and for activatingrestoring mechanisms in the event of host failure or mal-function.

Type 2 provides a monitoring service. This service can befurther subdivided into a real-time performance monitoringservice and a real-time network status monitoring service.

Type 3 provides the service of collecting and storing theMIB information.

Fig. 8. The proposed layered architecture.


On the basis of the services already defined we considerthree generic service elements lying on the top of theseservices. We name them strategic applications service ele-ment, control applications service element and monitoringservice element. These service elements do their job basedon the layer 2 services and they may be distributed or not.

4. Description of the prototype

In order to implement the above described networkmanagement concepts, we developed a prototype thatincludes some of the proposed characteristics. In the sequel,we will describe the main characteristics of the prototype aswell as our experience from its usage.

The prototype was implemented in a DEC 3100 work-station at the beginning, and has now been transferred to anAlpha workstation. The focus was on the MIB II, butgeneralisation (by adding other MIBs) can easily be derived.The network management protocol used was the SNMPprotocol. In order to acquire network management informa-tion we used the polling approach with polling perioddependent on the type of the requested information and onthe number of managed nodes.

Apart from the TMIB implementation which follows therules already described, we had to define two other tables,namely thenetworkstable and thestatustable, which havethe following description:

• Networks: this table has one row for each network wewant to manage. It mainly maintains information aboutthe hosts included in each network by referring to aHostFile with structure described in RFC 952.

• Status: this table has the structure depicted in Fig. 9.The table has at least one row for each host in the spe-cified network. This table is updated (by inserting newrows) every time the status of the corresponding hostchanges.

As far as the implementation architecture of the prototypeis concerned, the general scheme of the architecture isdepicted in Fig. 10. Each NMAO consists of two main pro-cesses: the polling process and the process that implementsthe graphical user interface (GUI).

The polling mechanism is implemented as a backgroundprocess that periodically polls the SNMP agents of the net-work and communicates with the GUI process with IPCmethods. This allows the polling parameters to be receiveddynamically and user commands to be obeyed to initiate andterminate the polling procedure. Moreover, the polling pro-cess, in order to collect the values of the MIB variablescontained in the MIB-like database tables, constructs theSNMP requests by issuing queries to the data dictionary.

Some of the facilities provided by the GUI process are thefollowing:

• Real-time monitoring of the following parameters:operational state of network resources, MIB controland configuration variables.

• Graphical presentation of the performance measures asfunctions of time, based on historical and current rawperformance data.

• Dynamic definition of performance measures.• Maintenance of raw network management information.

In the sequel, we will present the part of the prototyperelated to the management of the quasistatic MIB variables.The operations included are rather primitive, while manage-ment applications may be built on the top of theseoperations.

The ‘quasistatic MIB management’ option of the framedepicted in Fig. 11 allows the user to choose a specific

Fig. 9. The status table.

Fig. 10. The elements of the network management application imple-mentation.

Fig. 11. The main network management frame.


combination of session and network in order to definetable objects that contain the network management informa-tion. This choice leads to the frame illustrated in Fig. 12,where the tables that are included in this session and net-work combination are presented.

The user can select the table he wants and do the follow-ing operations:

• View: table data presentation according to specific userconstraints.

• Delete: deletion of the table contents.• View Part: table data presentation in a way that enables

the user to choose at the same time the fields to bedisplayed as well as the constraints that have tobe fulfilled.

The constraints concern two parameters. First, theyconcern the host (we can choose one or more hosts). Second,they concern the valid time constraints the user wants.In addition to that, there is a prespecified operation, we

call it the LAST operation, that enables us to locate therows of the table that are still valid. The constraints canbe set by using the quasistatic constraints frame depictedin Fig. 13.

Next, we will present the part of the prototype relatedto the graphical presentation of the performance measuresas functions of time. The operations included are ratherprimitive. More complex management applications maybe built on the top of these primitive operations.

The ‘performance monitoring’ option of the frame illu-strated in Fig. 11 leads to the frame depicted in Fig. 14,where the user can choose a specific combination of sessionidentity and network name and a performance measure forpresentation in a line graph as a function of time.

The performance indicators included in the prototypeare based on dynamic sensor data and they concern hostperformance indicators, related either to host interfacesor to the TCP/IP implementation. Thus, the ‘input errorrate’ is used in order to trace possible transmission mediumfailures, while the ‘output error rate’ is used to monitorthe performance of the interface. For example, in a thinEthernet network the terminator may be disconnected.This will result in a great number of incoming packetsreceived in error. A high value of the ‘output error rate’indicates a possible interface malfunction. In addition tothat, the ‘throughput’ and the ‘utilization’ for an interfaceis defined.

The rest of the described performance indicators arerelated to TCP/IP performance. We can use the ‘reassemblyfailure probability’, which indicates a possible problemwith the values of various TCP/IP parameters or aproblem in the network itself. By examining the ‘TCP seg-ments retransmission probability’ we can distinguishbetween those cases.

In what follows, we will present some of the performanceindicators we have used. Taking into consideration the factthat only the rate at which the dynamic sensor data changecontributes an indicator of the network state, we adopted

Fig. 12. The table list frame.

Fig. 13. The quasistatic constraints frame.


the following notation: MIB-variable name(t): ¼ value ofthe MIB-variable at timet; (MIB-variable):¼ MIB-variablename(t1) ¹ MIB-variable name(t0).

TCP/IP implementation related performance indicators:

Reassembly failure probability¼D(ipReasmFails )D(ipReasmReqds )

Fragmentation failure probability

¼D(ipFragFails )

D(ipFragOKs ) þ D(ipFragFails )

Network services utilisation¼D(tcpCurrEstab )

tcpMaxConn

TCP segments retransmission probability

¼D(tcpRetransSegs )

D(tcpOutSegs )

Host interface related performance indicators (on specifichost interface):

Throughput : S¼D(ifInOctets ) þ D(ifOutOctets )

D(sysUpTime )

Link utilization¼S p 8

ifSpeed

Input error rate¼D(ifInErrors )D(sysUpTime )

Output error rate¼D(ifOutErrors )D(sysUpTime )

These performance indicators can be chosen by the userdirectly from the performance monitoring frame depictedin Fig. 14.

After selecting a specific performance measure, the usercan set two types of constraints to its presentation. Thefirst type of constraint concerns the network node and theinterface number (wherever needed, as for the throughput

Fig. 14. The performance monitoring frame.

IP throughput¼D(ipInRecieves ) þ D(ipOutRequests ) þ D(ipForwDatagrams p )

D(sysUpTime )

*for nodes acting as gateways;

UDP throughput¼D(udpInDatagrams ) þD(udpNoPorts ) þ D(udpInErrors ) þ D(udpOutDatagrams )

D(sysUpTime )


calculation). The second one concerns the valid time bound-aries and the step parameter. The frame for setting con-straints to performance measures related to TCP/IPimplementation is depicted in Fig. 15.

Except for the performance indicators presented in theperformance monitoring frame the user can define dynami-cally a performance indicator of his own choice. By usingstring parsing the management application will start a poll-ing procedure for the appropriate MIB variables in order togive a graphical presentation of the performance indicator.

Finally, another part of the prototype concerns the exis-tence of database management tools, accessible directlyfrom the network management environment. Using thispart, the user can perform database management operationson the raw performance data stored in the data tables(queries, table creation, etc.).

Our prototype has been tested thoroughly as far as itsfunctionality is concerned. So, we have done a number ofexperiments that show:

• how useful the temporal parameter is in building appli-cations that are based either on quasistatic or dynamicobjects. The whole history is directly accessible in aunified way.

• how easy the development of new applications is. Newapplications are developed by using either databasequeries or 4GL programming.

Part of these experiments is described in the next sectiondiscussing paradigms of how the proposed model can beused in network management applications.

As far as the size of the network being managed is con-cerned, the tests have been done for the university network.More precisely, the number of managed nodes varied from5 to 10, in order to examine the influence of the networksize in the performance of our model. Costs do not seem tovary significantly. Regarding the network utilisation used

by the network management requests and replies weobserved that it remains below 1% for all cases, while asfar as the data volume is concerned, it varies linearly withthe number of managed nodes. The last observation does notpose any problem in real applications, because we candefine a number of NMAOs, each of which has a TMIBfor specific applications, which is of manageable size rela-tive to the computing power of the workstation where theNMAO resides. From our experience every typical midsizeworkstation can host a NMAO.

As far as the choice of the polling period is concerned wehave tested a number of pair values (polling period forquasistatic objects, polling period for dynamic objects).The choice influences first the percentage of networkresources used for network management and second thesize of TMIB. For the quasistatic objects, it seems thatwhile the percentage of network resources used for networkmanagement grows proportionally with the decrease of thepolling interval, the resulting information existing in theTMIB does not differ significantly. This means that as faras the choice of the quasistatic objects polling interval isconcerned a rather large value is suitable. Typical valuesmay be [30 sec, 3 min].

For the dynamic objects, it seems that small values forthe polling interval increase both the percentage of networkresources used for network management and the TMIB sizebecause typically every query results in new TMIB infor-mation. But most of the applications that use this type ofdata, such as performance and fault management applica-tions, are not based on instantaneous data but rather onaveraged data over a given period. For most cases valuesin the region of [30 sec, 90 sec] are sufficient. The approxi-mation of the values of various measures is good enough.Lower time resolution is required only for measurementsof burstiness.

As far as the database size is concerned we have observed

Fig. 15. The performance monitoring constraints frame.


that this is not a serious problem. Considering the pollinginterval of 30 sec for both quasistatic and dynamic objectswe have that per managed node the database size is onaverage as follows: for the dynamic objects almost everyrequest resulted in new rows, thus giving at most 3000 rowsper day, each row consisting of about 0.5 Kbytes. For quasi-static objects typically only one out ofn requests contributesnew rows wheren takes values larger that 4 for most cases.Thus about at most 750 rows per day (worst case) are added,each row consisting of about 1.5 Kbytes. So, for the fullMIB-II information we need about 6 Mbytes per day permanaged node. Assuming that the lifetime of informationwhich is useful for real-time or time non-critical applica-tions is no more that two days, we find that we need storagespace of about 12 Mbytes per managed node. As the net-work being managed by one NMAO consists of no morethan 50 nodes, the required storage is less than the 1 GBwhich is typically available in any network managementworkstation. As far as global time applications are con-cerned, the necessary storage space depends heavily onthe specific application. In those cases, off-line analysistakes place—not necessary in the network management sta-tion—and the data are provided from off-line storage.

5. Conclusions

In this paper, we have proposed a new network manage-ment information model that directly includes the temporaldimension. In this framework the services provided by thismodel have been given, while the architecture supportingthem has been presented as well. Our view has been sup-ported by the implementation of a prototype related to theproposed model. The main aspects of our approach are:

• The direct incorporation of the time parameter as anattribute of the network management information, in a

way that maintains the already existing semantics as faras the network management model is concerned.

• The adoption of the temporal database model for storingthe historical network management information.

• The use of temporal database queries for doing networkmanagement related operations.

• The fact that we can easily incorporate in our modeleither future MIBs or private MIBs, that is our modelis open as far as the creation of new MIBs is concerned.

• The layered architecture that we have proposed for thetemporal network management information model.

The proposed model can be used to facilitate the devel-opment of network management applications. Having as abase the evaluation of network management informationin a given time window, we can easily apply varioustypes of requests ranging from a user query to the databaseto an algorithm detecting event correlation either in timenon-critical or global time regions. We conclude our dis-cussion presenting a few cases for which the proposedmodel has been used.

We consider that we have to manage an enterprise net-work that consists of several subnetworks connected to theenterprise backbone network. Suppose that a subnetwork Ais connected to the backbone network with a serial leasedline and two routers, one named ‘sisyfos’ at the backbonenetwork site and another one named ‘aiolos’ at the subnet-work A site. In this environment users of subnetwork Acomplain that they have low service quality. In order tosolve the problem, we try to check if the line is problematic,towards which direction and for which period of time, so asto inform the public PTT (Post, Telephone and Telegraph)organization that is the leased line provider. For thispurpose, we need to specify for what interfaces of routers‘sisyfos’ and ‘aiolos’ the number of incoming packetsdiscarded due to format errors was greater than a smallpercentage of the incoming packets delivered to the layer

Fig. 16. A dynamic TMIB table used to monitor the percentage of incoming packets discarded due to the format errors on a network interface.

Fig. 17. A quasistatic TMIB table used to report failures of network interfaces.


above, and for which period of time this was true. So, weneed an interval table with the following dynamic MIB-IIobjects of the ifTable in interfaces group as the TMIB tablecolumnar objects: ifIndex, ifInUcastPkts, ifNUcastPkts andifInErrors. Part of this table can be as shown in Fig. 16.

We consider that, for a given interface, the line connectedto that interface has a problem when the number of incom-ing packets discarded due to format errors is greater than the5% of the incoming packets delivered to the layer above. So,we have to issue the following query in order to identifywhen the line had a problem and towards which direction:

range of F is ifTableretrieve F.nodeID, F.ifIndexvalid during Fwhere F.nodeID ¼ ‘sisyfos’ or F.nodeID ¼

‘aiolos’ and F.ifInErrors .0.05*(F.ifInUcastPkts þ

F.ifInNUcastPkts)when true

In the same environment, suppose we want to make areport on the failures of interfaces of router ‘aiolos’ duringa specific day. This report will include also the time wheneach failure happened at the agent site and at the managersite. For this purpose, we need an interval table with thefollowing quasistatic MIB-II objects of the ifTable in inter-faces group as the TMIB table columnar objects: ifIndex,ifAdminStatus, ifOperStatus and ifLastChange. If ifAdmin-Status is up and ifOperStatus is down, the related interface isin failure mode. IfLastChange gives us the time at the agentwhen the interface changed operational state. A part of thistable can be as shown in Fig. 17.

In order to construct such a report, we have to issue thefollowing query:

range of F is ifTableretrieve F.nodeID, F.ifIndex,F.ifLastChangevalid at begin of Fwhere F.nodeID ¼ ‘aiolos’ andF.ifAdminStatus ¼ 1 and F.ifOperStatus¼ 2when F overlap [June 6, 1996]

In the same environment, the enterprise network is con-nected to two different network providers through serial

lines with a router named ‘pegasus’ which has two serialinterfaces. Suppose we want to evaluate the results of aspecific routing policy regarding the two service providers.In order to do so, we need to trace the changes of the routingtable entries (next hop) for a given set of destinations. Forthis purpose, we need an interval table with the followingquasistatic MIB-II objects of the ipRouteTable in ip groupas the temporal table columnar objects: ipRouteDest,ipRouteIfIndex and ipRouteNextHop. Part of this tablecan be as shown in Fig. 18.

For example if we want to know the history of routes thatthe datagrams followed for the destination 193.92.156.0during last month (June 1996) in order to check the routingstrategy related to the two different providers, we couldissue the following query:

range of R is ipRouteTableretrieve R.ipRouteIfIndex,ipRouteNextHopvalid during Rwhere R.nodeID ¼ ‘pegasus’ andR.ipRouteDest ¼ ‘193.92.156.0’when R overlap [June 1996]

References

[1] J. Case, M. Fedor, M. Schoffstall and J. Davin, A simple networkmanagement protocol, RFC 1157, DDN Network Information Center,SRI International, May 1990.

[2] Information processing, open system interconnection, common man-agement information protocol (CMIP), International Organization forStandardization and International Electrotechnical Committee, Inter-national Standard 9596.

[3] M. Rose and K. McCloghrie, Structure of management informationfor TCP/IP based internets, RFC 1155, DDN Network InformationCenter, SRI International, May 1990.

[4] J. Clifford, A. Croker and A. Tuzhilin, On completeness of historicalrelational query languages, ACM Trans. Databases, 19 (1994).

[5] R. Snodgrass, The temporal query language TQuel, ACM Trans.Databases, 12 (1987).

[6] T. Apostolopoulos and V. Daskalou, A model for SNMP based per-formance management services, Proc. IEEE SICON/ICIE ’95, Singa-pore, July 1995.

[7] T. Apostolopoulos and V. Daskalou, On the implementation of aprototype for performance management services, Proc. IEEE Int.Symp. on Computers and Communications, Alexandria, Egypt, June1995.

[8] Information processing, open system interconnection, structure of

Fig. 18. A quasistatic TMIB table used to evaluate routing policies by monitoring the history of routes that datagrams followed for a given destination.


management information, Part 1, International Organization forStandardization and International Electrotechnical Committee, Inter-national Standard 10165.

[9] B. Neumair, Modelling resources for integrated performance manage-ment, in: Integrated Network Management III, (ed. H.-G. Hegering,and Y. Yemini) IFIP Working Group 6.6, Elsevier Science, SanFrancisco, 1993.

[10] J. Haritsa, M. Ball, N. Roussoloulos, J. Baras and A. Data, Design ofthe MANDATE MIB, Proc. IFIP TC6/WG 6.6 Symp. on IntegratedNetwork Management III (ed. H.-G. Hegering and Y. Yemini) IFIPWorking Group 6.6, Elsevier Science, San Francisco, 1993.

[11] K. McCloghrie and M. Rose, Management information base networkmanagement of TCP/IP based internets: MIB-II, RFC 1213, DDNNetwork Information Center, SRI International, March 1991.

[12] J. Case, K. McCloghrie, M. Rose and S. Waldbusser, Managementinformation base for version 2 of the simple network managementprotocol (SNMPv2), RFC 1450, SNMP Research, Hughes LANSystems, Dover Beach Consulting, Carnegie Mellon University,April 1993.

[13] J. Case, K. McCloghrie, M. Rose and S. Waldbusser, Introduction toversion 2 of the Internet-standard network management framework,RFC 1441, SNMP Research, Hughes LAN Systems, Dover BeachConsulting, Carnegie Mellon University, April 1993.

[14] W. Stallings, SNMP, SNMPv2, and CMIP: The Practical Guide toNetwork-Management Standards, Addison-Wesley, Massachussets,USA, 1993.

Theodore K. Apostolopoulos is an AssociateProfessor at the Department of Informaticsat Athens University of Economics and Busi-ness. He obtained his diploma in electricalengineering in 1979 and his Ph.D. in infor-matics in 1983 from the National TechnicalUniversity of Athens. His research interestsinclude telecommunications, computer net-works, distributed systems and databases,performance evaluation of computer andcommunication systems, parallel algorithmsfor the solution of engineering problems. His

current research activity focuses on network management, networkservices, distributed applications and telematics. The research activ-ities in the above areas have been supported by various projects fundedby industry and government agencies. He has authored more than 30publications covering the above scientific areas. He is a member of theIEEE, the IEEE Computer Society and the IEEE CommunicationsSociety.

Victoria C. Daskalou received her bachelordegree in Informatics from the Departmentof Informatics at Athens University of Eco-nomics and Business in 1992, where she hasbeen a Ph.D. student since 1993. Herresearch interests include network manage-ment, databases and intelligent networks.Currently, she participates in three researchprojects related to the above scientific areas.


Temporal network management model Concepts and ... · Temporal network management model Concepts...

Documents

Transcript of Temporal network management model Concepts and ... · Temporal network management model Concepts...