An Architecture for Monitoring and Modeling ...

An Architecture for Monitoring and Modeling Network Systems* Gerald A. Winters Zhenjun Zhu Michael A. Bauer Hanan Lut yya Daniel A. Muntz Toby J. Teorey

Abstract

1 Introduction

Advances in network monitoring protocols, such as SNMP and RMON, combined with their widespread availability from commercial vendors, has led to the development of tools that enable system administrators to eectively manage problem domains, such as network con guration and troubleshooting. The abundance of monitoring and data-gathering tools presents an opportunity to combine network monitoring and modeling technologies to provide enhanced network management capabilities. For example, a network administrator can monitor his existing internetwork and use this information as a basis for capacity-planning projections. Alternative con gurations can be compared using \live" network data to characterize the trac streams, which is superior to using \back-of-the-envelope" estimates. This paper1 presents an architecture for monitoring and modeling, using commonly available tools. Our proposed architecture uses resources available to the network manager and does not require the use of any commercially available tools. Additionally, we show how network capacity planning, con guration, and sharing of network performance statistics among network administrative domains can be improved by the use of our architecture.

There is currently no methodology or systematic approach for the network administrator to use for the entire network modeling and performance testing process. However, there are many tools available that perform pieces of the entire task. For example, there are tools that perform, respectively, data collection, modeling, or network management. Many of these tools perform highly specialized tasks, such as computing network utilization or counting the number of collisions on an Ethernet. The problem is that no integrated approach links the individual tools together. Our architecture provides the basis for such a systematic approach for modeling and performance analysis of computer networks. Our model also addresses several other problems encountered in monitoring and modeling computer networks. For instance, Management Information Base (MIB) data (e.g., SNMP [3] or RMON [13] data) in its present form is generally not used for input to modeling and performance analysis tools. SNMP data can be summarized as a collection of counters re ecting the state of important kernel data structures. It is necessary to rst analyze or process much of the SNMP data before using it as input to network modeling and performance analysis tools. For example, network model-

 This

work is funded by IBM Canada Ltd. Laboratory Center for Advanced Studi es, Toronto. The IBM contact for this paper is Jacob Slonim, Head of Research, IBM Centre for Advanced Studies, 844 Don Mills Rd., Mail Station 21, North York, Ontario M3C 1V7, CA. 1

1

ing tools such as NetMod [2] and EtherMan [9] require statistical input not found in standard MIB data, e.g., the average packet rate and size. These statistics can, however, be calculated from SNMP by computing the change in the SNMP interface byte counter. The solution lies in implementing a layer of software that transforms raw MIB data into a form usable for modeling and analysis tools. In this paper, we outline a list of criteria for a systematic approach to monitoring and modeling. We also give an overview of our architecture and summarize a list of protocol commands with which to utilize our architecture. We conclude our paper by addressing several implementation issues and evaluating our design goals.

2 Architectural Principles

campus networks (e.g., 50,000 workstations and 200 LANs), keeping data availability high and providing the means to reduce associated network trac during peak trac periods.

3 Architecture Overview Figure 1 identi es the components of our proposed architecture. The arrows between components represent communication paths of data and commands. The following sections examine each of the architectural components.

3.1 Raw Data Collectors

Raw data collectors (Figure 2) comprise the

rst stage of our proposed architecture. Raw data collectors may be standardized agents, such as SNMP or RMON, or any other data collection tool. There is a wide variety of tools available for data collection, and we allow the network administrator to plug in any data collection tools at his/her disposal. We do, however, require that the domain of monitored objects be included in the \internet" subtree allocated for administration by the Internet Activities Board. This restriction still allows the inclusion of the entire \mgmt," \private," and \experimental" subtrees. The primary reason for this constraint is to allow for a consistent name space for monitoring objects.

Design

This section outlines a list of criteria for a systematic approach to monitoring and modeling: low cost, modular design, data sharing, and scalability. Any reasonable solution to providing a systematic approach to monitoring and modeling must be low cost. Our architecture uses commonly available tools and links them together to provide a complete system for monitoring and modeling, minimizing the need to purchase additional tools. Our architecture has a modular design, with a clear separation between components, facilitating the use of locally available resources, as various tools can be plugged into the system. The architecture allows for data sharing among administrative domains. Because solving many network problems requires information outside the administrative domain, information needs to be shared across network domains. To promote data sharing, statistical data is stored in a common data format and presented through a standard interface, regardless of how or where the data was collected and independent of any particular statistic. This idea of a common data format was rst promoted by the working group on operational statistics [11]. Our architecture scales up to large-scale

3.2 Statistic Collector Daemons

Statistic collector daemons, or collector dae-

mons, collect data from the raw data collectors, very likely performing some type of statistical analysis on the raw data, and then store the output (via a repository agent) in the data repository for later use by other tools. Performance statistics such as packet rate, packet size, and throughput are not normally available from standard MIB data collectors. Therefore, collector daemons are needed to convert the raw data into a suitable format for modeling and analysis tools. We use the term \statistic" loosely, referring to any data of interest. Statistics are referenced by object identi ers [8] and must be MIB object identi ers or instance identi ers under the subtree allocated for administration by the

2

Modeling and Analysis Tools

Repository Agents

Statistic Collector Daemons

Raw Data Collectors

Figure 1: Monitoring-Modeling architecture. Internet Activities Board. In other words, each MIB object must have an \internet" pre x object identi er:

Collector daemons can write statistics to the distributed data repository or delay writing by buering their data to the local le system. There may be cases in which network trac is high and it is desirable to keep collected statistics o-line during peak periods. Delayed writing allows collected statistics to be transferred over the internetwork at low trac periods. Controlling daemon-write behavior is done with commands to the daemon when it is initialized (Section 5.1). When a daemon is initialized for data collection, the daemon registers its location, start time, write frequency, and type of statistic with a repository agent. The repository agent responds by storing the daemon registration information in a le, giving administrators status information and aiding them in keeping track of dierent collection experiments. When a daemon nishes collecting data, it de-registers with a repository agent and becomes idle, waiting for additional commands.

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

The intent is to include all the standard MIBs, such as MIB-II and RMON, and all MIBs under the \experimental" and \private" subtrees. In Section 4, we introduce a MIB designed for modeling and performance analysis. Statistics can be instance identi ers, such as \ifInOctets.2", or object identi ers[7], such as \interfaces". When an object identi er is supplied to a collector daemon, the daemon returns the entire subtree, performing an SNMP walk. Collector daemons can collect simple scalar data or an entire subtree of data, depending on the speci cation of the statistic. We refer to the data returned by a daemon as a \statistic," even when the daemon is retrieving data from an entire MIB subtree with many objects. Collector daemons compute one or more statistics and write those statistics to the data repository through a repository agent. We suggest the use of single-statistic daemon collectors, daemons that collect data for one statistic only, although this is not a requirement. Singlestatistic daemon collectors can be grouped together as needed and easily shared among analysis and modeling tools.

3.3 Repository Agents

Repository agents function as gate keepers for stored statistical data from collector daemons, providing an abbreviated standard Unix le system interface with each one acting independently as a front-end to the underlying storage system. The available repository agent commands to access the stored data are a sub3

Modeling and Analysis tools

Data repository

Repository agent

Statistic collector daemons

MIB

* * *

Local file system

* * *

Raw data collector (RMON, SNMP, ...)

LAN

Figure 2: Data ow from a single LAN site to modeling and analysis tools. This gure illustrates the data ow from a single site, starting with the raw data collector and continuing up through the modeling and analysis tools. The dashed-line box indicates the presence of zero or more data-collection entities.

4

set of the full complement of Unix le system commands. We require the underlying storage system to be a distributed le system. This requirement is necessary to provide a prede ned directory hierarchy (see Section 7) for the data collected by the system. Repository agents shield clients from the the underlying distributed le system and provide a uniform interface. Since repository agents are actually just a shell over the native distributed le system, agents may be distributed throughout the system as needed. Repository agents export a uniform interface consisting of a prede ned directory structure for the data and a small set of system commands to manipulate the data. The simplicity of the interface should allow repository agents to be implemented on any distributed le system and allow the administrator to use existing resources. For example, the distributed le system can be AFS [5] or NFS [12], or any other distributed le system. The statistics stored in the data repository have a common storage format that is independent of any particular statistic. To promote data availability across administrative domains, we adopt the le-transfer format promoted by the working group on common operational statistics [11]. However, examination of the format proposed in [11] does not allow for the de nition of network topology information. In response to this de ciency, we must extend their format to include topology data, but we reserve this work for a future paper. The combination of a common storage format and uniform agent interface promotes sharing and facilitates the design and implementation of modeling and analysis tools. For example, it is possible for analysis tools to retrieve data from repository agents in dierent administrative domains. Additionally, analysis tools can be designed using prefabricated access routines and software to connect to agents and retrieve data from agents.

Modeling tools read from the data repository but can also write to the repository, providing statistics which may be of use by other tools. Analysis tools include simple report-andpresentation tools and also more complex tools, which perform such tasks as proving or disproving certain hypotheses, examining trac balance, or performing a tness study but do not provide results which can be used by other tools. Analysis tools only read data from the repository. The important distinction is that modeling tools can provide results, as do collector daemons, but analysis tools do not.

4 A MIB for Modeling and Performance Analysis To provide modeling statistics for input to modeling and analysis tools, we de ne a modeling MIB. The main reason for presenting new modeling statistics as MIB objects is to provide a common naming space with current MIB objects. The SNMP object ifOutQLen and the RMON object etherStatsPkts are useful modeling statistics, as are many others. Figures 3 and 4 illustrate the mstat (modeling statistics) MIB. We illustrate the structure of the mstat MIB informally using a method introduced in Stallings [10]. There are two groups in the mstat MIB: the network and device groups. The objects in these groups are designed to facilitate modeling and performance analysis of network systems. We give a brief description of each of these objects. The device group has a single table, devTable, with the rows of the table corresponding to each interface on a device. The devTable includes the following columnar objects:  devIndex: A value that uniquely identi es this row. The values for this object should be the same as the corresponding ifIndex object in the interfaces group.  devUtilization: Percentage value giving the average utilization of the interface. The queuing model used to calculate this value is device-dependent.  devAvgDelay: The average delay time in

3.4 Modeling and Analysis Tools

We oer the following intuitive de nitions for modeling and analysis tools: Modeling tools provide an abstraction of a system for the purpose of studying its behavior. 5

experimental (internet 3)

mstat (experimental x)

device (mstat 1) network (mstat 2)

Figure 3: Graphical view of the mstat MIB. The mstat MIB is a new MIB for modeling and performance analysis. The objects in the mstat MIB represent a rst step in de ning a complete MIB.

device (mstat1)

network (mstat 2)

netUtilization (1)

devTable (1)

netAvgDelay (2) devEntry (1)

netAvgInQLen (3) devIndex (1)

netAvgPktLen (4)

devUtilization (2)

netAvgPktArrivalRate (5)

devAvgDelay (3) devAvgInQLen (4) devAvgPktLen (5) devAvgPktArrivalRate (6) devAvgPktServiceRate (7) devProbQOverflow (8) devQSpace (9)

Figure 4: Hierarchical view of the mstat device and network group objects.

6

5 A Client-Server Protocol for Monitoring and Modeling

milliseconds packets undergo at this device. 

devAvgInQLen: Average length of the in-

put packet queue. This statistic is useful for buer con guration decisions.



devAvgPktLen: Average length of packets



devAvgPktArrivalRate:



devAvgPktServiceRate: A value indicat-





Repository agents act as servers to clients wishing to access the data repository. Collector daemons and modeling and analysis tools are clients. Clients connect with servers and perform a series of commands to read and write data. The server accepts connections and carries out commands from clients. The following sections summarize a client-server protocol for accessing the data repository. Additional commands control and synchronize data collection activity.

processed by a device.

The average packet arrival rate. This statistic is useful in calculating other statistics and is a good indicator of the size of the workload for a device.

5.1 Repository Access Commands

ing the average number of packets a device can serve per unit time. This value is normally static but can change under certain conditions.

Repository agents, acting as servers, are responsible for controlling access to the data repository. Clients communicate with repository agents using the following protocol commands:

devProbQOver ow: The probability that

the number of waiting jobs is larger than the number of packets the input queue can hold.

LOGIN

devQSpace: The maximum size of the

EXIT OPEN

output queue.

The network group includes the following objects:

CLOSE READ

netUtilization: The average utilization of

WRITE



the network. The method for calculating this statistic depends on the media type. In the case of Ethernet, Lam's CSMA/CD model [6] is used.



netAvgDelay: The average delay a packet



netAvgInQLen: The average length of the



netAvgPktLen: The average length of the



netAvgPktArrivalRate:

LS CD

Clients use an abbreviated set of Unix le system commands to access data les. The LOGIN and EXIT commands are used to authenticate, log in, and log out. The actual authentication mechanism is a local choice.

undergoes.

input queue.

5.1.1 Synchronizing the Data Collection Process

packets occurring on the net. packet arrival rate.

- start a session and authenticate a client - terminate a session - open a file for reading and/or writing - close a file - read data from a named file - write data to a named file - list directory entries - change the working directory

There are two commands for synchronizing the actions of collector daemons: START and ABORT. The START command speci es the

The average 7

start and stop time of data collection, a variable list of MIB objects to be polled, and buering control information. In cases where network trac is high, collection daemons can be programmed to buer output data to the local le system, transferring the data during low trac periods or o-hours. The ABORT command terminates data collection immediately. When a daemon terminates data collection, as instructed from a START command or by an ABORT command, the daemon goes idle and listens on a port for further commands.

ing with a master daemon using the REGISTER command. The master daemon listens on a port for commands from an administrator and forwards those commands to the appropriate collector daemons. Figure 6 illustrates the relationship between collector daemons, the master daemon, and the administrator, and it identi es the communication paths. The master daemon accepts two commands from an administrator, the START and ABORT commands, and uses the MIB object parameter from those commands to determine which daemons to forward the commands to. Table 1 gives an example of the registration information a master daemon would maintain for a particular situation.

5.1.2 Keeping Track of Data Collection Experiments Two commands, ACKSTART and ACKSTOP, relate status information on collector daemons to administrators. When collection daemons begin collecting data, they send an ACKSTART command to a repository agent. Repository agents process ACKSTART commands by updating a le in the prede ned directory tree with information from the command, including the start time of data collection, the statistics the daemon is collecting, and the frequency the statistics are gathered. Administrators can use this information to keep track of current collection experiments. Since collector daemons can be programmed to buer output data, the ACKSTART command is a useful indicator in determining if collector daemons are collecting data. Figure 5 illustrates the sequence of events that occur when a collector daemon receives a START command from an administrator. When a collection daemon terminates the data collection process, the daemon sends an ACKSTOP command to a repository agent. The agent responds by removing the daemon status information from the current collection daemon le.

7 The Prede ned Directory Tree Data is stored in a prede ned directory tree, which is illustrated in Figure 7. The design of the directory tree provides easy look-up of data les and minimizes data storage requirements. The top-level directory has three directory entries: /ACTIVE, /DATA, and /TOPOLOGY. The /ACTIVE directory contains data les with information about daemons that are actively collecting data. When a daemon registers with the ACKSTART command, the repository agent responds by updating the appropriate le in /ACTIVE with the daemon registration information. The les in the /ACTIVE directory contain status information about current collection experiments. When the last collection daemon de-registers with the ACKSTOP command, the repository agent removes the appropriate /ACTIVE le. The /TOPOLOGY directory contains network topology data les. The /TOPOLOGY data les provide network topology data to modeling and analysis tools, giving these tools the means to integrate repository statistics. Many modeling and analysis tools require both network topology and computed statistics for input. We place no restriction on the names of les in /TOPOLOGY. The /DATA directory (Table 2) contains the subtree where statistical data les are stored and identi es the networks from which

6 Multiplexing Between Collector Daemons Because there may be multiple collector daemons operating on a single host, daemons register the network address, port on which they are listening, and MIB objects they are collect8

Administrator

1. START command Repository agents

3. ACKSTART cmd

REGISTER command Daemon

REGISTER command Daemon

REGISTER command

. . .

Daemon

2. Collect data

INTERNETWORK

Figure 5: Starting a collection daemon. Daemons remain idle until given a START command. Daemons begin collecting data as instructed by the START command and acknowledge by sending an ACKSTART command to a repository agent.

Administrator

Daemon (arbitrary port)

. . .

Master daemon (well−known port)

Daemon (arbitrary port)

Figure 6: Communication paths between the administrator, the master daemon, and collector daemons. START and ABORT commands are multiplexed to the proper collector daemon through a master daemon. During initialization, collector daemons register with a master daemon. 9

Address 141.211.128.189

Port 2001

141.211.128.189

2006

Variables ifOutQLen ifInOctets devUtilization

Table 1: A sample master daemon data table. Master daemons must be able to multiplex administrator commands to the correct data collector daemon.

ACTIVE (active daemon files)

DATA

TOPOLOGY (network topology files)

data files subtree

Figure 7: A view of the directory structure presented by the repository agents. Repository agents control access to stored data and oer an abbreviated Unix le system interface with the usual read, write, ls, and cd operations. the statistics are gathered. As Table 2 indicates, sample entries in /DATA/* might appear as:

tire internet subtree is not represented. The mgmt subtree contains the SNMP MIB-II and RMON modules. The experimental subtree has modules that are under development and may be of importance. The private subtree has the important enterprise-speci c MIBs. Figure 8 gives an expanded directory representation of the subtree beginning at this level. Statistical data les are contained in the leaves of the /DATA subtree. As illustrated in Table 3, the naming scheme used for statistical data les gives useful information about the les. Data le names consist of a series of descriptive elds separated by a \.", including start time and date, end time and date, and sampling frequency of data collection. The fully quali ed path name indicates the location, statistic, start time and date, end time and date, and sampling frequency of data collection. Data les contain a series of \time-stamp," \instance," and \value" groupings. The \instance" is an instance portion of an SNMP instance identi er, and \value" is the value of the SNMP instance. An SNMP instance identi er uniquely identi es an instance and consists of an object and instance portion. For example,

/DATA/nfsnet /DATA/net-1

The /DATA/* directory entries identify the devices where the statistics were sampled. Devices can be hosts, routers, or LANs. Sample entries might appear as: /DATA/nfsnet/rtr1 /DATA/citi/141.211.128

The fourth directory level, /DATA/*/*/*, contains the subtree of internet MIBs. This subtree represents a portion of the subtree under administration by the Internet Activities Board (IAB). More precisely, the subtree starting at /DATA/*/*/* implicitly has the pre x "iso.org.dod.internet". For example, the /DATA/citi/rtr1/mgmt path has a fully quali ed object identi er of \iso.org.dod.internet.mgmt". The directory entries at this level (mgmt, experimental, and private) are the only subtrees that we expect to contain useful statistics for modeling and performance analysis, which explains why the en10

Level 1 /* Root directories ACTIVE DATA TOPOLOGY

Level 2 /DATA/* Network directories citi nfsnet net-1

Level 3 /DATA/*/* Device directories 141.211.128 rtr1 35.146.99.6

Level 4 /DATA/*/*/* Start of internet MIB directories mgmt experimental private

Table 2: Logical view of the prede ned directory tree. Levels 2 and 3 identify the network and device from which statistics were collected, and level 4 contains the Internet MIB subtree.

/DATA/*/*/*

mgmt

experimental

mib−2

system interfaces . . .

. . .

mstats

private enterprises

at . . . snmp rmon . . .

. . .

. . .

Figure 8: Expanded view of the /DATA subtree. The mgmt, experimental, and private subtree structure is the same as the corresponding object identi er subtree maintained by the Internet Activities Board.

/DATA/*/*/... ...mgmt/mib-2/interfaces/ifTable/ifEntry/ifInOctets/ 950411.164701.950415.120000.60 .../experimental/mstats/device/devTable/devEntry/ devUtilization/921010.000000.921011.000000.120 Table 3: Schematic view of statistical data les at the frontier of the directory structure. The object identi er of data les can be deduced from the directory of the le.

11

the SNMP object ifInOctets might have an instance identi er of:

les that should not be shared can be made unreadable by everyone except the owner or a special group. Because of the widespread availability of network-sning tools, we also recommend the use of data encryption in some situations. Encryption should be optional; encryption processing requires extra CPU cycles on both the client and server ends. We defer the issue of encryption as future work.

iso.org.dod.internet.mgmt.mib-2\ .interfaces.ifTable.ifEntry\ .ifInOctets.1

The instance portion is the \1", and the object identi er is the rest of the instance identi er. The rst few entries in an ifInOctets le for a device with two interfaces might look like the following: 950429164700 950429164700 950429164800 950429164800 ...

1 2 1 2

10 Summary

10678 22300 19933 31933

In Section 2, we listed the guiding principles for our architectural design. Our most important principle is to provide a systematic approach for modeling and performance analysis of computer networks. There are many commonly available tools that perform part of that task, but no single approach coordinates these tools. By de ning collector daemons that gather and store statistical data, data repository agents that act as gate keepers to statistical data, and a protocol for accessing the data and synchronizing the data collection process, we have speci ed a complete system, yielding a systematic approach to modeling and performance analysis. We also propose that a systematic approach to modeling and performance analysis must be low cost and modular. Our system uses local and distributed le systems for data storage. We use a local name service such as DNS or BIND. Our system also utilizes common MIB collectors, such as SNMP or RMON agents. Additionally, we specify a protocol for collector daemons, which requires only an investment of time. This exibility to plug local resources into the various parts of the system, utilizing existing resources, provides for a lowcost, modular approach. Because network systems are getting larger and more distributed, our systematic approach must scale. This means our system must avoid bottlenecks and grow as the internetwork grows, while keeping associated amounts of trac low. There are, however, two factors that negatively impact the ability of our system to scale. First, scaling is limited by our requirement that repository agents oer a uni ed di-

Because the object portion of the instance identi er is implied from the directory of the data le, data storage requirements are reduced, as only the instance portion of the entire instance identi er is stored.

8 Locating Agents

Repository

Clients must locate repository agents before any interaction can take place. Clients locate agents using a global name service, depending on what is available. For example, the Domain Name Service (DNS) [4] and Berkeley Internet Name Domain (BIND) [1] are two common naming services. As part of the repository agent bootstrap process, the agent registers itself with the global name service. Clients across administrative domains easily locate repository agents this way.

9 Security and Privacy Issues Security is an important issue, as there may be statistics that should be restricted to a select group of people. For example, a network service provider or telecommunications carrier may want to gather statistics that should not be shared with competitors. Access control can be set using the security semantics of the underlying distributed le system. Restricted data 12

rectory hierarchy, which becomes more dicult to meet as the internetwork grows. For example, there may be economical limits in making the data repository globally accessible. Additionally, there are data le managability issues that arise from large systems, with new networks being added, other networks being removed, devices being renamed, etc... Secondly, scaling is limited by the raw data collectors (e.g., SNMP). Our system can do nothing about the volume or speed of trac from raw data collectors to collector daemons. Therefore, our system can scale no better than the raw data collectors. As a result of these limits, we must qualify our maximum scaling claims to large-scale campus networks of 50,000 workstations and 200 local area networks. However, our system does have scaling enhancement features. The repository agents are an interface to the underlying distributed le system and can be implemented throughout the internetwork as necessary. Collector daemons can be programmed to buer data in the local le system, transferring data to the data repository during slow network trac periods or o hours. Additionally, collector daemons normally perform statistical computation on the raw monitored data before writing to the data repository, thereby distributing the CPU load and in some cases reducing the volume of data to be stored (compared to the raw monitored data). And nally, collector daemons can be distributed throughout the internetwork as desired. For example in close proximity to the raw data collectors, or even on the same devices, eliminating monitored network trac entirely. We also designed our system to allow sharing of collected data between administrative domains and customers. A prede ned directory structure and a general set of le system commands allow users to browse and retrieve data from the data repository. Additionally, a speci ed data format for data les and the transfer format proposed by the working group on operational statistics enable network administrators to share data with customers and users from dierent administrative domains. Using statistics monitored from the live network increases the potential to use modeling in

management of computer networks. In particular, con guration and capacity planning are enhanced as a result of using monitored statistics with modeling technology, because live data can be used as input rather than relying on human experts to estimate model parameters. As an example, suppose an administrator is considering the addition of new users and hardware to an existing system. The administrator can experiment with alternative con gurations using network modeling tools. By integrating monitored statistics rather than estimates or guesses, the administrator can achieve better results [14].

11 Future Work Our eort represents a good start towards a complete speci cation for modeling and performance analysis. However, several areas need additional work. The data-transfer format needs to be extended to include topology data. In addition to stored statistics, many modeling and performance analysis tools require network topology as input. To include topology data in the system, the transfer and data storage format needs to be extended. Privacy for data transfers should also be available. The mstat MIB for modeling and performance analysis represents a good starting point, but it needs to be expanded to include other useful objects. Our intent is not to specify a complete MIB but rather to begin the hard process of specifying a complete MIB. Future work needs to be focused on expanding this MIB. Finally, additional work is needed on the modeling and analysis tools to come up with a core set of standard reporting tools. A core set of standard application tools enhances sharing and serves as a vehicle for comparison. If administrative domain \A" uses results from report tool \a" and domain \B" uses results from report tool \b", then there may be uncertainty when comparing the results from tools \a" and \b", as their results might be computed dierently. Using a standard set of tools makes the comparison of results easier, because the methods for computation are known in advance. 13

About the Authors

methods in software engineering and fault tolerance. She can be reached via electronic mail at [email protected].

Gerald A. Winters

is a Ph.D. candidate in Computer Science and Engineering in the EECS Department at the University of Michigan. He received a B.S. in computer science and mathematics from Michigan State University in 1986 and his M.S. in computer science from the University of Michigan in 1991. His research interests include network performance and systems management. His Internet address is [email protected].

Daniel A. Muntz

Dan Muntz recently comleted his Ph.D. in Computer Science at the University of Michigan. His research interests include distributed systems, mass storage, networking and kernel hacking. He can be contacted via email at [email protected].

Toby J. Teorey

is Professor of Electrical Engineering and Computer Science at the University of Michigan and Associate Chair for CSE. His research interests are in network performance and database technology. His Internet address is [email protected].

Zhenjun Zhu

is currently a M.S. student in Department of Computing and Information Science of Queen's University, Kingston, Canada. He received his B.Sc. Hon. in Computer Science from University of Western Ontario, London, Ontario, Canada in 1995. He has software design experience with IBM Canada Ltd. and Bell-Northern Research Ltd. in areas of computer language and network design and OAM. His research interests include network management, distributed system and database, and real-time protocol in multimedia network applications. He can be reached via electronic mail at [email protected].

References [1] P. Albitz and C. Liu. DNS and BIND. O'Reilly & Associates, Inc., 1992. [2] D. W. Bachmann, M. E. Segal, M. M. Srinivason, and T. J. Teorey. \NetMod: A Design Tool for Large-scale Heterogeneous Camp us Networks". IEEE JSAC, 9(1):15{24, January 1991. [3] J.D. Case, M. Fedor, M.L. Schostall, and C. Dav in. Simple Network Management Protocol (SNMP). RFC 1157, Network Information Center, SRI International, Menlo Park, CA, May 1990. [4] J. Garcia-Luna-Aceves, M. Stahl, and C. Ward. Internet Protocol HandBook:

Michael A. Bauer

is Chairman of the Department of Computer science at the University of Western Ontario. He received his doctorate from the University of Toronto in 1978. He has been active in the Canadian and International groups working on the X.500 Standard. He is a member of the ACM and IEEE and is a member of the ACM Special Interest Group Board. His research interests include distributed computing, software engineering and computer system performance. He can be reached via electronic mail at [email protected].

The Domain Name System (DNS) Handbook. SRI International, Network Infor-

mation Systems Center, Menlo Park, CA, 1989. [5] J.H. Howard. An Overview of the Andrew File System. In Winter 1988 USENIX Conference Proceedings, pages 23{26, February 1988. [6] S. S. Lam. A Carrier Sense Multiple Access Protocol for Local Net works. Computer Networks, 4(1):21{32, February 1980.

Hanan L. Lut yya

is an assistant professor of Computer Science at the University of Western Ontario. She received her B.S. in computer science from Yarmouk University, Irbid, Jordan in 1985, her M.S. from the University of Iowa in 1987, and her doctorate from the University of Missouri-Rolla in 1992. She is a member or the ACM and IEEE. Her research interests include distributed computing, formal 14

[7] D. Perkins. Understanding SNMP MIBs. SynOptics Communications, Inc., 1992.

[11] B. Stockman.

A Model for Common Operational Statistics. RFC 1404, Net-

work Information Center, SRI International, Menlo Park, CA, January 1993. [12] Sun Microsystems, Inc. NFS: Network File System Protocol Speci cation. RFC 1094, Network Information Center, SRI International, Menlo Park, CA, March 1989. [13] S. Waldbusser. Remote Network Monitoring Management Information Base. RFC 1271, Network Information Center, SRI International, Menlo Park, CA, November 1991. [14] G. A. Winters and T. J. Teorey. Extending the RMON Matrix Group to Provide Network Layer Statistics. In Proceedings of CASCON 1994 Conference, pages 166{ 178, Toronto, Oct. 31-Nov. 3 1994.

[8] M.T. Rose and K. McCloghrie. Structure

and Identi cation of Management Information forTCP/IP-based Internets. RFC

1155, Network Information Center, SRI International, Menlo Park, CA, May 1990.

[9] M. Schulze, G. Benko, and C. Farrell. Homebrew Network Monitoring, A Prelude to Network Management. Technical report, Department of Computer Science, Curtin University of Technology, Perth, Western Australia, March 1993. [10] W. Stallings.

SNMP, SNMPv2, and CMIP. The Practical Guide to Network Management Standards. Addison-Wesley,

Reading, MA, 1993.

15