1064-7570/98/0900-024 5$15.00/0 Ó 1998 Plenum Publishing Corporation 245
Temporal Network Management Information Model
and Services
Theodore K. Apostolopou los1 and Victoria C. Daskalou1
The paper addresses the issue of time as an attribute of the network management information. The temporal dimension is incorporated in the management information model proposed by the Internet Engineering Task Force (IETF), as it is described by the Structure of Management Information (SMI). The core of the proposed network management information model is the Temporal Management Information Base (TMIB), a conceptual representation of the diachronic behavior of network resources. The temporal network model also includes the de® nition of a speci® c architecture and a number of temporal services. The existence of such services facilitates the development of time-reference applications in different functional areas.
KEY WORDS: Temporal management information base (TMIB); temporal network management services.
1. INTRODUCTION
Telecommunication networks are passing through a rapid evolution. A very het-erogeneous environm ent supporting multi-vendor applications upon a variety of underlying switching systems and transmission facilities composes today’ s pic-ture of networking. The need to control these complex and heterogeneous net-works has introduced the concept of network management. The general network management architecture consists of the following main elements: a) a number ofmanaged nodes, each containing anagentthat maintains a localManagement Information Base (MIB); b) at least one network management station; and c) a
network management protocol, such as the SNMP [1, 2] or CMIP [3], which is used by the station and the agents to exchange management inform ation.
The MIB is a conceptual representation of the network resources that pro-vides the network manager with the ability to observe and control the current
1Department of Informatics, Athens University of Economics and Business,76, Patission Street,
behavior of managed nodes. But, due to the expansion of communication net-works in terms of volum e and complexity, observing the current state of network resources does not satisfy the network managers needs. They need also tools with forecasting and decision making capabilities that can help them to predict the future behavior of network resources based on past observations and long-term statistics of their historical behavior [4]. For this purpose the static nature of the MIB does not suf® ce. It needs to incorporate a temporal dimension that will describe the evolution in time of the network state.
Time is an attribute of most real-world phenomena, and in this paper we address the issue of time as an attribute of the network management inform a-tion. More precisely, we propose a model for representing the past, current and
future behavior of TCP
/
IP networks. For this reason we incorporate the temporaldimension in the management information model proposed by the Internet Engi-neering Task Force (IETF), as it is described by the Structure of Management Information [5, 6]. The temporal extension of the IETF information model is accomplished using the concepts of temporal databases. We considered a num-ber of temporal database models against their ability to represent and maintain network management information using speci® c criteria as presented in Section 2. As a result, in order to incorporate time in the IETF information model, we conclude to the adoption of the main issues proposed in the Temporal Rela-tional Database Model (TRDM), as named in [7], that was proposed in [8]. The core of the proposed network management information model is the Temporal Management Information Base (TMIB)that represents the evolution in time of the network behavior. The temporal network management model and the TMIB design are presented in detail in Section 3. The architecture that implements the proposed information model is described in Section 4. In Section 5 we present the temporal management services. Finally, in Section 6 we discuss the main issues of our approach.
2. MODELING NETWORK MANAGEMENT INFORMATION 2.1. Time-Reference Information Models
Modeling network management inform ation in communication networks attracted a fair amount of attention in recent years. In the standardization pro-cedure, two different inform ation models were de® ned to represent the network management inform ation: one from ISO [9] and one from IETF [5, 6]. Both mod-els are centered on the so-called managed objects, which represent an abstraction of network resources and form the Management Information Base (MIB). The informational model of ISO is fully object-oriented, with managed objects being instances of managed object classes. The model of IETF is less complex, with managed objects classi® ed in two types: scalar objects and table objects. The
scalar objects are simple MIB variables that can have at most one instance at a given time. The table objects are two-dim ensional arrays of scalar objects and at a given time they consist of multiple row entries.
A number of extensions to standard models have been proposed for represent-ing management information in commercial systems and research prototypes. In these systems, the use of databases for modeling network management inform a-tion is a commonly accepted solua-tion. The majority of these systems [10±12] make use of the conventional relational database model for implementing management information bases and performing integrated network management operations.
Little attention has been given in developing network management infor-mation models that can represent the past, current and future network behav-ior. The IETF and ISO information models do not support a standard schema for the representation of such time-de® ned management inform ation. More pre-cisely, most of the IETF MIBs represent only the current state of the managed objects. Representation of historical information can be found only in RMON MIBs [13, 14]. The RMON MIB [13] provides methods for controlling sam-pling mechanisms and storing historical information. The only temporal
infor-mation concerns objects in tables recording the sampling history, like the
ether-HistoryIntervalStartin the etherHistoryTable. RMON MIB version
2 [14] introduces the concept of the TimeFilter object as an index in MIB
tables. A TimeFilter object allows a network management station to
down-load only rows changed since a particular time. Although the name `TimeFilter’ may imply that RMON agents maintain a history of change events, this is not the case. A time-® ltered-value represents the current value of the object instance, not the `saved’ value at the time indicated by the TimeFilter index value. As men-tioned in [14], by design, the actual value of aTimeFilter object instant is not itself meaningful and it is not indicated in the returned SNMP response. As a consequence, the procedure adopted by RMON MIB agents merely provides a method to download rows changed since a particular time. It can not provide an integrated environm ent that can support historical services such as selection using temporal constraints and capitalization of historical data.
Explicit references to the temporal dimension of network management data are given in [4] and [15]. An important contribution in the area of modeling historical management information is the Management Information Repository of the DECmcc system [4]. It is a historical object base that can model both the observable and the historical state of objects and their attributes. The system pro-vides services for retrieving and recording historical inform ation. It propro-vides also services for exporting network management inform ation in relational databases and for purging and archiving the volume of historical data. Despite its ability to store and manage historical data and events, the system does not provide services to predict the future network behavior and to capitalize the management infor-mation. The work described in [15] proposes an active temporal database to store
events and trace timestamped data. In this model network functions can be spec-i® ed as Event-Condition-Action (ECA) statements. When the event occurs and the condition holds the action is performed. A new event speci® cation language was proposed to de® ne events, while any data manipulation language could be used to specify conditions and actions. This work describes a model to represent network functions. It does not present a speci® c schema to model the evolution in time of the network management inform ation, neither methods to capitalize the management inform ation.
For managing large communication networks, the management system should offer facilities for proactively managing network resources by using the experience that can be gained by historical information. The proposed model represents not only the past and current, but also the future behavior of network resources in TCP
/
IP networks. This new information model uses as basis the IETF model suitably extended to include the temporal nature of management information. For the incorporation of the temporal dimension in the IETF infor-mational model, it was necessary to consider temporal database models against their ability to represent network management information using speci® c criteria as presented in next subsection.2.2. Temporal Databases in Representing Network Managem ent Information
Although relatively little work has been done on incorporating the tempo-ral dimension in management information models, a large number of tempotempo-ral database models have been proposed over the course of the past decade. An overview of the area of time representation in databases can be found in [16].
The temporal database models extend the conventional relational model in order to store, along with inform ation on entities and relationships, the temporal dimension of data. Usually, this dimension takes the form of valid time. The valid time of an event is the clock time at which the event occurred. Two dif-ferent strategies for incorporating valid time in the relational model have been proposed in the literature. In the ® rst model, termed 1NF (® rst normal form) or row timestamping or temporally ungrouped, the schema of a table includes one or two distinguished temporal columnar objects that represent the period of time over which the fact represented by the row is to be considered valid. In the other approach, termed as N1NF (non-® rst normal form) or attribute timestamping or temporally grouped, the value of each attribute changes from atomic value to a set of values. An example of a table representing the traf® c information of two network nodes using the N1NF model is depicted in Fig. 1 while the same information using the 1NF model is presented in Fig. 2.
The proposal of temporal database models has enforced the developm ent of temporal languages. An evaluation of temporal database models and algebras
Fig.1. An example table of an N1NF temporal database model.
can be found in [17]. An evaluation of historical relational data models and query languages can be found in [7]. A joint effort for incorporating the strong points of each individual temporal data model and language lead to the developm ent of TSQL2 [18] which is a temporal extension of the SQL2 language. Various members of the temporal database community are now working to transfer some of the constructs and insights in to SQL3 speci® cation and a ® rst step to this effort was to propose the SQL
/
Temporal language [19].In the following we present the criteria that a temporal database model has to satisfy to be able to represent network management inform ation.
1. Model’ s ability to follow theSNMP MIB schema structure philosophy. For the network manager the temporal database will embody the net-work itself. As a consequence, the model adopted should extend the MIB schema in a form compatible to the structure of MIB table objects, which is already familiar to network managers.
2. Model’ s ability to support temporal selection, i.e. row selection based on valid time.
3. Model’ s ability to supporttemporal projection, i.e. computation of a new timestamp value for a row based on current value of its timestamp.
4. Model’ s ability to handle insert, delete and update operations in
databases supporting valid time.
5. Model’ s ability to support temporal aggregates. This is very important because of the vast amount of dynamic network management inform a-tion that should be ® ltered and capitalized.
6. Model’ s ability to handle the difference in the modeling between dynamic events and more static forms of information. More precisely, for the de® nition of our model we take into account the frequency that management inform ation variables change their values. Therefore, we de® ned two broad classes of objects [20, 21]: a) Quasi-static objects, which describe the current network con® guration (e.g., the number of host interfaces, the routing table, etc.) and their values do not change
very often; and b) Dynamic objects, which are related to network events
(e.g., the transmission of packets) and their values change very often during time.
After the consideration of the most important database models we have con-cluded that the 1NF models and more precisely the model presented in [8] satis-® ed these criteria. The model supports operations such as temporal selection and temporal projection, insert, delete and update and can perform temporal aggrega-tion. It can also handle the difference in modeling between events and more static forms of information as it can support event and interval tables. An extended evaluation of temporal database models against their ability to model network management inform ation can be found in [22].
3. TEMPORAL NETWORK MANAGEMENT INFORMATION MODEL
The elements of the proposed temporal network management information model are:
· The Temporal Management Information Base (TMIB)that forms a con-ceptual representation of the past, current and future behavior of network resources.
· Rules for the mapping of IETF MIBs onto TMIB table objects. · The characterization of historical and future TMIB tables asquasi-static
ordynamic.
· Thecapitalization of the data included in the TMIB, which is necessary due to the vast amount of management information.
3.1. Temporal Managem ent Information Base
The ® rst element of the proposed model is the TMIB. The TMIB is a collec-tion of temporal table objects that represent a diachronic view of the management information. There are two types of TMIB tables:
1. Interval tables that consist of a set of explicit columnar management information objects and of two implicit time objects. These time colum-nar objects, validFrom and validTo, represent the time interval
[valid-From, validTo) during which the state of the management information is valid.
2. Event tablesthat consist of a set of explicit columnar management
infor-mation objects and of one implicit time objectvalidAt. This time
colum-nar object refers to the instant that an event described by the explicit columnar objects took place.
3.2. Rules for the Mapping of IETF MIBs onto TMIB Table Objects
The second element of the model is the rules for the mapping of IETF MIBs onto TMIB tables. These rules are the following:
1. Table objects of IETF MIBs are mapped onto corresponding TMIB tables. There is an one-to-one mapping of the MIB table columnar objects onto the explicit columnar objects of the derived TMIB table. 2. A number of scalar objects are combined to form a TMIB table. Each
scalar object is represented by one explicit columnar object of the TMIB table.
3.3. Characterization of TMIB Table Objects
The TMIB tables (interval and event tables) can be classi® ed in two types: · Historical tables: The TMIB tables that represent the past and current
network state.
· Future tables: The TMIB tables that represent the future behavior of network resources. Future TMIB tables are constructed by applying the appropriate prediction and simulation models on information included in historical TMIB tables. Future tables have the same structure as histor-ical tables: they consist of explicit nontemporal columnar objects that rep-resent the predicted management inform ation and of implicit temporal objects that represent the future valid time.
Taking under consideration the criterion that classi® es the network man-agement information into quasi-static and dynamic managed objects, the TMIB
tables can be characterized asquasi-static or dynamic. The nontem poral
colum-nar objects of a quasi-static TMIB table represent only the quasi-static part of the corresponding MIB table or quasi-static scalar objects of MIB groups. The explicit columnar objects of a dynamic TMIB table represent delta values of the corresponding MIB objects. According to the nature of the information included in the two categories of TMIB tables the operations that can be performed in each category are quite different. The information included into quasi-static TMIB tables can be the argument in a retrieve, append, delete or replace requests by
Fig.3. Part of a historical interval quasi-static TMIB table.
the user, while the inform ation included in dynamic TMIB tables can be an argu-ment only to a retrieve requests.
An example of a TMIB table representing a part of the quasi-static objects of the MIB-II [23] ifTable of node ª pegasusº is illustrated in Fig. 3. In this table we can observe the history (the past and the present) of the values taken by each columnar managed object. Each row lists the values of the columnar objects during the time interval [validFrom, validTo). The current information is represented with rows having thevalidTo time object equal to ¥ . New rows are inserted into quasi-static TMIB tables only when the value of a quasi-static MIB object represented by an explicit TMIB columnar object has changed. For example, we can see that during the time interval [570, 1100) the interface with
ifIndex
=
1 was up (ifOperStatus=
1), during the interval [1100, 1800) itwas down (ifOperStatus
=
2), and since time 1800 until now, e.g., during the interval [1800, ¥ ), is again operational (ifOperStatus=
1).An example of a TMIB table representing a part of the dynamic objects of
ifTableof node ª pegasusº is illustrated in Fig. 4. As this is a dynamic table,
each row represents delta values of the columnar managed objects during the interval [validFrom, validTo). For example, the ® rst row in this table says that
during the interval [100, 130) the node ª pegasusº at the interface withifIndex
=
1 received 2000 octets and sent 1200 octets.Apart from these mentioned extensions, we need to introduce a totally new TMIB table whose objects are directly related to management of network events. This TMIB table describes the evolution in time of the received SNMP
Fig.5. Part of the historical eventtrapTableTMIB table.
trap messages. In order to do so, we de® ne a historical event trapTable. The table consists of the ® elds of the SNMP trap message plus two columnar
objects: atrapIndexwhich uniquely identi® es a row in thetrapTableand a
validAtobject representing the time instant that the trap message was received. An example of the trapTable TMIB table for the node ª nefeliº is depicted in Fig. 5. Each row describes a SNMP trap message received by the node at the time given by the value of the validAt ® eld. For example the second row {ª nefeliº , 2, . . . , 198.92.99.73, 1, null, . . . , 2500} says that the node ª nefeliº received an SNMP trap message from the node with IP address 193.92.99.73 at time 2500 that reported a warm start (trapType
=
1).3.4. Capitalization of Managem ent Information
Because of the vast amount of data included in historical tables (especially in dynamic tables) our model serves the need for capitalization of the network
management information by providing a new table type:capitalized TMIB table.
This type of tables is constructed by applying the appropriate aggregate operators on explicit columnar of historical TMIB tables. Capitalized tables represent the evolution in time of capitalized network management information. In our model the values of an aggregate columnar object are produced by applying the follow-ing aggregate operators described in [24] to the values of the source columnar object:
1. Simple aggregates: count, sum, avg, any, min, max and stdev.
The operators countU, sumU, avgUand stdevU are used when we
want unique aggregation, that is the aggregation is performed over the set of strictly different values in a columnar object.
2. Temporal aggregates:
· ® rst:returns, at each point in time, the oldest value of the given
colum-nar object, that is, the one associated with the ® rst valid row.
value of the given columnar object, that is, the one associated with the row with the latestfrom time.
· rate:computes the average growth or decrease experienced by values of
a columnar object over time, and is applicable only to numeric columnar objects. The return value indicates growth or decrease per time unit, e.g., Kbits
/
sec, packets/
sec.Based on the simple historical table of Fig. 4, an example capitalized TMIB table representing the history of the total number of ifInOctets received by all interfaces of node ª pegasusº is illustrated in Fig. 6b. In order to produce this capitalized table we determine the periods of time for which no new rows were inserted in the table presented in Fig. 4. For each such period we
calcu-late the sum ofifInOctetsfrom the values that were valid during that period.
For example, as illustrated in Fig. 6a during the interval [130, 140) the total
number of ifInOctets is 7300 because it is calculated only from the rows
{ª pegasusº , 1, 2050, 1320, 130, 160} and {ª pegasusº , 2, 4700, 3200, 130, 160} and {ª pegasusº , 3, 550, 630, 100, 140} that were valid during that inter-val.
4. ARCHITECTURAL MODEL
In this section we will describe the architectural model and the services that incorporates directly the proposed network management perspective. In order to present this architectural model we de® ne two new entities: the temporal net-work management system (TNMS )and the temporal agent (t-agent). We de® ne
as TNMS the entity that manages a Temporal Management Information Base
(TMIB)which diachronically represents the global network state. A t-agent is an entity physically located in a speci® c network node which has the responsi-bility of collecting network management information from all the managed nodes belonging to itsarea of responsibility and of storing this information in TMIB tables. The proposed network management architecture consists of one TNMS and a number of t-agents as illustrated in Fig. 7.
The TMIB design follows the distributed model. It consists of all the TMIB tables that reside in the t-agents. The communication between the TNMS and the t-agents does not need a speci® c network management protocol. This can be accomplished directly because the TNMS can consider that the TMIB tables residing on every t-agent are tables constituting a distributed database. All the well-known techniques and protocols borrowed from the distributed database era
may be used in order to achieve a consistent global view of the overall infor-mation representing the network state.
The architectural model admits a user-de® nable set of t-agents that should be established in the network management environm ent. More precisely, the net-work administrator should establish each t-agent implementation in a speci® c network node and de® ne its area of responsibility. In order to de® ne the area of responsibility of each t-agent, the network manager should divide all the network
components and
/
or the networks that she wants to manage in a number ofnonin-tersecting sets of SNMP agents. Each t-agent is associated with a unique object identi® er that characterizes the agent in the entire network. Each t-agent, in order to collect the network management information stored in the TMIB table, uses polling procedures as well as event-driven mechanisms that are based on the SNMP protocol. The time inform ation of each TMIB table is the time at the t-agent when the response of the polling procedure arrives. The TNMS and the t-agents can synchronize their clocks by using a protocol such as the NTP [25] or SNTP [26]. The network state is mapped on the database schema through a pre-selected and user adjustable use of ® lters. By using these ® lters the TNMS user can choose the right resolution as far as the time (how often) and
/
or the space (what inform ation) is concerned for each t-agent and each TMIB table. More precisely the TNMS user, by using the appropriate service, can de® ne dynami-cally the structure of the TMIB tables that will be maintained by the t-agent, as well as the table lifetime.One important parameter of the TNMS design is to have the network administrator interact solely with the TMIB, so that from the user’ s point of view the TMIB encompasses diachronically the network. Whenever the network administrator wishes to monitor the network state or to make changes to the managed nodes, she retrieves or updates the appropriate columnar objects in TMIB tables of the distributed global TMIB by using appropriate temporal net-work management services. The TNMS, in order to provide temporal netnet-work management, is constructed by the following service elements, as illustrated in Fig. 8:
1. General-Support Service Element (GSSE): It provides services for the de® nition of objects needed by the TNMS operation. It also provides services for creation and manipulation of TMIB tables.
2. Temporal Database Service Element (TDBSE): It provides services for the monitoring and control of the historical behavior of network resources which is stored in the appropriate quasi-static and dynamic TMIB table objects.
3. Future Management Service Element (FMSE): It provides services for the prediction of the future network behavior based on the knowledge about the historical behavior of the management information.
Fig.8. The structure of the Temporal Network Management System.
4. Capitalized Management Service Element (CMSE): It provides services for the capitalization and aggregation of historical network management information.
5. TEMPORAL NETWORK MANAGEMENT SERVICES
The temporal network management services include: de® nition, creation, copy and deletion of TMIB tables; periodic recording of managed object instances and valid times in TMIB tables; retrieval of historical and current data; manipulation (delete, update, insert) of the current network states; production of capitalized management information; and prediction of future data based on his-torical observations.
In the following, we provide an overview of the services that are classi® ed according to the service element they belong.
5.1. General Temporal Managem ent Services
The GSSE provides two types of services:
1. De® nition services, which can be used for de® ning the structure of three
types of TMIB objects: a)GS-DEFINE-TABLEfor historical, capitalized
or future table objects; b) GS-DEFINE-EVENT for event objects and
threshold expressions upon speci® c columnar objects of TMIB tables
that can trigger the event; and c)GS-DEFINE-FILTER for ® lter objects
that represent constraints on explicit or implicit time columnar objects of TMIB tables.
2. Table creation and manipulation services, which include GS-CREATE
for creation of TMIB table objects with speci® c structure in a speci® c
t-agent,GS-COPYfor reproduction andGS-REMOVEfor deletion of the
whole or speci® c parts of TMIB tables.
5.1.1. De® nition of TMIB Tables
The service GS-DEFINE-TABLE when used for the de® nition of a
histori-cal TMIB table requires the speci® cation of the following: (a) the IETF MIB objects it represents; (b) the temporal nature of the table, i.e., whether it is an event or an interval table; and (c) the table type (quasi-static or dynamic). For example, if we want to de® ne a TMIB table that its columns represent the
dynamic objects ipInReceives, ipInHdrErrors, ipInAddrErrorsof the
ipgroup and the dynamic objectstcpInSegsandtcpInErrsof thetcpgroup
the table structure, using ASN.1 notation, is as follows:
A capitalized TMIB table consists of implicit simple and aggregate columnar objects. The values of its implicit time objects can be produced by using tempo-ral constructors. A tempotempo-ral constructor is an event or interval expression that returns an event or interval. It uses not only event or interval constants, but also the identi® er of a TMIB table object and the following simple and aggregate temporal constructor operators:
Simple temporal constructor operators: a) beginOf and endOf: unary, return events; b)overlap; binary, as temporalintersection returning the points
in time whenbotharguments are valid; and c)extend: binary, as temporalunion
returning the points in time wheneither of the arguments are valid.
Aggregate temporal constructor operators: a) earliest
/
latest: return the oldest/
newest time of a TMIB table b) rising: returns an interval when the attribute was rising in value.For example, the structure de® nition of the capitalized table depicted in Fig. 6b is the following:
5.1.2. De® nition of Temporal Filters
The GS-DEFINE-FILTER service can be used for the de® nition of ® lter objects, i.e., objects that specify selection and temporal constraints. When the user wants to apply constrains that concern the values of the explicit columnar objects of TMIB tables we refer to selection constraints. When the user wants to apply strains that concern the value of the implicit time objects we refer to temporal con-straints. The de® nition of selection constraints is based on the [3].
The temporal constrains can be speci® ed by atemporal predicate, which is an expression containing logical operators (and, or, not), operating on expres-sions containing atemporal predicate operator(precede, overlap orequal). A temporal predicate operator is a binary operator that takes events or intervals as arguments and returns a Boolean value. The meaning of three temporal predicate operators is depicted in Fig. 9.
5.2. Temporal Database Services
These services support the management of historical TMIB tables and more precisely the periodic collection of managed object instances and valid times in
TMIB tables; the retrieval of past and current data using speci® c ® lters; the dele-tion or update of the current network management informadele-tion; and the inserdele-tion of new data in TMIB tables. These services are related to the operations that can be performed on a TRDM database event or interval table when the appropriate network monitors and network executors augment the database system.
5.2.1. Collection Service
The collection of managed object instances and valid times and their
record-ing in TMIB tables require background pollrecord-ing procedures. TheTD-MONITOR
service allows the user to de® ne the polling interval and the start and stop time. The service also accepts special parameters in order to change the polling param-eters and to suspend, resume or terminate a collection.
5.2.2. Retrieval Service
TheTD-RETRIEVE service permits users to select past and current views of information stored into historical TMIB tables objects. The user should de® ne explicit columnar objects and the implicit time objects of the virtual table that the service returns as a result. In addition, the user should de® ne the constraints that should apply on the source explicit objects as well as on the source implicit temporal columnar objects using the GS-DEFINE-FILTER service.
5.2.3. Manipulate the Current Network State
TheTD-APPEND,TD-DELETE, andTD-REPLACEservices can be used in order to change the current management information stored in historical TMIB tables. The action is transferred to the appropriate SNMP agent and affects the original MIB object in a transparent way to the user. The user should have the impression of interacting solely with the TMIB.
5.3. Capitalization Services
After the creation of capitalized TMIB tables in a speci® c t-agent, we use theCM-EXECUTEservice. The service controls the procedure that ® lls the table with capitalized inform ation coming from the aggregation of past and current information. The service accepts special parameters in order to suspend, resume
or terminate the production of capitalized data. The serviceCM-RETRIEVE
per-mits the users to retrieve capitalized information in a way similar to the TD-RETRIEVE service.
5.4. Managem ent of Future Data
The model offers services that can forecast the future management infor-mation based on historical observations. The services are based on any
used in order to control the prediction procedure by specifying the simulation or forecasting application and its parameters that will ® ll the future TMIB tables. TheFM-RETRIEVE service permits the users to retrieve predicted information in a way similar to the TD-RETRIEVE service.
6. USAGE OF THE TEMPORAL MANAGEMENT MODEL
Management applications have different requirements related to the tem-poral dimension of the management information. For example, a network man-agement application concerning realtime performance monitoring has radically different requirements, as far as the required information is concerned, from an application concerning the collection and usage of long term statistical data. The proposed model provides a number of services that can be used to develop of net-work management applications in different functional areas, taking into account the temporal dimension. Having as base the evolution of network management information in a given time window, we can easily apply various types of oper-ations ranging from every-day network administration to algorithms detecting event correlation or forecasting the future network state. In the following we present a few cases where the proposed model can be used.
We consider that we have to manage an enterprise network that consists of several subnetworks connected to an enterprise backbone network. Suppose that a subnetwork A is connected to the backbone network with a serial digital line and two routers, one named ª sisyphusº at the backbone network site and another one named ª pegasusº at the subnetwork A site. The subnetwork A is also connected to the backbone network by means of a backup leased line. Suppose that the primary connection has shown up a lot of errors. The network manager wants to keep track of the changes in the state of the primary line. Moreover, she wants to maintain a standard quality of service and proactively connect the backup line before the problem arises.
The network manager considers that the appropriate quality of service of the network connection is disturbed when the number of incoming packets dis-carded due to format errors is greater than the 5% of the incoming packets delivered to the layer above. Tracking the evolution in time of the line per-formance requires the creation of a historical interval TMIB with the
follow-ing objects presented by its columnar objects: nodeID,ifIndexand
ifInPer-Errors
=
ifInErrors/
(ifInUcastPkts + ifNUcastPkts). A part of thistable is presented in Fig. 10. First, the table structure has to be de® ned using the GS-DEFINE-TABLE service; then, it should be created at the t-agent that controls the area of responsibility in which the routers ª sisyphusº and ª pegasusº belong. After the table creation, the service TD-MONITOR should be used in order to control the polling procedure. Whenever the network manager wants to retrieve the time periods that the line had a poor performance, for example
dur-Fig.10. A historical TMIB table presenting the percentage of the incoming error packets.
ing the time period [100, 240), and for which transmission direction, she should use the TD-RETRIEVE service with the following ® lter structure:
Proactive management of the line performance requires the usage of a future TMIB table that should be produced by the historical data of the TMIB table presented in Fig. 10. The future table will have structure similar to the histo-rical table and it should be created using the GS-CREATE service. Then, the user should call the FM-EXECUTE service with a user parameter specifying the forecasting algorithm to ® ll the future table and continuously update its con-tents according to the inform ation changes in the historical table. For example, the future table could contain the predicted values for the percentage of error packets for a forecasting period of 60 seconds. The usage of the GS-EVENT
service can set a threshold in order to cause an alarm when the predicted value of the percentage of error packets reach an upper limit.
7. DISCUSSION
In this paper we have proposed a temporal network management inform a-tion model. Within this framework we have presented the primitive services pro-vided by the model, as well as the architecture that supports them. The proposed model incorporates directly the time parameter as an attribute of the network management inform ation maintaining the already existing semantics as far as the information management model is concerned. We have adopted the concepts of temporal database models for the de® nition of a Temporal Management Infor-mation Base (TMIB). The TMIB represents the evolution in time of the network management information. Our approach includes a capitalization procedure for ® ltering both in space and in time the vast amount of network management data. Finally, we have de® ned, using ASN.1 formulation, a number of primitive net-work management services that take into account the time parameter. This can result in a concrete and compact implementation of our view. The existence of such services facilitates the development of network management applications. Our view has been supported by the implementation of a prototype that par-tially implements the proposed model. The experimental use of this prototype exhibits very positive results as far as the advantages of our approach are con-cerned. The description of the ® rst version of the prototype is presented in [20].
ACKNOWLEDGMENTS
This work was partially funded by the Hellenic General Secretariat of Research and Technology.
REFERENCES
1. J. Case, M. Fedor, M. Schoffstall, and J. Davin, A simple network management protocol, RFC
1157, May1990.
2. J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, Protocol operations for version2of the Simple Network Management Protocol (SNMPv2), RFC1905, January1996.
3. International Organization for Standardization, Open System Interconnection, Common Man-agement Information Protocol (CMIP), X.711, ISO
/
IEC9596-1,1991.4. A. Shvartsman, Dealing with history and time in a distributed enterprise manager,IEEE Network, November1993.
5. M. Rose and K. McCloghrie, Structure of Management Information for TCP
/
IP based internets, RFC1155, May1990.6. J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, Structure of management information for version2 of the Simple Network Management Protocol (SNMPv2), RFC 1902, January
7. J. Clifford, A. Croker, and A. Tuzhilin, On completeness of historical relational query languages,
ACM Transactions on Database Systems, Vol.19, No.1,1994.
8. R. Snodgrass, The temporal query language TQuel,ACM Transactions on Database Systems, Vol.12, No.2,1987.
9. International Organization for Standardization, Open System Interconnection, Systems Manage-ment Information Model, X.720ISO
/
IEC10165-1.10. O. Wolfson, S. Sengupta, and Y. Yemini, Managing communication networks by monitoring databases,IEEE Transactions on Software Engineering, Vol.17, No.9, September1991.
11. J. Haritsa, M. Ball, N. Roussoloulos, J. Baras, and A. Data, Design of the MANDATE MIB. In H-G. Hegering and Y. Yemini (eds.),Integrated Network Management III, Elsevier Science Publishers B.V.,1993.
12. F. Stamatelopoulos, N. Roussopoulos, and B. Maglaris, Using a DBMS for hierarchical network management, Proc. of Engineer Conf. NETWORLD+INTEROP’95, Las Vegas, March1995.
13. S. Waldbusser, Remote network monitoring management information base, RFC1757, IEFT, February1995.
14. S. Waldbusser, Remote network monitoring management information base version 2 using SMIv2, RFC2021, January1997.
15. M. Hasan, An active temporal model for network management databases,Proc. of IFIP
/
IEEE Fourth International Symposium on Integrated Network Management, May1995.16. G. Ozsoyoglu and R. Snodgras, Temporal and real-time databases: A survey,IEEE Transactions on Knowledge and Data Engineering, Vol.7, No.4, August1995.
17. L. McKenzie and R. Snodgrass, Evaluation of relational algebras incorporating the time dimen-sion in databases,ACM Computing Surveys, Vol.23, No.4, December1991.
18. R. Snodgrass, I. Ahn, G. Ariav, D. Batory, J. Clifford, C. Dyreson, R. Elmarsi, F. Grandi, C. Jansen, W. Kafer, N. Kline, K. Kulkarni, C. Leung, N. Lorentzos, J. Roddick, A. Segev, M. Soo, and S. Sripada,TSQL2Language Speci® cation, September1994.
19. R. Snodgrass, M. Bohlen, C. Jensen, and A. Steiner,Adding Valid Time to SQL
/
Temporal, Febru-ary1996. (ISO/
IEC JTC1/
SC21/
WG3DBL-ANSI X3H2-96-151).20. T. Apostolopoulos and V. Daskalou, Temporal network management model: Concepts and imple-mentation issues,Computer Communications, Vol.20, No.8,1997.
21. T. Apostolopoulos and V. Daskalou, Network management services using a temporal information model. In A. Lazar, R. Saracco, and R. Standel, (eds.),Integrated Network Management V, Chapman and Hall,1997.
22. V. Daskalou, A temporal network management model, Ph.D. Thesis, Department of Informatics, Athens University of Economics & Business,1998. (in progress) (in Greek)
23. K. McCloghrie and M. Rose, Management information base network management of TCP
/
IP based internets: MIB-II, RFC1213, March1991.24. R. Snodgrass, S. Gomez, and E. McKenzie, Aggregates in the temporal query language TQuel,
IEEE Transactions on Knowledge and Data Engineering, Vol.5, No.5,1993.
25. D. Mills, Network time protocol (version3) speci® cation, implementation and analysis, RFC
1305, March1992.
26. D. Mills, Simple Network Time Protocol (SNTP), RFC1769, March1995.
Theodore K. Apostolopoulosis a professor at the Department of Informatics of Athens Uni-versity of Economics and Business. He obtained his diploma in electrical engineering in1979and his Ph.D. in informatics in1983 from the National Technical University of Athens. His research interests include telecommunicatio ns, computer networks, distributed systems and databases, perfor-mance evaluation of computer and communication systems. His current research activity focuses on
telecommunicati ons, network management, network services, distributed applications and telemat-ics. The research activities in these areas have been supported by various projects funded by industry and government agencies. He has more than30publications covering these scienti® c areas. He is a member of the ACM, the IEEE, the IEEE Computer Society and the IEEE Communications Society. Victoria C. Daskalou received her bachelor degree in Informatics from the Department of Informatics of Athens University of Economics and Business in1992, where she has been a Ph.D. student since1993. She joined the university’ s Network Operations Center in1997. Her research interests include network management of TCP
