The main output of this work are (1) the specification of the required isnMIB structure & objects, (2) the definition of QoS metrics & the related management functions. These outputs were complemented by an advance overview of the encompassing management architecture, chosen from a set of possible scenarios, which provided an input to the specifications for the design of the MUSIQ management tools during the follow-on work-packages.

Design and specification procedures for the isnMIB and QoS parameters were guided by the results of three sub-tasks: (a) the study of user requirements (b) the analysis of information service (IS) systems and (c) the study of related MIB functionality.

The analysis of the survey on user requirements, performed within MUSIQ, provided insight and specific information on the need for management tools expressed by three IS target groups: end-users, managers and developers. The analysis of IS engines and systems (0) has provided an insight on the objects that can influence the operational status and performance of Information System components and that should consequently be monitored.

Significant standardisation activities were undertaken within the project (section 8), participating and contributing to the relevant IETF working groups activities (in meetings or through e-mailing lists). The definition of the Management Information Base was preceded by a survey on related MIBs: different MIBs relating to application management were surveyed, their contents analyzed and cross-MIB overlaps and relationships identified. It is worth noting that this is an issue that has been worrying the IETF itself and has excluded developers from an implementation. The outcome of this work has been submitted to the IETF-community in the form of an internet-draft, [38]. Input from this task has ensured that during the isnMIB definition we have conformed to international standardisation guidelines and practices, made use of the existing management object space, and making it easier to migrate to a fully standards compliant solution once (if) the appropriate standards will be available and of cost-effective implementation.

Driven by the results of the analysis tasks, we have formulated a set of metrics that would be used to compute quality of service parameters, making use of the objects defined in the isnMIB. Both the isnMIB and the QoS metrics were then reviewed under the light of a discussion around the possible management scenarios to be used in the project. The distributed nature of Internet based Information Services dictated the adoption of a distributed and hierarchical architecture based on two levels of manager components (1): The Site Managers (SM), interacting with local agents implementing the isnMIB and the Domain Managers (DM), higher level repositories of management data.

TABLE OF CONTENTS

EXECUTIVE SUMMARY

TABLE OF CONTENTS

Table of Figures

INTRODUCTION

Document Road Map

Management Requirements and MIB definition

1 Information Service architecture

2 Information Service Implementations

3 Management of Information Systems

4 Existing MIBs

5 Synopsis - Management Requirements

6 The management functions

7 MIB Structure

8 Standardization Activities

QoS Metrics Definition

1 Management Scenarios

2 QoS Management

3 QoS Indicators

4 QoS Metrics

Conclusions

References - Bibliography

APPENDIX A: Configuration of Information Services

APPENDIX B: The full SNMP-based approach

1 Introduction

2 Architectural Overview

3 The IS Manager MIB

APPENDIX C: ASN.1 Authoring

1 Introduction

2 Authoring Guidelines

3 Textual Conventions

4 Tools Used

APPENDIX D: MIB ASN.1 Description

1 The IS Node MIB (isnMIB)

2 The IS Manager MIB (ismMIB)

The main output of this work are (1) the specification of the necessary isnMIB structure & objects, (2) the definition of QoS metrics & the related management functions. These outputs were complemented by an advance overview of the encompassing management architecture, chosen from a set of possible scenarios, which provided an input to the specifications for the design of the MUSIQ the management tools during the follow-on work-packages. The SNMP-management framework was selected as one of the foundations to our work, due to wide implementation and the fact that it is a de facto standard for management of TCP/IP networks.

The following methodology was adopted, leading to the definition of a consistent set of management parameters and QoS metrics:

• Analysis of the user requirements survey. The analysis of the survey provided insight and specific qualitative and quantitative information on the need for management tools expressed by three target groups: IS end users, IS managers and IS developers. This information aided us in the process of identifying the end users quality requirements, the problems faced by the managers and the management functionality offered or planned by the developers. The proposed framework aims to address and meet these user requirements, and throughout its design we where driven by them. The results of this analysis are presented in "DESIRE Project Deliverable D7.1 - Requirements Survey for Quality of Service in Distributed Information Systems" and provide input to the work described in this document.
• Analysis of the information systems. We have performed a detailed analysis on the functionality and architecture of information engines (section 1), aiming at the identification and parameterization of the components that could reflect the operational behavior of the system and that could be meaningful for the computation of QoS parameters. We have also looked at the operational hooks and dependencies that may assist in the instrumentation of the agent and during the MIB design. Since, the DESIRE project is emphasizing on WWW, we emphasized on HTTP engines and have studied the HTTP protocol for identifying protocol management requirements.
• Overview and analysis of existing MIBs. The definition of the Management Information Base was preceded by a survey on related MIBs: different MIBs relating to application management were surveyed, their contents analyzed and cross-MIB overlaps and relationships identified. It is worth noting that this is an issue that has been worrying the IETF itself and has excluded developers from an implementation. The outcome of this work has been submitted to the IETF-community in the form of an internet-draft, [38]. This task has ensured that during the isnMIB definition we have conformed to international standardisation guidelines and practices, made use of the existing management object space, and making it easier to migrate to a fully standards compliant solution once (if) the appropriate standards will be available and of cost-effective implementation.
• Definition of management requirements, functional areas. Driven by the results of the analysis tasks we have formulated a set of generic management functions within the framework of the manager-agent paradigm. This has provided us with the grounds for the designing of the isnMIB.
• Authoring of the MIB modules. After defining the management framework and describing the MIB modules we performed the authoring of the MIB in ASN.1 following the SNMPv2 SMI, as defined by the set of RFCs [8][9]. The MIB syntax has been verified using a MIB compiler.
• Management Scenarios and MIB revision A discussion on management scenarios was held, providing an input to the specifications for the design of the MUSIQ the management tools during the follow-on work-packages. The discussion around management scenarios was undertaken in parallel with the definition of QoS parameters, allowing us to revise the MIB under the light of the management framework and the refined requirements for the QoS parameters.
• QoS metrics definition. Once the MIB objects and the management functions were defined and revised - as result of the discussions held around the management scenarios -, a set of QoS indicators and metrics is defined, (section "QoS Metrics Definition"). These are high level parameters that attempt to model the QoS offered and seen under users and managers perspective. QoS indicators are defined throughout the hierarchical management architecture: more detailed parameters that are mostly targeted for use by the IS manager, while the QoS metrics are abstract and more end-user oriented. These parameters are the main contribution of this work and should be the goal output of any management application implementation.

• The first part of the document (Management Requirements and MIB definition) analyses the architecture associated to most Information Systems. Results of the IS functional analysis are presented under a management perspective. Configuration, logging and performance issues are examined for HTTP, ftp, WAIS and gopher servers. A synopsis of management requirements are given in section 5. We also present the results of the work performed on the analysis of existing MIBs (4) and the standardization activities that were undertaken within the project (8). A description of the isnMIB structure is done in section 7 and the detailed MIB description and authoring under Appendixes A and B.
• The second part of the document (3) addresses the definition of QoS and associated metrics. The results on the discussion on management scenarios are summarized in (1) and a set of QoS management procedures, indicators an metrics are identified and formally defined. These will be used as input for the management applications work-package to be undertaken under MUSIQ WP75.
• A "Conclusions" section summarizes the main results of this work
• References and related bibliography are presented at the "References - Bibliography" section.
• Appendix A identifies and analyses parameters that influence the behavior and performance of HTTP engines
• Appendix B discusses in more detail the alternative management architecture based throughout the hierarchy on SNMP for the interaction between the components (manager-to-agent and manager-to-manager communication). A second MIB module, the IS Manager MIB (ismMIB), is described here.
• Appendix C discusses MIB authoring issues. It describes the authoring guidelines adopted, the textual conventions defined and the tools used.
• Appendix D provides the ASN.1 description of the MIB modules produced within this task of MUSIQ.

A typical Information Service (IS) system consists of multiple components. The major components with which an IS is built are the IS system and the connecting network (WAN/LAN). To allow users retrieving information from the server they must be in possession of a client system connected to the network. This situation is illustrated in figure 1.

Figure 1: The Information Service components

Even though the DESIRE project is focused on WWW services, other information services like FTP, WAIS and gopher are considered since it is common practice to inter-link such servers for flexibility and organizational or performance reasons. Therefore, a decomposition of the building blocks for an Information Service is defined.

Figure 2: A simple IS System

Figure 2 illustrates the functional decomposition of an information system. Although, the client is also drawn, this document addresses only the server side of the information system. The server has four components which are generic elements in an information service: (1) the TCP-protocol stack, (2) the information transport protocol entity, (3) the information application and (4) the local data.

The TCP protocol stack

Figure 3: A PDU exchange using two different protocols.

The ITPE PDUs of the protocols are sometimes not directly exchanging the information (data), but also guide the information exchange (parameters of the transfer) or authorize the users accessing the Information Service. This difference is illustrated in the above figure 3 where an HTTP and an FTP example are shown. Both are seen from the application as one request/response cycle, although the FTP exchange does it in multiple return PDUs.

The information engine application

Figure 4: An IS System consisting of multiple components

For example (Figure 4), an IS system consists of two information entities: an HTTP server and FTP server. The HTTP server uses the HTTP protocol to publish static information through a set of HTML files while dynamic data are offered to the end-user through the server's connection with other applications/ servers. The FTP server provides access to a file archive through the FTP protocol. Through HTML documents and CGI or Java scripts the HTTP client application has access to an RDBMS, a text database with full text retrieval functionality and a search engine for searching the FTP archive or the HTML file space.

Figure 5: Example of an IS System

In order to effectively manage an IS system, it is required to rely on a set of management objects, mapping the functional behavior of the components identified in section 1.1 above. In addition to the IS specific management objects, we will need to rely on management objects that would mirror both the behavior of the system(s) on which the IS is running and the underlying network infrastructure.

Information Service Implementations

• Configuration and maintenance of an information server. This analysis will greatly assist in the definition of MIB objects by identifying hooks that will allow remote configuration and maintenance of the server and, if possible, the offered information content.
• Logging supported by the servers. The analysis of the server logs will provide the hooks for implementing remote monitoring through an agent/MIB interface.
• Performance issues. Identifying and studying the performance parameters will assist both in the MIB design and the definition of QoS parameters.

An important issue is whether all Information Services (HTTP, FTP, WAIS and Gopher) will be treated together as generic information services or as different cases in the configuration and logging related MIB objects. A uniform approach should be adopted in the MIB. However, in cases where no common ground is identified, service specific tables and objects may be defined. The main advantage of common, generic object groups is that new services can be added without changing the semantics of the MIB.

Configuration

Servers started by the inetd super-server have the advantage of reading their configuration files each time a client attempts to access their information (since inetd restarts them whenever they are needed). This allows changes in configuration files to take effect immediately. Standalone servers, on the other hand, require explicit restarting for configuration changes to take effect. Furthermore, a crashed standalone server will probably stay unnoticed and the service will become unavailable, whereas, in the inetd case fresh copies will be spawned on demand.

The type of server (standalone or inetd-started) is important to know for implementing remote configuration and maintenance. The existence of a MIB variable identifying the server type is essential. In addition, configuration changes made remotely to a standalone server should be followed by a server daemon restart (initiated by the agent). Restarting should be offered by the agent as an automated feature for remote configuration and as an option for resetting crashed servers, etc. However, restarting the server after each single SET operation on configuration MIB variables seems inefficient; time-out/grace period techniques could be used instead: the agent restarts the server when a grace period expires after a set of configuration changes. Restarting on demand could also be implemented through SETting specific MIB variables; this operation should, of course, be restricted to trusted entities.

WWW Servers

Objects associated with the remote configuration of http entities (with an emphasis on servers/proxies) will be defined in the MIB. Only generic parameters that are supported by all major servers will be considered. Implementation-specific parameters and options will only be included as variables only if they are considered extremely useful and expected to be supported by all vendors in the near future. All these should be generalized for the other information service entities that will be supported by the proposed management framework, i.e. ftp, wais, gopher. Note, also, that the analysis of configuration and logging mechanisms that is presented in this section will not only provide objects and requirements for the MIB design, but will also assist the instrumentation design phase of the agent implementation.

The following table summarizes and compares all the configuration variables for the HTTP servers mentioned above. In the case of the Netscape server the column of the table represents functionality, although the configuration and initiation of the processes takes place in a different way than the rest of the servers.

HTTP Servers	NCSA	Apache	W3C	Netscape
AccessConfig	X	X
AccessFilename	X	X		X
AddDescription	X	X		ObjectType
AddEncoding	X	X	X	ObjectType
AddIcon	X	X	AddIcon, AddIconToSTD	cindex-init
AddIconByEncoding	X	X
AddIconByType	X	X
AddLanguage	X	X	X
AddType	X	X	X	ObjectType
AgentLog	X	X		Addlog (record-useragent)
Alias	X		Map	NameTrans
AllowOverride	X	X
AlwaysWelcome			X
AuthDBMGroupFile		X
AuthDBMUserFile		X
AuthGroupFile	X	X		Authtrans(grpfile)
AuthName	X	X
AuthTrans				X
AuthType	X	X		Authtrans(auth-type)
AuthUserFile	X	X		Authtrans(userfile)
BindAddress	X	X
Chroot				X
CookieLog		X
DefaultIcon	X	X
DefaultType	X	X
DefProt			X
DELETE-script			X
DidAddHref			X
Directory	X	X	Protect, DirAccess	X
DirectoryIndex	X	X
DirReadme			X
Disable			X
DNSLookup			X	DNS
DocumentRoot	X	X		Document-root(root)
Enable			X
ErrorDocument	X	X		Error
ErrorLog	X	X	X	X
Fail			X
FancyIndexing	X	X	DirShowIcons, DirShowBrackets, etc.	cindex-init
Group	X	X	GroupId
HeaderName	X	X
IconPath			X
IdentityCheck	X	X	X
IndexIgnore	X	X
IndexOptions	X	X
Init				X
LanguagePriority		X
Limit	X	X
LoadObjects				X
LogFileDateExt			X
LogFormat		<User Specified>	<CLF or Older>, LogTime, NoLog	init-clf
MaxContentLenghtBuffer			X
MaxRequestsPerChild		X		ProcessLife
MaxServers	X	MaxClients		MaxProcs
MaxSpareServers		X
Meta-Dir			X
MetaSuffix			X
MinSpareServers		X		MinProcs
OnDeny	X
Options	X	X
OutputTimeOut			X
ParentGroupId			X
ParentUserId			X
Pass			X
PathCheck				X
PidFile	X	X	X	PidLog
Port	X	X	X	X
POST-script			X
PUT-script			X
ReadmeName	X	X
Redirect	X		X
RefererIgnore	X	X
RefererLog	X	X
ResourceConfig	X	X
RootObject				X
ScriptAlias	X		Exec	service(CGI)
ScriptTimeOut			X
Search			X
ServerAdmin	X	X
ServerName	X	X	HostName	X
ServerRoot	X	X	X
ServerType	X	X	X
Service				X
StartServers	X	X
SuffixCaseSence			X
TimeOut	X	X	InputTimeOut
TransferLog	X	X	AccessLog	Addlog(server-log)
TypesConfig	X	X
User	X	X	UserId	X
UserDir	X	X	X	unix-home, init-uhome
VirtualHost	X	X
Welcome			X

Proxy Servers	W3C	Netscape
Cache AccessLog	X	init-clf
CacheClean	X
CacheDefaultExpiry	X
CacheExpiryCheck	X
CacheLastModifiedFactor	X	lm-factor
CacheLockTimeout	X	lock-timeout
CacheNoConnect	X	connect-mode
CacheOnly	X	cache-mode
cache-protocols		X
CacheRefreshinterval	X
CacheTimeMargin	X
CacheUnused	X
CachLimit _1 & 2	X
CasheRoot	X	cache-root
CasheSize	X	cache-size
Cashing	X	init-cache
CollectGcMemoryUsage	X
ftp_proxy	X
Gc (garbage collection)	X
GcDailyGc	X	gc-times
gopher_proxy	X
http_proxy	X
init-proxy(log-format)		X
init-proxy(timeout)		X
KeepExpired	X
no_proxy	X	supress
NoCaching	X	cache-mode
top-dirs		X
wais_proxy	X

Most configuration variables supported by the majority of the http servers should be included in the MIB and / or used in the instrumentation of the agent implementation. For example parameters of importance that should be used: log file location (error log, access log), server PID file, user and group id, server name, server port number, document root directory, server type (standalone or not), maximum server processes/connections, caching parameters, etc.

Service access points

Exceptions to the addressing scheme above do exist, and many Information Services implement the exception. The current IP address space is becoming saturated, and `virtual' naming techniques have been implemented and are currently in use, leading to the virtual host concept, where a system may have multiple hostnames with the same IP-address. In such a system, various information transfer protocols can co-exist across different hostnames (virtual hosts) in the same physical networked machine (same IP address). As a result, the combination of IP-address and port-number is no longer uniquely identifying an Information Service.

Within the MIB definition a clear distinction should be provided on which the use of virtual host can be based. Combinations with IP-address, port-number and a hostname are possible. The MIB should reflect the concept of a virtual host through which information services are made accessible.

Logging

remotehost user authuser [date] "request" status bytes

• remotehost: the host name or IP number of the host where the request initiated.
• user: the remote login name of the user.
• authuser: the name as which the user authenticated himself.
• date: the date and time of the request.
• request: the exact request that was made by the client.
• status: the status code returned to the client.
• bytes is the content-length of the transfer.

As it is reported in the following paragraphs, some information servers optionally use the CLF in their log files, while others use similar formats.

It is desirable to use a CLF compliant format for log-tables in the MIBs designed.

HTTP

• access_log: it keeps information of all the requests satisfied by the server. Its format includes the host source of the request, date and time and the requested operation and file.
• agent_log: it logs the client software used for each request, from the UserAgent header, together with the time of the request.
• error_log: it logs error and status messages. More specifically it keeps Startup messages, Restart messages and Halt messages, debug dumps, clients which time out and abort, scripts which produce no output (malformed header from script), .htaccess files (these keep directory specific access directives) which attempt to override things they do not have permission to (as defined by access.conf), server bugs which produce a segmentation violation or bus error, user authentication configuration problems, `File Doesn't Exist' errors and resource limit errors.
• referer_log: it records referrer headers of client requests, that specify the resource from which the Request-URI was obtained.

• The Document Access log records accesses to the server's documents.
• The Proxy Access log, maintained only if the server is configured as a proxy, an additional file can be specified for logging just this kind of accesses.
• Cache access, there is also the ability to log separately any documents that were retrieved form the cache, instead of getting them remotely.
• Error Log, for recording possible errors messages.

The log format can be chosen between the Common Log Format and an older CERN format. Other configuration options give the opportunity to specify GMT or local time in the log files, a time and date log filename extension and whether logging will be suppressed for certain hosts or domains.

Netscape server

The Netscape Proxy Server logs Accesses, Errors and SOCKS requests. The logs are kept in a common log file or sent to the UNIX SYSLOG facility. The format of the logs can be either in the Common Log Format, or another, user specified format.

The http servers' log data can be processed off- or on-line to produce statistics for accesses on a per document or client/domain basis. Such statistics should be included in the MIB and generated by agent on demand, if the required processing permits, otherwise should be kept in memory and updated incrementally. Scripts (in Perl or UNIX shell scritps) that provide this functionality are included in most http server distributions and various such custom tools are available as freeware / shareware. It would, also, be useful to provide an SNMP interface to the actual logs through the MIB, i.e. the actual logs are offered to the manager as tables and the agent responds to the requests of table entries by retrieving the appropriate lines from the log files. Indexing and caching can be used to improve performance without imposing high storage and processing power requirements on the agent.

FTP

The WU Archive FTP daemon provides enhanced logging capabilities including:

• Individual user command logging. The server can be configured to log any user commands (real, guest, or anonymous), not only anonymous.
• Transfer logging. Like command logging it is performed in a per user basis. Direction of transfers to log is also configurable (upload, download). Transfer logging does not use SYSLOG; output is stored in a file (xferlog). The entries in the log file have the following format:

<date & time> <transfer duration in sec> <client ip address>
  <transfer size in bytes> <file path / original filename>
  <ASCII/BINARY mode> <on the fly Compression, Taring, both or none>
  <Ingoing/Outgoing> <Anonymous/Guest/Real user> <Authentication
  type: 0-none 1-RFC 931> <authenticated user: *-if no
  authentication userID-authentication used>

<server PID>: <sequence number>: <date & time>: <code>: <message>

<date & time> <server PID> <client site> <client action>

A client action may be an retrieval of a document, an error, etc. Common values are:

• Root connection: connection to the root directory of the server.
• retrieved directory <dir>: the client requested the contents of <dir>.
• retrieved file <file>: the client retrieved the reported file.
• retrieved binary file <file>: retrieval of binary or image file.
• search<database> for <keyword>: database searching.
• retrieved ftp <host@path>: retrieval of file through an ftp link.
• Executed <script>: the client selected an exec link.
• Client went away: client disconnection while the server was sending data.
• System Load Too High: rejected connection request due to connection limit.

The Gopher log file can be processed to extract access information (top hosts & domains), access load and other protocol statistics (percentage of search/read/browse/ftp requests.

Security Wrappers

Such wrapper programs can be used in the agent/MIB implementation for collecting access and/or limited protocol statistics, perform access control and/or logging on behalf of servers that do not support such functionality. Furthermore, since most IS nodes use wrappers for security, the MIB should include objects for monitoring (or even configuring) their settings (service access restrictions at the system level).

Performance Issues

On the other hand running server's standalone is not always optimal, especially for low access statistics. Having a server running as a standalone daemon, with usually more than one processes spawned even when idle, consumes valuable resources for just waiting client requests. When the load is low the overhead of inetd starting a server process can be considered insignificant and overall performance is improved. Another disadvantage of standalone servers is that crashed processes are not automatically detected and the service becomes unavailable, whereas the inetd started server will spawn fresh copies at every request.

Access limits

Objects allowing the monitoring of system resources and their usage should be included in the MIB. Objects that present the running status of servers (standalone/inetd running server, number of current processes, etc.) and allow remote configuration, are useful for determining offered quality and server potential to adapt to higher loads. Since the system to be managed (a international web of information servers) is characterized of a high distributed nature the MIB in design and the associated architecture should support distributed and hierarchical management for achieving consistent monitoring, planning and control in various levels and wide-area scale.

Management of Information Systems

The target system we aim to manage is quite distributed in various levels. First, at the system level we have more than one, usually heterogeneous, information server daemons, associated and linked in various ways and directions. Then, in the network view, there exist a multitude of such "information nodes" with different degrees of offered quality, various information sizes, types (static, active, temporal, etc.) and topics. Managing such a highly distributed system is quite a challenge that could not be met successfully in a local scale. In the following paragraphs, we present an overview of management architectures in an attempt to identify the most suitable one for our target system.

Different approaches and architectures for management systems are currently being used or proposed. Three approaches seem to prevail [[15],[25]]: (a) the centralized, (b) the distributed (peer systems) and (c) the hierarchical architectures. A fourth architecture, the network of managers, combines features from (b) and (c). The systems mainly differ in the number of managers used and their degree of interaction and independence.

Centralized approach

Figure 4: (a) Centralized manager and (b) Platform approach

A variation of the centralized architecture is the platform approach [15] (figure 4(b)). The single manager splits into two parts: the management platform and the management applications. The platform offers a first stage of processing of the management data, being concerned mainly with information collection, provides key management services like monitoring and control, throughput calculation etc., and hides the underlying management protocols offering an abstract view to the applications. The applications operate in the second data processing level, handling decision support and higher functions than information gathering and simple calculations. The two parts communicate through a common application programming interface (API). This architecture offers easier maintenance and expandability and simplifies development of integrated applications in heterogeneous, multi-vendor, multi-(management)protocol environments. Heterogeneity and protocol complexity is handled once in the platform level, not in every application. However, the limited scalability is inherent in the centralized structure. In addition, the platform proves to be a serious bottleneck when the number of applications increases.

Distributed approach

Figure 5: Distributed (peer-manager) architecture

Figure 6: Hierarchical architecture

A combination of the distributed and hierarchical architectures, the network architecture [15] is sketched in Figure 7. Both the manager per domain (element managers) and manager of managers (integrated managers) concepts are applied. Instead of a purely peer-systems or hierarchical structure, the managers are organized in network scheme. This approach combines features and advantages from both architectures, preserves the scalability and exhibits better functionality and adaptation in diverse, non-canonical environments. An extension of the network architecture that integrates the platform approach at the manager level in a scaleable way is presented at [40].

Figure 7: Network architecture

The advantages of distributed management architectures provide attractive alternatives for managing the distributed network of information servers introduced by the DESIRE project. The proposed architecture must have a distributed, hierarchical nature that will allow efficient monitoring, planning and control in different levels of abstraction and geographical areas. Minimizing WAN management traffic and manager response should be an important factor in selecting an architecture model.

Existing MIBs

The aim of this chapter is to report on the applicability of the existing standards track MIBs, to find how all of them can be brought together if possible, to search their pros and cons, to avoid overlap of managed objects, to propose additional objects that are needed to meet the requirements and guarantee that effective management of the Information Systems will be approachable.

The CEO Project MIBs

The following three MIBs were produced:

• HTTP MIB [15], which reflects the low level transactions and may be implemented almost totally through the Common Log Format file.
• Retrieval Services MIB [16], which de-couples the Information Store MIB from the underlying transport MIB (the HTTP MIB).
• Information Store MIB [17], which handles managed objects that are relevant to documents in the information store, as well as information regarding the applications composing the information service.

The idea behind the three MIBs was to decouple the details of the communication protocol from retrieval services (that could be applied to any other underneath information communication protocol) and the way information is organized. In this way, a modular system is specified, where ftp or other can replace http.

The CEO HTTP MIB

The httpSystem group contains generic management information and configuration information about the http protocol entities of a system. These entities exchange HTTP messages (PDUs) between each other in order to transport information. The httpSystem group contains the httpEntitytable maintaining generic administrative information about the http Servers and Clients present on the system. Such information is a unique identifier of the Server or Client, the protocol implemented by the entity, a textual description of the http Server or Client, a textual identification of the contact person, a textual description of the protocol version implemented, a textual description of the protocol implementor, a textual description of the implementation version, an authoritative identification for the private MIB of the particular http Entity, the DNS address of the http Entity, the TCP port at which the http Entity listens, the IP address at which the http Entity listens, the value of sysUpTime at the time the http Entity was last initialized and an identification of the role of the http Entity as server, client, proxy or cachingProxy.

Generic administrative information, such as implemented protocol, engine description, contact name, etc. and configuration information such as IP address, the port in use, role of the entity (server, client, proxy, cachingProxy) etc. are desirable for management of Distributed Information Systems. The centralized configuration management of distributed information servers is a major requirement of IS managers.

The httpStatistics group contains management information concerning the utilization of the http protocol entity. This group contains three tables: the httpSummarytable, the httpRequesttable and the httpResponsetable.

The httpSummarytable provides overview statistics for the http protocol entities of the specific system. Such statistics are the total number of requests generated or received, the total number of request errors detected, the total number of requests discarded, the total number of responses generated or received, the total number of response errors detected, the total number of responses discarded, the total number of unknown messages received, the total number of bytes received and generated and the total number of time-outs for each http entity of a particular system.

The httpRequesttable provides detailed request statistics for the http protocol entities. This table keeps the number of requests received/generated and the time the last request was received/generated for each request method and http protocol entity of a particular system.

The httpResponsetable provides detailed response statistics for the http protocol entities on the particular system. This table keeps the number of responses received/generated and the time the last response was received/generated for each type of response received/generated by http protocol entities of a particular system.

Statistics on the network traffic transmitted and/or received by HTTP entities are useful for the estimation of the quality of service the information server is providing or the client is receiving.

The httpTimeOuts group contains management information about the time-outs occurred with the protocol entity. This group contains a scalar object, the httpTimeouttableSize with the number of entries in the httpTimeouttable, and the httpTimeouttable providing detailed time-out statistics for the http protocol entities of the particular system. This table keeps the time when the time-out occurred with a remote entity and the address of the remote entity for all the entities of the system. Through the scalar object the table may be resized by the Network Management System.

Statistics on the number of time-outs occurred with remote HTTP entities are also useful for the estimation of the quality of service the information server is providing.

The CEO Retrieval Service MIB

The rsStatistics group, contains management information about the service primitives that are executed on the HTTP Service Provider. The rsStatistics group is composed of four scalar objects the rsTotalRequests, which is the total number of request service primitives that have been executed on the HTTP service provider, the rsTotalIndications, which is the total number of indication service primitives that have been executed on the HTTP service provider, the rsTotalResponses, which is the total number of response service primitives that have been executed on the HTTP service provider and the rsTotalConfirmations, which is the total number of confirmation service primitives that have been executed on the HTTP service provider.

The rsQoS group, contains management information about the provided QoS of the HTTP Service Providers. This management information represents the performance of the underlying network. The QoS parameters that are provided are: the transport delay, the number of errors, the number of time-outs and the throughput. The rsQoS group is composed of two tables, the rsDelaytable and the rsThroughputtable and two scalar objects, the rsNumberOfErrors and the rsNumberOfTimeouts. The rsDelaytable keeps track of the delays, which occurred, during transport of information, between a source and a destination. The rsNumberOfErrors gives us the total number of errors that have occurred. The rsNumberOfTimeouts gives us the total number of time-outs that have occurred. The rsThroughputtable keeps track of the data throughput with a certain client.

All objects included in this MIB are essential towards the effective management of distributed information services.

The concept of the CEO Retrieval Service MIB is similar to the Network Services Monitoring MIB (see section 4.9.1) containing elements common to the monitoring of any network service application.

A combination of the two MIBs is necessary for the complete monitoring of network service applications.

The CEO Information Store MIB

The IS MIB module is composed of four groups, the isGeneral group, the isAccess group, the isErrors group and the isDocuments group.

The isGeneral group. This group contains overall administrative data. There are static data, uniquely identifying the IS data, and two tables, the isApplDependancytable and the isTopictable. Such static data are an administratively-assigned name for the Information Store, a textual identification of the responsible organization for the IS server, a textual identification of the contact person, the last initialization of the IS server and an indication of the set of media types that the IS server primarily offers. The isApplDependancytable contains managed objects, which apply to all different kinds of applications provided by the IS. Such managed objects are a distinguished name of the host on which the application is running and the application name, the process name of the application, the version of the application software, the last initialization of the application, the operational status of the network service application, the time that the application entered its current operational state, the time that this application last performed some activity and the total number of activities where the application has failed. The isTopictable contains textual description of the topics provided by the IS server.

A table keeping information about all background processes is attractive for the management of information services. Information servers often use several background processes in order to provide some services. Because of this dependencies develop among processes. These dependencies become critical when a particular process needs to be stopped, restarted or reconfigured. These dependencies need to be defined within a MIB, so that management applications can operate correctly with consistent and complete information.

The isAccess group, which provides general access information and access information organized by domain, day, most recent users, most frequent users. In this group, there are various scalar managed objects and four tables, the isDomaintable, the isAccessOfLastNDaystable, the isMostFrequentNUsertable and the isMostRecentNUsertable. Such scalar objects are the total number of accesses done at the IS, the total number of bytes transferred and received by the IS, the number of entries which is contained in the accessOfLastNDaystable, the number of entries which is contained in the isMostFrequentNUsertable, a field with which a new "most frequent N user table" can be made, the universal date and time for the last time, that the isMostFrequentNUsertable was refreshed, the number of entries which is contained in the isMostRecentNUsertable. The isDomaintable keeps track of the number of accesses done from a specific domain. The isAccessOfLastNDaystable is a Top N table of the number of accesses, on a day to day basis, that have been done in the past. The isMostFrequentNUserTable is a Top N table of the number of accesses, that have been done in the past, from a specific user. The isMostRecentNUsertable is a Top N table with the N most recently accessed documents.

The isErrors group, which contains management information about the errors that occurred in the Information Store. In this group, there is a single table, the isErrortable. This table keeps track of the description of the errors, which occurred during accesses of the IS, the number of occurrences of particular errors and the time at which the error last occurred.

The isDocuments group, that contains management information about currently available documents on the Information Store server. The information is kept in the isDocumenttable containing the name of the document, the number of accesses, the access rights, the document size, the document type, the date and time of the last update and the number of accesses since the last update, the date and time of the last access and any associated errors.

The HTTP-interest group

This MIB consists of two groups, the xxxSystem group and the xxxStatistics group. The xxxSystem group, which contains management information about the xxx protocol entity. In the xxxSystem group, there is a table, the xxxEntitytable, containing details about the xxx Servers and Clients present in the system. Such details are a textual description of the xxx Server or Client, an authoritative identification for the entity, a textual identification of the contact person, an identification of the primary protocol in use, a textual description of the version of the implemented protocol, the fully qualified domain name by which this entity is known, the transport address at which the xxx entity listens for requests or responses, the primary port used to communicate with this entity and an identification of the role of the xxx entity as server, client, proxy or caching proxy.

The xxxStatistics group, which contains management information concerning the utilization of the xxx protocol entity. The xxxStatistics group contains the following four tables and a few scalars objects:

• the xxxSummarytable, providing overview statistics for the xxx protocol entities on this system.
• the xxxRequesttable, providing detailed request statistics for the xxx protocol entities on this system.
• the xxxResponsetable, providing detailed response statistics for the xxx protocol entities on this system.
• the xxxTimeouttable, providing detailed time-out statistics for the xxx protocol entities on this system.

Other differences between the two MIBs are the following:

• The HTTP-MIB contains a few more objects in the httpEntitytable, which are the httpEntityVendor, the httpEntityVersion, the httpEntityInitialisation. These objects have been removed from the latest revision of the XXX-MIB.
• The XXX-MIB contains one more object in the httpEntitytable, the xxxEntityName.
• The HTTP-MIB contains two more managed objects in the httpSummarytable, the httpSummaryResponseErrors and the httpSummaryTimeOuts.
• The XXX-MIB contains two more managed objects in the xxxRequesttable, the xxxRequestInBytes and the xxxRequestOutBytes. These objects have been added to the latest revision of the XXX-MIB.
• The XXX-MIB contains two more managed objects in the xxxResponsetable, the xxxResponseInBytes and the xxxResponseOutBytes. These objects have been added to the latest revision of the XXX-MIB.
• The HTTP-MIB has organized all the time-out information for each of the HTTP entities into a group. The XXX-MIB keeps all the time-out information under the statistics group.
• The XXX-MIB contains the xxxTotalTimeouts, which is the total number of timeouts for all xxx entities. The HTTP-MIB contains the httpTimeouttableSize, which is the number of the last Timeouts contained by the httpTimeOuttable.

• The system group which provides general administrative information about the system in which the MIB resides.
• The interface group which provides information of all the attached intferaces of the system.
• The address translation group which provides a mapping between the IP-address and the physical hardware address.
• The IP group which provides basic managed objects for management of the IP-layer.
• The ICMP group which provides basic information of the ICMP functionality in the IP-layer.
• The transport control protocol group which provides management information of the TCP-layer.
• The used datagram protocol group which provides management information of the UDP-layer.
• The EGP group which provides mandatory management information for the EGP-protocol.
• The transmission group which provides a hook for allowing physical media management.
• The SNMP group which provides management information of the SNMP protocol.

The system application installed group provides information about packages and all of their component elements such as executable and configuration files found on a system. This group consists of two tables, the sysApplInstalledtable and the sysApplCfgElmtable.

The sysApplInstalledtable provides information on installed applications. Such information is the manufacturer of the software application, the software application name, the version, the serial number, the date and time of the installation and the path name where the executables are stored for the application. The sysApplCfgElmtable provides information regarding the executables and non executable files which collectively compose the application. This information is discoverable provided that certain conventions are followed by administrators during the installation of host application software.

The sysApplCfgElmtable contains information such as, the name of the elements, the type of the element (executable, nonexecutable), the date and time of the installation, the full path name of the file, the size of the file in Kbytes, the role of the element (executable, exclusive, interesting, required, dependent).

The system application run group contains information about applications, which are currently running or have run in the past. This group consists of two pair of tables (four tables), the sysApplRuntable and the sysApplPastRuntable, the sysApplElmtRuntable and the sysApplElmtPastRuntable, and seven scalars managed objects.

The sysApplRuntable contains the host applications which are currently running. An entry is created in this table for each instance of an application which is running (when the application started). This table contains information such as a pointer to the installed application table, the date and time that the application was last started and the current state of the running application (running, runnable, waiting, exiting).

The sysApplPastRuntable contains the host applications which have run in the recent past. An entry is created in this table for each instance of an application which has been run (when the application terminated). This table contains management information such as a pointer to the installed application table, the date and time that the application was started, the exit state of the application (complete, failed), the date and time that the application exited. table rows are removed from the sysApplPastRuntable according to the values set in two scalars, the sysApplPastRuntableSizeLimit, which is the maximum table size, and the sysApplPastRuntableTimeLimit, which the maximum age of the table entries. These two scalar objects are included in order to allow user control of the size and resources consumed.

The sysApplElmtRuntable contains entries of applications that execute one of their elements. It is possible to have multiple entries in this table for each application. Entries in this table are tied to entries in the sysApplRuntable so that an administrator can determine which elements are running with each instance of application execution. This table contains information such as the time the process was started, the time the process ended, the state of the running process (running, runnable, waiting, exiting), the full path name of the process, the starting parameters for the process, the type of the executable (unknown, operatingSystem, deviceDriver, application), the total CPU time of the running process, the average memory in Kbytes used by this process, the number of transport connections used by the process, and the number of files open by the element.

The sysApplElmtPastRuntable contains table rows corresponding to instances of processes which have previously executed on the host. Entries to this table are made when the process has terminated. This table contains information such as, the time the process was started, the time the process ended, the state of ending (completed, failed), the full path name of the process, the starting parameters for the process, the type of the executable (unknown, operatingSystem, deviceDriver, application), the total CPU time of the running process, the average memory in Kbytes used by this process, the number of transport connections used by the process, and the number of files open by the element. table rows are removed from the sysApplElmtPastRuntable according to the values set in two scalars, the sysApplElmtPastRuntableSizeLimit, which is the maximum table size, and the sysApplElmtPastRuntableTimeLimit, which the maximum age of the table entries. These two scalar objects are included in order to allow user control of the size and resources consumed.

There are three additional scalar managed objects. The sysApplPastRun-tableItemsRem, which is a counter of entries removed by the agent during its lifetime from the sysApplPastRuntable because of the table size limitations as set in the sysApplPastRuntableSizeLimit. The sysApplElemPastRuntableItemsRem, which is a counter of entries removed by the agent during its lifetime from the sysAppl-ElemPastRuntable because of the table size limitations as set in the sysAppl-ElemPastRuntableSizeLimit. The sysApplAgentPollInterval, which is the minimum time in seconds that an agent will poll the status of the managed resources.

The University of Lisbon WWW MIB

The proposed MIB consists of three groups: the general group, the client group and the document group.

• The General group, contains variables providing information on last requests and total accounting. This is done by keeping the extracted information from the last record in lastHost, lastTopDomain, lastTimeStamp, lastOperation and lastDocument. The total accounting is gathered and stored on totalOutOctets, totalRequests, totalDocuments and totalTopLevels.
• The Client group, which provides counters to monitor the origin of the requests. These counters can be accessed by traversing the TopLevelDomainRequests and the HostRequests tables. Each row has the identification for the table item, the number of requests and the total bytes that they represent.
• The Document group, which permits monitoring of document accesses. There are managed objects providing the name of the document, total requests and amount of octets sent.

The Host Resources MIB consists of the following six groups:

• The Host Resources System Group: which has several objects that describe overall system parameters such as the number of users and processes, and where the operating system is loaded from.
• The Host Resources Storage Group: which provides utilization information on all forms of storage on the system, including RAM, disk drives, and, memory buffers.
• The Host Resources Device Group: which provides configuration and fault information about all devices on the system. Some types of devices such as printers and disk drives have more detailed information specified than others. For example, one kind of device is a network interface. MIB-II already defines extensive information on interfaces, so the devices group really doesn't need to duplicate those features.
• The Host Resources Running Software Group: which lists the software running on the system.
• The Host Resources Running Software Performance Group: which provides performance data about each piece of software running on the system
• The Host Resources Installed Software Group: which lists all the software installed locally on the system

The Host Resources MIB provides many types of functions [41], primarily in the fault management, configuration management, and, performance management areas.

The Host Resources MIB helps a number of system management jobs that a network manager might face. With this MIB module, a network manager is able to download an inventory of all equipment on various LANs across an organization, without regard to what types of systems the equipment is attached to. In addition to determining how much memory and disk is installed in each computer, the types and versions of other hardware and software components can be retrieved. Obsolete versions of software or hardware can be flagged and incompatibilities between various hardware and software components can be detected. Disk drives can be monitored to make sure that routine backup procedures are being followed and that the disks are not running out of space.

Textual information on a system, such as that found in file names, is returned in a format that allows any international language or character set. This allows the MIB module to monitor systems that have been internationalized, and (again) shows that SNMP is suited for this task.

The FTP MIB

Hierarchical management of information services seems appealing since it permits statistics collection on the information flow in each domain and among domains. It is possible to control the information flow in regional, national or international level and unify the administration of homogeneous (in terms of content, configuration or target user group) groups of information servers.

In order to manage the FTP and file servers that are accessible through this protocol, a ftp object group is defined. This object group is composed of four sub-groups: the general, manager, server and an extra sub-group.

The general sub-group, which is installed in every managed system that supports FTP, contains management information about the software used for file transfers, the number of sent and received messages, the number of opened connections (FTP commands and data transfers), the duration of the connections and the number of errors (addressing or connection errors and bad access authorizations).

The manager specific sub-group, which is installed in every system which supports an FTP manager software, contains management information about the manager (description), the connections and the FTP messages that leave the manager's domain, the status and address of the FTP servers that stay in the manager domain. These objects are similar to the General Base objects.

The server specific sub-group, which is installed in every managed file server, contains management information about the file servers (description), the number of FTP connections besides the sent or received messages, including error messages and the server's files. The table that describes the server's files contains information about the type and size of the files, the access permissions, the date that they were saved and their version.

The extra sub-group contains managed objects for the control of the information flow between two specific systems. It contains obtains that describe the systems and the FTP connections and messages between the systems.

The Relational Database Management System MIB

The structure of the RDBMS-MIB reflects the separation of the database and the access mechanism. The RDBMS-MIB generally contains four tables describing the database, four tables describing the server and another table providing the relationship between described database servers and databases.

The group database tables

The group consists of: the installed database table (rdbmsDbtable) describing the general management data of the database, the database information table (rdbmsDbInfotable) describing information about the presence on a host which is information needed when the database is opened for use, the database parameter table (rdbmsDbParamTable) describing the parameter for the configuration of the database (This table describes on a per entry basis for each parameter), and the database resource limits table (rdbmsDbLimitedResourceTable) providing per database the limitations in resources (The provision of this information may only be done if the database is in operation).

The database server group

The definition of a few very important traps may be useful towards the effective management of distributed information services.

Mail and Directory Management

This MIB may be used on its own for any application. This MIB is also designed to serve as a building block which can be used in conjunction with application-specific monitoring and management. Two examples of this are MIBs defining additional variables for monitoring a Message Transfer Agent (MTA) service or a Directory Service Agent (DSA) service.

A table, called applTable, is defined which will have one row for each network service application running on the system. It keeps statistics of the current number of active associations and the total number of associations since application initialization. The assocTable augments the information in the applTable with more detailed information about active associations.

The Mail Monitoring MIB

The MIB is composed of a basic table, the mtaTable, holding information specific to a MTA, the mtaGroupTable, holding information specific to each MTA group, and the mtaGroupAssociationTable, holding information regarding the associations for each MTA group.

The X.500 MIB

The managed objects included in this MIB are divided into three tables: the dsaOpsTable, the dsaEntryTable and the dsaIntTable. The dsaOpsTable provides summary statistics on the accesses, operations and errors. The dsaEntriesTable provides summary statistics on the entries held by the DSA and on cache performance. The dsaIntTable provides some useful information on the interaction of the monitored DSA with peer DSAs. The dsaIntTable provides a useful insight into the effect of neighbors on the DSA performance. The table keeps track of the last "N" DSAs with which the monitored DSAs has interacted (attempted to interact), where "N" is a locally-defined constant.

A MIB aiming to the management of information services should include objects (number of entries cached, cache hits, etc.) about the performance of caching mechanisms used. This could be done as for example in the X.500 MIB (dsaEntriesTable).

The Mail and Directory Alarms MIB

An equivalent alarm mechanism or set of alarm mechanisms may be used in order to support a hierarchical structure of managers. Intermediate managers will generate alarms towards other higher-level managers, when abnormal events occur.

Netscape MIB

By using the Netscape MIB, one can see administrative information about the Netscape server and monitor the server in real-time. There are three tables providing this information the httpEntityTable, the httpStatisticsTable and another httpStatisticsTable providing NT specific statistics on the Netscape server.

The httpEntity table provides several static information on the Netscape server (a description of the server, the HTTP version number, the server software version number, the methods supported by the server, the maximum and the minimum number of active processes on the server, the maximum and the minimum number of active threads on the server, etc.).

The httpStatisticsTable provides several statistics on the Netscape server (the status of the server, the number of server's idle threads, the number of server's threads that are processing requests, the total number of requests received/generated, the total number of request errors detected, etc.).

The MIB from Netscape provides several static and statistics information on the Netscape server. All MIB variables are read-only and the network manager is not able to configure the server through SNMP. Static variables are the ones included in most of the http MIBs found in the literature (CEO HTTP-MIB, XXX-MIB, WWW-MIB, ISN-MIB).

The following diagram illustrates how Netscape implements basic SNMP managemnt functionality in their product:

Figure : The Netscape MIB implementations

Concluding, the MIB from Netscape provides several static and statistics information on the Netscape server. All MIB variables are read-only and the network manager is not able to configure the server through SNMP. Static variables are the ones included in most of the http MIBs found in the literature (CEO HTTP-MIB, XXX-MIB, WWW-MIB, ISN-MIB).

Microsoft Internet Information Server MIB

The MIB of the Microsoft Internet Information Server includes managed objects for all information services (FTP server, Gopher server, and HTTP server). In this MIB there are several objects monitoring cache (Cache Hits, Cache Hits %, Cache Misses, Cache Size, Cache Used, Cached File Handles, etc.). Concerning HTTP MIB, there are mainly objects collecting statistics. Counters are organized into sections for the service measured.

Generic counter are providing information on total cache hits since service startup, ratio of cache hits to all cache requests, total cache misses since service startup, the configured maximum size of the shared HTTP, FTP, and Gopher memory cache, the current number of bytes containing cached data in the shared memory cache, etc. As far it concerns the FTP server, several counters are providing information on the rate at which data bytes are received and sent by the FTP server, the total number of connection attempts that have been made to the FTP Server, the current Number of anonymous users currently connected to the FTP server, the total files uploaded to and downloaded from the FTP server since service startup, the largest number of anonymous users simultaneously connected to the FTP server, etc.

As far it concerns the Gopher server, several counter are providing information on the following. The total number of connections aborted due to error or over-the-limit requests made to the Gopher server, the rate at which data bytes are received and sent by the Gopher server, the total number of directory listings sent by the Gopher server since service startup, the total number of logon attempts made by the Gopher server since service startup, the total number of searches performed by the Gopher server since service startup, etc.

As far as concerns the HTTP server, information is provided on the rate at which data bytes are received and sent by the HTTP server, the total number of CGI requests executed since service startup, the rate at which HTTP requests are currently being handled, the current number of connections to the HTTP server, the number of requests that couldn't be satisfied by the server because the requested document could not be found, the number of HTTP requests using the POST method, etc.

Concluding, the MIB from the Microsoft Internet Information Server includes managed objects for all information services (FTP server, Gopher server, HTTP server). In this MIB there are several objects monitoring cache (Cache Hits, Cache Hits %, Cache Misses, Cache Size, Cache Used, Cached File Handles, etc.). Concerning HTTP MIB, there are mainly objects collecting statistics.

Synopsis - Management Requirements

• It is desirable to unify information service (IS) entities in the MIB. A uniform approach should be adopted, wherever possible, that treats all IS entities through a common representation regardless of information protocol (http, ftp, wais, gopher) and even protocol role (server, proxy, gateway, client, etc.). However, in cases where no common ground can be identified, service / role specific objects should be defined. The main advantage of a common interface and representation is that different implementations and new services can be added without the need of recompiling the MIB.
• The type of IS server (standalone or inetd-started) is important to know for implementing remote configuration and maintenance and an object indicating it should be included in the MIB. In addition, configuration changes made remotely to a standalone server should be followed by a server daemon restart (initiated by the agent). Restarting should be offered by the agent as an automated feature for remote configuration and as an option for resetting crashed servers, etc. However, restarting the server after each single SET operation on configuration MIB variables seems inefficient; time-out/grace period techniques could be used instead: the agent restarts the server when a grace period expires after a set of configuration changes. Restarting on demand could also be implemented through SETting specific MIB variables; this operation should, of course, be restricted to trusted entities.
• Objects associated with the remote configuration of IS entities (with an emphasis on servers/proxies) will be defined in the MIB. Only generic parameters that are supported by all major products will be considered. Implementation-specific parameters and options will only be included as variables only if they are considered extremely useful and expected to be supported by all vendors in the near future. That the analysis of configuration and logging mechanisms that is presented in this document will assist the instrumentation design phase of the agent implementation. For example important parameters are: log file locations, server process ID file, user and group id, server name, server port number, document root directory, server type (standalone or not), maximum server processes/connections, caching parameters, etc.
• It is desirable to use a CLF (common log format) compliant format for log-tables in the MIBs designed. The http servers' log data can be processed off- or on-line to produce statistics for accesses on a per document or client/domain basis. Such statistics should be included in the MIB and generated by agent on demand, if the required processing permits, otherwise should be kept in memory and updated incrementally. Scripts (in Perl or UNIX shell scritps) that provide this functionality are included in most http server distributions and various such custom tools are available as freeware / shareware. It would, also, be useful to provide an SNMP interface to the actual logs through the MIB, i.e. the actual logs are offered to the manager as tables and the agent responds to the requests of table entries by retrieving the appropriate lines from the log files. Indexing and caching can be used to improve performance without imposing high storage and processing power requirements on the agent. The FTP log data can be used to compile similar statistics, like the top most-downloaded files, counters of total bytes transferred, the most busy hours of the day, average transfer delays and throughput, etc. The WU ftp distribution includes scripts which provides such functionality. The WAIS log file can be processed to extract access information (top hosts & domains), access load and other statistics. In a similar way, the Gopher log file can be processed to extract access information (top hosts & domains), access load and other protocol statistics (percentage of search/read/browse/ftp requests.
• Security wrapper programs can be used in the agent/MIB implementation for collecting access and/or limited protocol statistics, perform access control and/or logging on behalf of servers that do not support such functionality. Furthermore, since most IS nodes use wrappers for security, the MIB should include objects for monitoring (or even configuring) their settings (service access restrictions at the system level).
• Objects allowing the monitoring of system resources and their usage should be included in the MIB. Objects that present the running status of servers (standalone/inetd running server, number of current processes, etc.) and allow remote configuration, are useful for determining offered quality and server potential to adapt to higher loads.
• Available network bandwidth may prove more critical than system resources for the availability of the service and the quality offered to the end-user. This applies not only to the site WAN connection, but also to all intermediate connections. Thus, when designing and/or managing an international, distributed information services system spanning on a wide area, network planning and monitoring becomes essential to the quality delivered. The MIB in design and the associated management architecture should support distributed and hierarchical management for achieving consistent monitoring, planning and control in various levels and wide-area scale.
• Any MIB objects associated with protocol parameters and features should have a generic flavor and not be version-specific. If certain version-specific features need to be maintained, the related objects should be organized in version-specific groups.
• One or more objects indicating the information entity role (proxy, gateway, tunnel or other server) of the system would be useful. This could be a single object or a table with entries containing role characterization and associated port number (one entry per entity running on the system).
• An object identifying the set of protocol versions supported by the server(s) running on the system should be included in the MIB.
• The agent should be able to provide information on the content coding values that every IS server on the system understands.
• The agent should maintain MIB objects identifying the media type values supported by the server(s) of the system.
• A MIB object (variable or table) could specify the character sets that are used in current server's documents. This information should be provided in a per server basis.
• Supported (implemented) request methods should be maintained in the MIB for every http entity running on the system. This should be done in a way that allows the addition of future methods, without requiring MIB re-compilation.
• It would be useful to keep supported error codes in the MIB (value and/or text mnemonic) for informational reference purposes in a form that new entries can be added (e.g. table and not predefined constants). Support of error and status codes introduced by later protocol versions and implementations will be easily supported by adding entries to a table.
• As it was mentioned above, implemented request methods should be maintained in the MIB for every server running on the system. This could be extended to provide information on a per-resource basis (like the information provided by the Allow header field) in association with access control restrictions. Additional information like content coding and media types could also be included for every resource (like the information given by the Content-Coding and Content-Type header fields).
• It would be useful for remote configuration and information management if the agent provided temporal content-specific data, like the information provided by the Expires and Last-Modified header fields on a per-resource basis.
• Logging authenticated accesses & failures and providing a MIB interface to logs (tables with log-entry objects) would allow remote security monitoring (via remote management applications). However, access to the MIB log objects should be restricted and not publicly readable.
• If access to the MIB can be considered secure, it would be useful to provide access to the user ID / password server database through a MIB table.
• The list of all accessible system directories through the system HTTP server(s) should be provided in the MIB. Each entity should have the form of a <absolute system path>/<URI> pair. Remote management applications could scan these table and identify potential security problems.
• MIB objects providing system information that could be used by a potential attacker for compromising system security should be restricted and not publicly readable.
• The advantages of distributed management architectures provide attractive alternatives for managing the distributed network of information servers introduced by the DESIRE project. The proposed architecture must have a distributed, hierarchical nature that will allow efficient monitoring, planning and control in different levels of abstraction and geographical areas. Minimizing WAN management traffic and manager response should be an important factor in selecting an architecture model.

Several MIBs are defined in the literature that are relevant to the management of information services. The review of these MIBs provides us with several points that should be considered in the design of the proposed management framework and the MIB:

• Generic administrative information are desirable for the management of Distributed Information Systems. The centralized configuration management of distributed information servers is also a major requirement of IS managers.
• Statistics on the network traffic transmitted and/or received by HTTP entities are useful for the estimation of the quality of service the information server is providing or the client is receiving. Statistics on the number of time-outs occurred with remote HTTP entities are also useful for the estimation of the quality of service the information server is providing.
• Hierarchical management of information services seems appealing since it permits statistics collection on the information flow in each domain and among domains. It is possible to control the information flow in regional, national or international level and unify the administration of homogeneous (in terms of content, configuration or target user group) groups of information servers.
• The definition of a few very important traps may be useful towards the effective management of distributed information services.
• A MIB aiming to the management of information services should include objects (number of entries cached, cache hits, etc.) about the performance of caching mechanisms used. This could be done as for example in the X.500 MIB.
• An alarm mechanism or set of alarm mechanisms may be used in order to support a hierarchical structure of managers. Intermediate managers will generate alarms towards other higher-level managers, when abnormal events occur.

• The manager polls the agents for retrieving data on:
  1. Information system architecture (components that make up a system and the relationship between them - the agent may be capable of automatic discovery or they will be provided by the administrator).
  2. System and information server performance. Such information should include service throughput (in service requests and bytes per sec.), error and timeout rates, service availability, server and system downtime, system resource utilization and others.
  3. Server errors and faulty conditions. The manager should monitor and try to analyze the errors and faulty conditions of the system and the servers. Errors could be categorized according to temporal parameters, service types or client domains aiming to identify error patterns or just sources and causes.
  4. Server security. The manager will be able to monitor server security at the system and mainly on the information server level. Remote configuration of security mechanisms should also be supported up to the point that it does not compromise the security of the system it tries to safeguard.
  5. Published information access statistics. The agent should provide a first approach in log processing, offering to the manager access statistics.
  6. Published information consistency and structure. The publish information structured should be checked by the manager (and the agent if the processing and storage requirements permit it). The manager should be able to retrieve information on the published document characteristics.
  7. Quality of service delivered to users, as perceived by the users. The manager monitors various QoS metrics in an attempt to record user satisfaction. In this way potential faults and/or bottlenecks, or other problems may be identified in advance and planning procedures may be more focused.
  8. User access patterns. The manager monitors the user accesses to the servers within the distributed information domain (the Paneuropean Researchers' Web designed by the DESIRE project), aiming to identify user access patterns for providing input to planning procedures (bandwidth planning & allocation, caching policy, caching proxy configuration, etc.).
• The manager provides new values to objects maintained by the agents for:
  9. Remote configuration of the server parameters. The manager reads and/or modifies server important configuration parameters through the agent.
  10. Change server process running status. The manager may kill and/or restart a server process if it runs standalone or modify the server running status from standalone to inetd-based or vice-versa.

The management of Information Services can not be realized without the manipulating of the two main actors: the information server and the information client. This fact identifies the two actors as potential locations for installing MIBs and agents that maintain and provide management information to the managers. Since it is not feasible to install agents to every node running clients the proposed agent and MIB modules aim at information server and offered services management. However, minimal client support is included and could be instrumented in the agent implementation.

Performance Requirements

Minimizing overall management traffic generated by the SNMP entities for manager-to-agent or manager-to-manager interaction is also a requirement, especially important at the WAN level. This is met, at least to an extent, by introducing a hierarchical, distributed model and by providing asynchronous notification functionality. The management applications (the core of the managers) that will be built to take advantage of the model, should rely as much as possible on these two features in order to minimize unneeded polling procedures, or limit them in local scope where more bandwidth is available.

Some groups of objects in the proposed MIB modules are involved with system and network security in a twofold way: they provide information on information engine access control and at the same time allow remote configuration of these security mechanisms. It is obvious that supporting configuration functionality may compromise system security unless the management protocol (in our design SNMPv2) provides a solid security model. Since SNMP security is not a resolved matter yet, the implementation of such functionality is left to be decided in the implementation or configuration of the agent, depending on whether the protocol security requirements are met. We expect that it will soon be resolved, since work is in progress and it is highly needed by the management community.

Architectural Requirements

Figure 3: The generic IS System with the managed objects

Figure X illustrates the managed objects reflecting the architecture of an Information Service.

• The TCP protocol stack can be managed by the objects already defined in MIB-II. This is a standard MIB used for any TCP/IP based system.
• Parts of the system can also be managed using objects already defined in the Host Resources MIB and in the System Application MIB. However, since that by the time the MIB for this workpackage was due to be finished the System Application MIb was not finished yet, this latter MIB is not used in the MUSIQ framework (even if some of its concepts were used).
• The Information Transport Protocol could be managed with the HTTP-MIB or XXX-MIB - both predecessors of a standards track MIB. However, this is still an on-going process, not in any standardization track, so it was decided to liaise with this activity but define independent managed objects for this project.
• There is no MIB available yet which defines managed objects for the Information Application. Therefore, managed objects should be added in the MIB.
• The local data storage is seen as the place of where Information can be retrieved from the service. The managed objects required for this part are not defined yet in other MIBs and, therefore, should be defined in our MIB.

The most important part of the group is the isnentityTable that maintains basic information on all the information entities running on the system that are being monitored by the agent. Apart from these parameters, the table provides the index for all tables with statistics and other management data on the entities. Each isnentityEntryprovides the following information:

• a unique index for the entity; the Application MIB (MADMAN) index is being used so that a 1-1 relation between the entity and the application in the MADMAN MIB is achieved (applIndex),
• an authoritative identification of the program entity, 0.0 if not provided by the vendor (isnentityOid),
• contact information for this entity (isnentityContact),
• the main protocol supported by the entity (isnentityProtocol); this is an "enumerated" type using officially assigned numbers for each protocol (as defined for example in the /etc/services UNIX file.
• the highest protocol version supported (isnentityProtocolVersion),
• the protocol role of the entity, e.g. server, proxy, etc. (isnentityProtocolRole),
• the transport address, i.e. ip address and port number (isnentityAddress).

The isnSummaryTable provides protocol summary statistics for the entities of the particular system. Each entry of the isnSummaryTable consists of the following objects:

• a table index; this is the entity table index acting as an index of the table and identifying, at the same time, the entity that the statistics are collected for (applIndex).
• total number of requests generated or received, request errors and request discards for the information entity (isnSummaryRequests, isnSummaryRequestErrors, isnSummaryRequestDiscards).
• total number of responses generated or received, response errors and response discards for the entity (isnSummaryResponses, isnSummaryResponseErrors, isnSummaryResponseDiscards).
• total number of timeout errors (isnSummaryInUnknowns),
• total bytes received and transmitted by the entity including data and control bytes (isnhttpSummaryInBytes, isnhttpSummaryOutBytes and).

The isnRequestTable provides detailed request statistics for the entities on this system. Each entry of this table consists of the following objects:

• the unique index of the entity (applIndex),
• the request type (isnRequestType),
• the protocol version (isnRequestVersion),
• the total number of requests, total request bytes received, and the time of the last request (isnRequestInCount, isnRequestInBytes, isnRequestInLastTime),
• the total number of requests, total request bytes generated, and the time of the last request generated (isnRequestOutCount, isnRequestOutBytes, isnRequestOutLastTime),

The table is indexed by the entity index, the request type and the protocol version. This means that the entries are ordered in the table by entity and sorted by request type and protocol, for example a table may look like this:

isnRequestEntry.1.httpGET.1.1.0.0 [entity with index 1, http get, version 1.1]

isnRequestEntry.1.httpGET.1.0.0.0 [entity with index 1, http get, version 1.0]

isnRequestEntry.2.httpGET.1.1.0.0 [entity with index 2, http get, version 1.1]

The isnResponseTable is similar to the isnRequestTable, providing detailed response statistics for all entities. The table is again indexed by the entity (applIndex), the response type and the protocol version. Each entry of this table consists of the following objects:

• the unique index of the entity (applIndex),
• the request type (isnResponseType),
• the protocol version (isnResponseVersion),
• the total number of responses, total response bytes received, and the time of the last response received (isnResponseInCount, isnResponseInBytes, isnResponseInLastTime),
• the total number of responses, total response bytes generated, and the time of the last response generated (isnRequestOutCount, isnRequestOutBytes, isnRequestOutLastTime),

The isnerrorErrorCountTable maintains an error counter for each entity. The counter is reset every time the manager reads it or when the agent is reset. Each entry of this table consists of the following objects:

• the table index is the entity index (applIndex),
• the error counter (isnerrorCountNum),
• the last time the counter was reset (isnerrorCountSince); this is the last time the manager read the counter or the agent was reset,
• the time of the last error (isnerrorCountLastError).

The isnServiceTable maintains client domain access & performance statistics: the agent extracts the domain name (or address) from every client address and counts total accesses, bytes and service time in a per domain fashion. Furthermore, the table includes gauges for the average delay and packet loss to the client domain. Notice that an entry for a specific domain is included in the table only if at least one client from this domain accessed an entity in the system in the near past. To reduce the explosion in size of the table the agent deletes a domain entry after a pre-established time period without accesses from the domain. The table is indexed by the entity index and the domain name. Each entry of this table consists of the following objects:

• the entity index (applIndex),
• the domain name (isnServiceDomain),
• total bytes served for the domain by the entity and total time required for service (isnServiceBytes, isnServiceTime),
• total number of accesses from the domain to the entity (isnServiceAccesses),
• average delay and packet loss to the domain (isnServiceDelay, isnServicePacketLoss).

The isnAuthTable maintains statistical information on successful and failed authentication operations. The table is indexed by the entity index and the authentication type; for each entity and supported authentication mechanism a entry is kept with counters for successfully authenticated (isnAuthSuccessCount) and failed accesses (isnAuthFailureCount).

The isnCacheTable provides statistical information on cache status and usage. The table is indexed by the entity index (applIndex) and entries are ofcourse included only for entities with caching mechanisms (proxies, etc.). The table includes a gauge for current entries in the cache, counters for total requests served by the cache and for total hits, and the average time an item remains in the cache.

The isnDependencyTable maintains dependency and inter-accessibility information for the components of the managed Information Systems (entity and dependent entities/applications). The table is indexed by the entity (applIndex) and the associated entity (the address and port number is used for identifying it). The association / dependency is tagged with a textual description and a set of four parameters collect performance and accessibility information for the dependency:

• accessibility of the dependent entity (accessible, not accessible, unknown),
• service latency, i.e. the delay between issuing a request and receiving the response,
• network delay (in ms) between the two applications,
• packet loss (%)between the two applications.

The isnConfigTable includes a set of generic configuration parameters, common to all information entities handled by the agent and the isnMIB. The manager may retrieve or modify these parameters for monitoring the settings or for performing remote configuration. The table is indexed by the entity table index (applIndex) and each entry of the table includes the following objects / configuration hooks:

• the current process ID (parent process) of the entity. The manager may set it to "0" in order to force an entity restart.
• the user and group ID used by the entity.
• the port number that the entity listens to.
• server type (for server entities): standalone or inetd-based.
• the document root directory.
• the access and error log pathnames.
• the maximum number of allowed connections.
• a configurable "restart grace period": for standalone servers if this is set to a value greater than 0, then the agent will restart the entity "restart grace" seconds after the last modification of the entry.

The isnproxyConfigTable maintains some of the proxy server configuration parameters and allows their modification by the manager. These include:

• exclusive use of the proxy cache (all requests are served only through the local cache) or not (if the request cannot be satisfied locally then the proxy will generate the appropriate request to a remote server). This behavior can be defined by setting a boolean value,
• the proxy's root directory,
• the cache size in MBs,
• the access log full pathname,
• the cache Last Modified Factor (LMF),
• the time after which a file lock can be broken.

The isnproxyNonCachedTable allows the manager to define URLs that should not be cached by the caching proxy server. The table contains entries with two objects: the "non-cacheable" URL and the caching proxy entity (the applIndex is used).

The isnmirrorConfigTable allows the manager to configure the mirroring functionality. Each entry in the table identifies a mirrored package. The following parameters are hooked to entry objects:

• the location of the mirrored package (a URN/URI),
• the time period for mirroring,
• the condition for refreshing the mirrored image; three options: change in size, change in date and always refresh,
• the username and password (if required) for logging in the remote site.

The isnSecurityTable maintains security restriction information and allows the configuration of access control mechanisms for all entities that support them. Four types of restriction mechanisms are supported:

1. based on denial of service (allow/deny) to specific domains. For ftp it corresponds to the 'deny' directories; for wais to the server access token. It can also be used to support system-level security wrappers.
2. based on usernames (for the IS entities that support them). For http this table controls which directories are protected by the .htaccess mechanism. For ftp this accounts to the sublogins mechanism. This type is not applicable for wais and gopher.
3. based on restricting access methods per domain or user class. This type is not applicable for http. For ftp corresponds to domain classes and permissions. For wais this is the database access control mechanism. For gopher this corresponds to the 'access' token.
4. based on concurrent connection restrictions per client domain/class. For ftp it is defined per class (ftpaccess/limit token). For http and wais it is not applicable. For gopher it corresponds to the access token (domain based).

Restricting mechanisms can be set up and configured by creating / modifying rows in the table. Each row identifies a security restriction mechanism for a specific entity. The limit, subject and object of the restriction is also included in the table entry and their meaning depends on the restriction type (there are four types as described above).

The isnContent group

The scalar object isnInfoSize provides the total size (in MBs) of the information published by all the managed entities in the system.

The isntopicTable maintains a description of all topic areas published by each entity. Each table entry is indexed by the entity index and a unique table index, and includes a textual description of the topic area.

The isndocumentTable provides information and access statistics on the actual documents published by the managed entities. The table size is restricted to a maximum preset size (writTable by the manager). The table is indexed by the entity index (applIndex) and a TimeFilter variable. For each document in the table the following information is included in the entry: the document URI & resource URL, the document type (static, dynamic, mirror image), document size in bytes, the content coding method, the time of last update and total number of accesses since last reset. The Timefilter mechanism resets the counters each time the manager accesses the table.

The isnlog group

The isnLogFileTable maintains an entry for every information entity log file. Each entry has three attributes: the log type (access, error or other log), a counter of the log file size in text lines and an object for clearing the actual log file (if the manager sets this object to TRUE then the respective log file is emptied). The table is indexed by the entity index (applIndex) and the log type. The manager uses this table for checking on the size of the entity log files and for remotely clearing the logs.

The isnRecentUserTable logs users that have recently connected to the entity, separately for each entity, up to a maximum number (per entity) set by the manager. Each row corresponds to a user accessing a specific information entity; thus the same user may appear in multiple entries corresponding to different information entities. The entry records the user identification (in the form user@address, where either "user" or "address" may not be available), the total number of accesses to the entity since the user entered the table and the last document accessed by the user in the specific entity. The table uses the RMON time filter mechanism and every time an entry is changed a "Time Mark" object is updated. The table is index by the entity index and time filter object.

Standardization Activities

The use of proxies, persistent connection and virtual hosts related issues needed extra attention and further specification. A lot of these efforts should be resolved in HTTP/1.1, but extra functionality also unveiled other problems, such as those associated with hit-metering. Hit-metering is a mechanism that aims providing the original document with the number of hits the document had at a proxy. This mechanism let information manager/providers know more exactly how many times the information was requested.

The DISMAN WG

DISMAN provides a framework that could be used in MUSIQ to delegate management tasks. However, there is still to much open issues to be discussed under DISMAN, and the proposed framework has still to be proven solid and implementation cost-effective. MUSIQ framework architecture will be simpler and use a hybrid (not only SNMP) management framework, being worth noting that DISMAN future activities of the WG will maybe support hybrid management approaches.

The contributions to IETF Working Groups

• the SYSAPPL-MIB,
• the WWW MIB,
• the NSM-MIB,
• the DSA-MIB,
• the HR-MIB, and
• the RDBMS-MIB.

1. Both the SYSAPPL-MIB and NSM-MIB claim to be generic for applications management (the SYSAPPL-MIB under an OS/host perspective and the NSM-MIB under a networked/distributed perspective).
2. Many overlapping and duplicated objects are contained in the surveyed MIBs. For example, the software groups of the HR-MIB can be replaced with the recently defined SYSAPPL-MIB. Other overlaps or duplications consist mainly in objects providing a greater level of detail.
3. Indexes defined in other MIBs may cause implementation problems when the referred MIBs are not implemented. The current SNMP framework gives no rules or hints on how to handle this situation. If an agent developer will not implement the referred MIB, he has to choose his own index values in a way that no conflicts will occur.
4. Due to difference in definition of an application in the SYSAPPL-MIB and the NSM-MIB there is no unique relationship between the entries of both MIBs.

MUSIQ has contributed to this task, trying to make the NSM-MIB more consistent in its definition and getting support for the definition of objects that would enable the computation of QoS parameters (ref).

SYStem APPLication MIB Working Group

• Phase 1 addresses a generic set of managed objects for the monitoring and control of an application in a single host, and it will not require any instrumentation imbedded in the applications. This set of managed objects will serve as a base for managed objects defined in phase 2.
• Phase 2 addresses a generic set of objects for runtime applications management, requiring a certain level of instrumentation at the managed application. In addition to the generic set of managed objects, an application specific MIB is defined which provides monitoring and control facilities for the World Wide Web application. This last MIB, the WWW-MIB, is taken over from the HTTP-MIB interest group.

During the start of the definition phase of the MUSIQ MIBs - IS-NODE-MIB and IS-MANAGER-MIB (7,0) - the SYSAPPL-MIB WG and the HTTP-MIB interest group were work was closely monitored, and MUSIQ also contributed to the discussions held at the IETF meetings in Montreal and San Jose [43].

WWW-MIB versus IS-NODE-MIB

The goals for the IS-NODE-MIB defined under MUSIQ are similar to those of the WWW-MIB currently defined under the SYSAPPL-MIB WG of the IETF. The WWW-MIB originally started its definition in 1995 where a small group of people interested in network management of WWW (including the current MUSIQ team) setup a mailing list and made a presentation in a Birds of Feather (BoF) at the 36^th IETF meeting in Los Angeles. The work of this interest group was officially adopted at the 38^th IETF meeting in San Jose. At this last IETF meeting, input of related WGs such as the HTTP-WG was also requested.

The scope of the WWW-MIB is to manage Document Transfer Protocol (DTP) entities. The DTP is an abstraction of the actual protocol used for document retrieval and based on the request/response paradigm. The WWW-MIB not only defines objects for management of the DTP-entities, it also defines objects for hooking the MIB in the management framework as defined by the SYSAPPL-MIB and the MADMAN WGs..

The approach used in MUSIQ had to be more pragmatic, and we add to define a coherent MIB for Information Services that would enable the management applications to unambiguously retrieve all of the necessary information necessary to compute the Quality parameters defined under WP73 and the requirements identified under WP71. If the Information Service concept in MUSIQ is based on the same fundamentals as the WWW-MIB, the MUSIQ IS-NODE-MIB tries to be stand-alone not duplicating information ubiquitously defined in other MIBs. This approach was taken for the sake of consistency with IETF defined MIBs.

The Table below depicts the main differences between the WWW-MIB and the IS-NODE-MIB

object groups	WWW-MIB	IS-NODE-MIB
system	entity table	entity table network bandwidth objects
protocol statistics	summary table received requests table transmitted request table received responses table transmitted responses table	summary table request table response table
errors and faults	yet, TBD	error table counting the only the number of errors
delivered service to users	will be part of the APPLICATION-MIB	service table in which some delivered QoS parameter per domain are monitored
authentication and security	will be part of the APPLICATION-MIB	authenticate table counting the success and failures security table for setting the access modes
cache	implicitly embedded	cache table
dependent application	-	dependency table
configuration	will be part of the APPLICATION-MIB	configuration table proxy configuration table mirror configuration table logfile table
provided information	document name table document filter table document table	topic table document table
user tracking	no (privacy reasons)	user table
external or relationship objects	relationship tables towards SYSAPPL-MIB APPLICATION-MIB NSM-MIB	NSM-MIB applGroup assocGroup HR-MIB hrSystemGroup, hrStorageGroup, hrSWRunPerf

• Outline the overall MUSIQ management framework and identify the management components. This is not the detailed definition of management architecture, but rather a feasibility study of the management framework guidelines that guides the design and implementation of the management applications and agents, where the architecture is strictly and formally described. General requirements concerning the overall management framework are identified, two alternative solutions are discussed and the most feasible approach is adopted for implementation.
• Identify QoS management procedures. Given the management framework and the user requirements and specifications defined in previous tasks of the project a set of QoS management procedures is defined. This is a first step towards both extracting the QoS metrics (as unique isolated parameters) and defining management functional specifications and requirements.
• Define the QoS metrics. By taking into consideration the selected management framework and the MIB objects already defined in previous tasks of MUSIQ, the QoS management procedures are decomposed in specific QoS metrics. Metrics are organized in groups according to their target group (useful to both end-user and manager or only to the IS manager) and to their associated management functionality (e.g. error statistics metrics, service quality metrics, etc.).

• Minimize WAN management traffic.
• Minimize overall management system response.
• Provide views of the managed subjects in multiple levels of abstraction.
• Provide up-to-date and correct management information from any hierarchy level.
• Support distribution of management responsibilities in a pan-European scale.

(a) A Full SNMP-based Approach

The overall architecture is organized in at least three levels of hierarchy, that may be generalized and expanded horizontally (add more planes with three levels that may intermix or not) or vertically (add more levels of hierarchy). The generic architecture exhibits a tree-like topology that may changes to a mesh if expanded, i.e. three core components are identified.

• At the leaf level (level 1, lowest in the hierarchy) the Agent is responsible for collecting first-hand, low level information from the managed information entity. This is the traditional, light-weight agent as introduced by the IETF management framework and the SNMP protocol. Light-weight refers to system resources usage, not the number of supported objects, i.e. the agent is a process that operates with limited system resources without significantly affecting the performance of the managed entity. The agent services requests and generates asynchronous notifications through the selected management protocol.
• The Domain Manager / Remote Management & Monitoring Agent (DM/RMMA) operates at one level (level 2) over the agents and is responsible for a specific domain of Agents and acts as a delegate of higher level managers. It may also be configured to operate as a local, lightweight manager for the specific domain by supporting a GUI for human operators. Different functionality (sets of management functions) may be implemented in the DM/RMMA, depending on the desired role of the component and multiple components may be configured for a single domain if certain functional groups need to be separated (due to complexity or resource requirements). For example, a DM/RMMA may be dedicated to fault management and report/trouble ticket generation and another DM/RMMA may be responsible for gathering performance and other information for the domain.
• The Management System (MS) operates at the top level (level 3 in the simple case) and it is the traditional management system with the full set of management functions (such as monitoring, history, alarms, topology, remote configuration) including a graphical user-interface (GUI).

More levels of DM/RMMAs may be inserted between the MS and level 1, thus expanding the hierarchy vertically and generalizing the concept of the domain (include other managers in the domain of authority of a DM/RMMA). Multiple MSs may be introduced at the top level (horizontal expansion of the model) for satisfying redundancy requirements or for separating functionality at the top level, e.g. an MS is responsible for planning and global access statistical analysis, another is responsible for fault handling and trouble ticket generation, etc.

In this approach all interaction between the components is performed through the SNMP management protocol. The choice of SNMP mandates the use and installation of Management Information Bases (MIBs) on every component that interacts with entities at higher levels.

At level 1, the SNMP agents maintain the Information Service Node MIB (isnMIB) as it was defined in WP-7.2. The manager components access the isnMIB to retrieve low level management and implement their functions based on these MIB objects. The DM/RMMA components maintain the Information Service Manager MIB (ismMIB) as it was defined in WP-7.2. The ismMIB provides an SNMP interface to the functions that the DM/RMMA implements and supports the interaction with the MS components and generally with the higher level manager components.

This is a full SNMP-based approach throughout the hierarchy. It has the advantage of using a standard protocol and framework (de facto standard for TCP/IP based networks management) and it pertains to the IETF Distributed Management Working Group work.

The formal mapping of management functions on SNMP MIB objects provides a clean, standardized interface, but also requires a significant effort to implement and maintain (e.g. introduction of additional functions conveyed through MIB structures).

Figure 8: The full SNMP-based approach

(b) Hybrid Approach

This approach relies on SNMP only for the collection of low-level managemnt data from the agents, i.e. requires a MIB implementation at level 1 only. The inter-manager component interaction is performed through other protocols. An outline of this approach is given in the following paragraphs and the detailed design will be produced within WP-7.5.

This is also a distributed hierarchical management architecture with the same SNMP agents at level 1, maintaining the isnMIB and multiple manager components at the higher levels:

• At level 2, the Site Manager (SM) component is responsible for an IS system consisting of multiple machines and applications and provides the functionality for automated, unattended management of the IS system. The SM retrieves data from the isnMIB through SNMP and provides higher level manager components with a view on the status of the IS system, access statistics, faults and other management information. It supports both real-time monitoring and analysis, historical logging of events and/or statistics, setting of alarm procedures, discovery of IS configuration and handling (filtering & forwarding) of events/traps. The SM ideally should be made platform independent. If the ismMIB is to be implemented, it belongs to this level (and could provide a platform independent interface).
• At level 3, the Domain Manager (DM) is a system able to group higher level information across a set of IS systems. The DM interacts mainly with SMs for acquiring summary information and may also retrieve detailed data directly from the agents (through SNMP and the isnMIB). Typical information maintained at this level is IS status, overall statistics and QoS metrics. The goal of the DM is to store high-level management information over a relatively broad period of time and make it accessible to the operator and/or the end-user. The GUI supported by the DM component depends on the desired functionality and the target-user. A few examples follow:
  1. A generic monitoring DM provides a simple graphical interface visualizing the Information Systems and their location, status and topology. The user may `click' on the icons to connect to the site managers and/or agents to poll detailed information. Such an interface is close to the traditional (OpenView, NetManager, etc) Management Application GUI.
  2. An Automatic Report Generator that is responsible for generating digested reports for specific groups of people (managers, end users, administrators, etc.) should provide minimal graphical interface for configuring the reports and target groups and use e-mail or http to present the reports.
  3. A fault finding broker may use DM derived management data asses reliability and performance parameters when performing the diagnosis of a problem submitted by a user.

Figure 9: The hybrid approach

(c) MUSIQ Implementation

Even though a MIB for the manager components (the ismMIB) was defined, the hybrid approach is considered by the MUSIQ consortium more feasible and appropriate for implemention within the DESIRE Project. Consequently, the design and implementation of the pilot agents and manager components will be based on this approach. Detailed architecture and design issues will be presented at the agent and management application documents (wp74 and wp75).

QoS Management

• The IS entity that provides the service to the end-user. The service and the entity itself are the targets of the management operations.
• The management agent at the IS entity site.
• The manager components (organized in two hierarchical levels).
• The human IS manager that operates the management applications and is responsible for monitoring and controlling the QoS delivered to the end-user by the IS entity and the associated infrastructure.
• The end-user who accesses the IS entities for retrieving information and issues queries on QoS to some specific manager components.

This section identifies the functionality of these actors that is required in order to monitor & control the quality of service. This includes the QoS management procedures that the IS manager should perform through specific management functions implemented by the manager components and the end-user interaction with the management architecture (mostly for querying on the delivered QoS).

QoS Procedures

1. Graphical presentation of the managed domain architecture/synthesis (host & IS entities), faults and configuration changes, performance information, various statistics, etc. A graphical interface infrastructure that all QoS management procedures use to convey information to the human operator.
2. An application interface to selected management functions, offered to remote managers in order to realize the distributed, hierarchical QoS management scheme described above.

1. Performance and resource utilization monitoring: monitoring of performance specific parameters that will provide the an picture of current QoS provided to users and will assist fault management and planning.
2. Fault monitoring and reporting: alarm setting and reporting, identification of configuration problems and faulty configuration changes, error handling and diagnosis, error rate monitoring, and other fault management functions associated with the information service & entity.
3. Security parameter configuration and monitoring: remote configuration of the information entity security mechanisms, handling of security events, monitoring of security status and generation of security alarm tickets.
4. Planning and resource allocation: analysis of performance and fault historical data (system and entity resource utilization / access statistics / errors) for planning allocation of resources, upgrades, distribution of information, caching techniques, etc. aiming to sustained the desired QoS level or improve it.
5. Remote configuration: remote configuration of entity parameters for tuning and improving the quality of service offered. This remote procedure is useful for minor adjustments that need to be completed quickly and remotely, or for small changes in configuration that need to be applied in parallel to multiple IS entities (possibly within the same domain or in different geographical or organizational groups).
6. Content statistics: published information management. This includes: access statistics per resource/domain, error statistics per resource/domain, topics offered and other statistics that can assist planning decisions like caching configuration, mirroring, etc.

• Request a specific site's health / behaviour. The end-user connects to a well-known domain manager (DM) and provides the target URL. The DM should be able to provide all the necessary QoS metrics (and probably a limited number of QoS indicators) on the requested site's health and behaviour. This may require the DM to access the target site manager (SM) or even "link" the user to the appropriate DM (if the SM is not included in its domain) in a transparent way. Some key parameters that should be presented to the interested end-user, are:
  • Current availability and operational status of the IS entity and its components. The manager reports whether the entity is down, its load percentage, current total throughput, percentage of its components that are operational.
  • Network status: WAN connectivity of the entity and capacity information. This includes whether the IS entity has WAN connectivity, the current WAN link utilization and a statistical average.
  • Estimated throughput to the interested client and average historical throughput. In addition to the current total throughput of the entity, the user should be informed on the expected throughput to his/her site. The agent maintains a throughput table with "per client domain" information and the manager components collect this information and construct historical databases. If the client's domain can be found in the agent table (someone from his/her domain has accessed the server in the near past) then the system will be able to provide the end-user with a good estimate of the expected throughput should the end-user connect. In addition, the historical data maintained at the DM, can provide a historical average for the client's domain, assuming someone from the domain has accessed the entity during the historical database lifetime.
  • Statistical information on the entity: optimal time period to access the server and associated throughput, content quality (consistency & errors) indicators.
  • Access statistics on the entity. The end-user should be presented with the option to retrieve access statistics for the IS entity, like document statistics and access statistics per domain. If the entity is a caching proxy, then statistics on its caching system efficiency should be accessible to the end-user.
• Seek the optimal site to access. The end-user will contact a well-known DM and request a list of optimal sites among all DESIRE sites or given a specific topic or other requirement. The DM should be able to provide two visual hierarchy maps with all the DESIRE information servers according to geography and information topic. The end-user may select a group to view the optimal list of servers taking into account the end-users area, the current time and day, etc.
• Report an accessibility problem to a site and request information on the fault. A DESIRE II issue.

QoS indicators & metrics have qualitative differences in addition to differences in the way they are presented to the user. So, before presenting the defined parameters we first identify the different types of QoS indicators & metrics according to their semantics & visualization. Then the actual QoS indicators are presented, organized in functional areas. Finally, the QoS metrics, derived from indicators, are presented in groups classified according to functional areas and target group (end-user & manager or manager only).

The indicator description consists of:

• a textual description,
• the associated QoS management procedures identified earlier in the text,
• the necessary MIB objects for calculating the indicator (if any),
• the type of the metric (as classified in 2.4) and the formula used to calculate it,
• whether historical data (and what type) are collected for this parameter or not, and
• the hierarchy level, i.e. the component, that is responsible for calculating the metric.

• Single value parameter. Parameters of this type may be polled or received asynchronously and graphically represented through gauges, bars, colour coded graphics or just a number. Such indicators may be calculated directly at the agent (already a MIB object) or at the SM level. Asynchronous notifications flow from lower levels towards the DM and the human operator.
• Distribution parameter. These are series of data that represent distributions (percentages adding to 100%) that are frequently visualized as pie charts (e.g. top domain access statistics):
  
  These parameters can be produced by MIB objects and are calculated at the SM. The user may retrieve these values directly from the SM or through a DM.
• Historical diagram parameters. Parameters of this type represent series of historically sampled data that are useful to the user only when presented together in the form of a diagram. An example is presented below (all values of sampled throughput for a specific time period):
  
  Most parameters of this type are useful mainly to planning and targeted to the IS system manager. Historical diagrams are gathered and stored at the DM level through which are made available to the human operator.
• Ensemble average diagram parameters. These are also multiple value parameters that provide aggregate averages for a single value indicator/metric. For example, the throughput average for the different days of a week, or hours of the day (presented below) may guide the end-user to choose the optimal time to access the specific server, or aid the manager in planning and resource allocation. Similarly to the historical diagrams these indicators are gathered and stored at the DM level.
  
• Sets/ tables of associated values. These are also series of values associated in a way. For example, a set of service delays from an entity to all dependent entities is such a indicator. Such sets of values may be available as MIB objects (table entries) in the agent level or may be gathered and stored at the SM level.

  NOTE: Any diagrams and graphs above are used only for providing a visual aid to the explanation of the metric types; they do not present any user-interface requirements.

expired = 0
total = 0
average = 0
variance = 0
for all documents in the IS Entity
{
    total ++
    if (isnDocumentExpires < current DateAndTime)
    {
           expired ++
           average += (current DateAndTime - isnDocumentExpires)
           variance += average^2
    }
}
average = average / expired
variance = variance / expired - average^2
total number of expired documents = expired
expired documents percentage = expired * 100 / total
average time since expiration = average
variance of time since expiration = variance

topics = 0
for all entries in isnTopicTable
    topics ++

total number of topics = topics

Metric name:	LAN status
Description:	A metric on the qualitative status of the LAN (for a given IS entity) considering the intra-LAN delay and packet loss.
Units:	percentage (0-100%), or graphical gauge or other GUI element ( - ), or textual characterisation (excellent, good, sufficient, poor, unacceptable).
Historical data:	Historical and ensemble average diagrams. The end-user may request the actual metric or any of the two (or both) diagrams.
Indicators:	Site LAN health & performance indicator
Formula:	The metric is calculated according to: the profile of all sites within the domain, the local historical profile (in the SM perspective), pre-established thresholds (by the manager), Both the SMs and DMs co-operate in the calculation of this metric and the construction of the diagrams in the first case. Each SM polls the agents in its site and retrieves the "Site LAN health & performance indicator". Then all delay and packet loss parameters are forwarded to the DM that the SM belongs to. The DM periodically collects the Site LAN health indicator instances from all the SMs in its domain and calculates the cumulative frequency for the delay and packet loss in the domain. For example, consider a domain with three sites (three SMs). The DM collects the following data: Delay (ms) site 1 10 12 9 9,5       site 2 50 48 51 55 60     site 3 9 8,5 7,9 8 8,6 9,5 9 Packet (%) site 1 1 0 1 0       site 2 1 2 1 0 1     site 3 0 0 0 1 0 0 1 and produces the following cumulative frequencies: Note that these distributions are stored at the DM and updated with every time new data are retrieved by the SMs. When a user inquires for the LAN status of a specific IS entity the DM retrieves the "Site LAN health & performance indicator" from the responsible SM and compares the delay and packet loss parameters to the two distributions it maintains for its domain. The result is a percentage calculated as follows: if ( delay < min_delay ) F1(delay) = F1(min_delay) if ( delay > max_delay ) F1(delay) = 1 if ( loss < min_loss ) F2(loss) = F2(min_loss) if ( loss > max_loss ) F2(loss) = 1 metric = [{F1(delay) - F1(min_delay)} / {1 - F1(min_delay)} * 50 + {F2(loss) - F2(min_loss)} / {1 - F2(min_loss)} * 50] % where F1(x) is the delay cumulative frequency, F2(x) is the packet loss cumulative frequency, min_delay / min_loss are the minima of the two distributions and max_delay / max_loss are the maxima of the two distributions. This metric may be presented to the end-user (or manager) as a percentage, a graphical gauge/bar or as a textual characterisation by introducing the following scale: unacceptable poor sufficient good excellent 0-20 % 20 - 45 % 45 - 75 % 75 - 95 % 95 - 100 % For example, for a site reporting a delay of 10ms and a packet loss of 1%, given the above example distributions, the LAN status metric will be calculated as: metric = [{0.625 - 0.0625} / {1 - 0.0625} * 50 + {0.938 - 0.5} / {1 - 0.5} * 50] % = 73.8%, or = "sufficient", or = Alternatively, the SM may calculate the metric according to a similar distribution, stored at the SM, that characterizes the historical profile of the site. Finally, the metric may be identified according to pre-established thresholds set by the manager.
Metric name:	WAN connection status & performance
Description:	Similar in concept and presentation to the LAN status metric, but for the WAN level (WAN connection). This metric takes into consideration the: Whether the WAN connection of the site to the Internet is operational (the site in question is currently connected to the Internet, not necessarily accessible from the end-user). The delay and packet loss parameters from the site in question to the client domain (end-user inquiring).
Units:	percentage (0-100%), or graphical gauge or other GUI element ( - ), or textual characterisation (excellent, good, sufficient, poor, unacceptable).
Historical data:	Historical and ensemble average diagrams. The end-user may request the actual metric or any of the two (or both) diagrams.
Indicators:	WAN connection health & performance indicator
Formula:	Like in the calculation of the LAN status metric, this metric may be calculated in a DM, SM or threshold based manner. For the SM-relative and the pre-established threshold cases the metric is calculated in the local SM. For the domain-relative case both the SMs and the DM participate in constructing this metric and the historical & ensemble average diagrams: Each SM polls the agents in its site and retrieves the "WAN connection health & performance" indicator. Then all delay and packet loss per client domain parameters are forwarded to the DM that the SM belongs to. The DM periodically collects the WAN health indicator instances (delay and packet loss) from all the SMs in its domain and calculates the cumulative frequency for the delay and packet loss per client domain. This is done as in the LAN status metric described above, but here the DM maintains multiple cumulative frequencies, since there is one for every client domain. The number of recent domains stored should be configurable. When the end-user inquires the DM for the WAN connection metric of a specific IS entity/system, the DM requests the current "WAN connection health & performance" indicator from the SM responsible for the entity and then compares the packet loss and delay for the end-user domain to the respective distribution. The metric (as a percentage) is calculated with the same formula presented for the LAN status metric: if ( delay < min_delay ) F1(delay) = F1(min_delay) if ( delay > max_delay ) F1(delay) = 1 if ( loss < min_loss ) F2(loss) = F2(min_loss) if ( loss > max_loss ) F2(loss) = 1 metric = [{F1(delay) - F1(min_delay)} / {1 - F1(min_delay)} * 50 + {F2(loss) - F2(min_loss)} / {1 - F2(min_loss)} * 50] % where F1(x) is the delay cumulative frequency, F2(x) is the packet loss cumulative frequency, min_delay / min_loss are the minima of the two distributions and max_delay / max_loss are the maxima of the two distributions (for the specific client domain). This percentage may be translated to a textual characterisation using the same scale discussed in the LAN metric above. Note that the end-user domain may not be present in the SMs (simply because none from this domain accessed the site recently), thus no distribution will exist in the DM for the specific client domain. In this case, the DM should use overall statistics and present to the user an aggregated metric for all other client domains (the same formulas will be used to calculate the metric and then an average will be taken).

metrichost = MemoryUtil*0.5 + ProcessorLoad*0.25 +
            SystemProcessLoad*0.25
metric = 0.5*metricIS_Entity_host + 0.5*Average[metriccomponent_host]

Metric name:	IS system availability
Description:	Availability (percentage of time that the system is operational, not down) of the IS system, taking into account all IS system components (IS entity & dependent applications).
Units:	Percentage (0-100%).
Historical data:	This metric is historical by nature. A historical diagram has no meaning.
Indicators:	Service availability / downtime indicator
Formula:	Availabilityi = [1 - (downtime / total_time)] * 100 % Availability = 0.5 * AvailabilityIS_entity + 0.5 * Average[Availabilitycomponent_i] (total_time is the period that downtime is calculated for, e.g. day)
Metric name:	IS system load
Description:	The current load of an IS system (main IS entity and dependent entities) by taking into account the current number of connections and maximum allowed connections.
Units:	Percentage (0 - 100%), or graphical element like a gauge or bar.
Historical data:	Historical and ensemble average diagrams. The end-user may request the actual metric or any of the two (or both) diagrams.
Indicators:	IS component load
Formula:	Load = 0.5 * LoadIS_entity + 0.5 * Average[Loadcomponent_i]
Metric name:	IS system & component health
Description:	Current operational status of the complete IS system and every component.
Units:	Percentage (0 - 100%), or graphical element like a gauge or bar.
Historical data:	Historical and ensemble diagram for both the system and the component metrics. The end-user may request the actual metric or the diagram (or both).
Indicators:	IS system component status indicator (table).
Formula:	switch (applOperStatus) { case "up": Healthcomponent_i = 100 case "congested" : Healthcomponent_i = 50 default: Healthcomponent_i = 0 } Health = 0.5 * HealthIS_entity + 0.5 * Average[Healthcomponent_i] %
Metric name:	IS component MTTF and reliability
Description:	Mean Time To Failure (MTTF) and component reliability (expected lifespan) for all IS system components: IS entity and dependent components.
Units:	MTTF: number or graphical element indicating days, Component reliability: percentage or graphical element (bar, etc.).
Historical data:	Historical diagram for the component reliability metric.
Indicators:	IS system component status indicator (table).
Formula:	The MTTF is calculated by monitoring the IS system component status indicator table as Average[time period between subsequent failures]. Component reliability is calculated as: , where MTTFi is the mean time to failure of componenti and ti is the time since the componenti was last initialized. Both should be in the same unit (e.g. days, minutes, etc.). Notice that a high MTTF will tend to produce a very low percentage, while the percentage for low MTTF values approaches 100% exponentially.
Metric name:	Current throughput
Description:	The current total throughput of the IS entity in bytes/sec and a percentage (compared to all other sites in the domain).
Units:	bytes/sec (throughput) - percentage / textual characterisation (comparison to other sites in the domain).
Historical data:	Historical and ensemble average diagrams. The end-user may request the actual metric or any of the two (or both) diagrams. Historical diagram example: Ensemble average diagram:
Indicators:	Total handled bytes indicator.
Formula:	The SM calculates current throughput from the indicator (using a sliding window mechanism). Throughput values and historical data are forwarded to the DM. The DM provides to the end-user the actual throughput in bytes/sec, and maintains the cumulative frequency for the domain. On the end-user inquiry, the DM compares the current throughput to the distribution and derives a percentage/textual characterisation using the formulas described earlier.
Metric name:	Current throughput for the client domain
Description:	Similar to the previous metric. Two parameters: throughput in bytes/sec and percentage/textual characterisation, but for the client (end-user) domain.
Units:	bytes/sec (throughput) - percentage/textual characterisation (comparison to other sites in the domain).
Historical data:	Historical and ensemble average diagrams. The end-user may request the actual metric or any of the two (or both) diagrams.
Indicators:	Entity service throughput indicator (table).
Formula:	The SM calculates the indicator. The throughput table is forwarded to the DM. The DM provides to the end-user the current throughput in bytes/sec, and maintains the cumulative frequency diagrams for all the client domains. On the end-user inquiry, the DM compares the current throughput to the distribution and derives a percentage/textual characterisation using the formulas described earlier.
Metric name:	Average throughput
Description:	The average total throughput of the IS entity.
Units:	bytes/sec.
Historical data:	none.
Associated metric:	Current throughput metric (see above).
Formula:	The DM calculates the average throughput from the distribution it maintains.
Metric name:	Average throughput for the client domain
Description:	The average throughput of the IS entity for a specific client (end-user) domain.
Units:	bytes/sec.
Historical data:	none.
Associated metric:	Current throughput for the client domain metric (see above).
Formula:	The DM calculates the average throughput from the distribution it maintains.
Metric name:	Content age
Description:	Average age of documents of an IS entity (since last update).
Units:	days
Historical data:	none
Indicators:	Document age indicator
Formula:	The DM extracts from the indicator the average time part for presentation to the user.
Metric name:	Top documents
Description:	A subset of the "Document accesses" indicator
Units:	table {document URL with link, total accesses}
Historical data:	none
Indicators:	Document accesses indicator
Formula:	The DM retrieves the indicator from the SM and derives the described table for presentation to the end-user.
Metric name:	Top domains
Description:	A subset of the "User/domain accesses" indicator
Units:	Table {domain name, total accesses}
Historical data:	none
Indicators:	User/domain accesses indicator
Formula:	The DM retrieves the indicator from the SM and derives the described table for presentation to the end-user.
Metric name:	Cache efficiency
Description:	Identical to the "Cache access & performance" indicator.
Units:	percentage
Historical data:	none
Indicators:	Cache access & performance indicator
Formula:	-

• The decomposition of a generic Information Service into its functional components and analysis of system wide variables that influence the reliability, performance and ultimately the Service Quality levels offered to users;
• The description of Information Services functional components and objects under a standard notation (ASN.1) with the definition of an Information Services MIB (isnMIB);
• Contribution to standardization initiatives in the area of application and WWW server management, namely to the WG on System Applications MIB of the IETF, leading to the publication of Internet drafts, amongst other contributions;
• The identification of a set of management scenarios that are the basis for the definition of the management framework and the system architecture to be implemented under WPs 74 and 75;
• The identification of requirements for the management applications with the sketching of a draft management layers architecture based on two key concepts, the Site Manager and the Domain Manager;
• The definition of a high level Quality of Service metrics and parameters that will help monitoring the fulfillment of IS users and manager requirements regarding IS reliability, performance and other operational assets as identified in the survey undertaken under WP71
• A pragmatic revision of the isnMIB under the light of the identified QoS parameters and draft management framework
• The formalisation of a new approach on the assessment of user satisfaction and on troubleshooting of potential problems affecting service quality levels.

From (a) the analysis of end-user & IS manager requirements, (b) the study of the IS engines and (c) the survey of related research in the area, we have concluded that the requirements for management of information systems is focused mainly on monitoring (of operation, access, resource usage, etc.) with less emphasis on remote configuration and security. This has been mapped on our results, from the MIB objects to the management functions and QoS metrics & indicators that were defined.

The distributed nature of Internet Information Services has dictated the adoption of a distributed layered management framework. In order to achieve a better organizational structure and accomplishing an efficient manipulation of large volumes of monitoring data, a hierarchical management framework was the adopted solution. The MUSIQ management framework will be based on a three level hierarchy of management components: (1) the agent, maintaining low-level information at the isnMIB. (2) The Site Manager (SM), responsible for collecting local detailed management information from the agents and store it over short time periods, aims mostly at operational management. (3) the Domain Manager (DM) storing higher level pre-processed management data over large time periods aiming at the computation of global utilization statistics, reliability and performance indicators.

Based on the rich set of management objects defined and the framework chosen, we have finally defined a set of QoS metrics and indicators, aiming at the management of Information Services as such and not as a set of individual disparate components (networks, systems, applications). With this in mind, we believe that we will be closer to the user perception regarding the assessment of Quality of Services levels once we have implemented the assessment techniques drafted in this document.

References - Bibliography

F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, and B. Alberti. "The Internet Gopher Protocol: A distributed document search and retrieval protocol." RFC 1436, University of Minnesota, March 1993.

T. Berners-Lee. "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web." RFC 1630, CERN, June 1994.

T.Berners-Lee, R.Fielding, H.Frysryk, "Hypertext Transfer Protocol - HTTP/1.0", Internet Draft, IETF HTTP Working Group, February 1996.

T. Berners-Lee, L. Masinter, and M. McCahill. "Uniform Resource Locators (URL)." RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994.

N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." RFC 1521, Bellcore, Innosoft, September 1993.

D.Brower, B.Purvy, A.Daniel, M.Sinykin, "Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2", RFC 1697, August 1994.

J.A.Carrilho, E.R.M.Madeira, "A Scheme for FTP Management," in Proc. of INET '94, JENC5.

J.Case, K.McCloghrie, M.Rose, S.Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)," SNMP Research, Cisco Systems, Dover Beach Consulting, International Network Services, RFC1902, January 1996.

J.Case, K.McCloghrie, M.Rose, S.Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2), SNMP Research, Cisco Systems, Dover Beach Consulting, International Network Services, RFC1902, January 1996.

L.N.Cassel, G.Patridge, and J.Westcott. "Network Management Architectures and Protocols: Problems and Approaches", IEEE JSAC, Vol. 7, no. 7, Sept. 89.

D. H. Crocker. "Standard for the Format of ARPA Internet Text Messages." STD 11, RFC 822, UDEL, August 1982.

F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang, J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype Functional Specification." (v1.5), Thinking Machines Corporation, April 1990.

R.Fielding, H.Frystyk, T.Berners-Lee, J.Gettys, J.C.Mogul, "Hypertext Transfer Protocol - HTTP/1.1", Internet Draft, IETF HTTP Working Group, April. 1996.

P. Grillo, S. Waldbusser, "Host Resources MIB," RFC1514, September 1993.

H. Hazewinkel, E. van Hengstum, A. Pras, "Definitions of Managed Objects for HTTP", draft-hazewinkel-httpmib-00.txt, April 1996.

H. Hazewinkel, E. van Hengstum, A. Pras, "Definitions of Managed Objects for an Information Retrieval Service", draft-hazewinkel-rsmib-00.txt, April 1996.

H. Hazewinkel, E. van Hengstum, A. Pras, "Definitions of Managed Objects for an Information Store", draft-hazewinkel-ismib-00.txt, April 1996.

J.Herman, "Enterprise Manage-ment Vendors Shoot It Out", Data Communications International, November 1990.

Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December 1987.

Information processing systems - Open Systems Interconnection - Systems Management Overview - International Organization for Standardization - International Standard 10040 - November 1992.

G.B. Jones, N. Jain, G. Mansfiled, "Mail and Directory Alarms," draft-ietf-madman-alarmmib-00.txt, March 1996.

B. Kantor and P. Lapsley. "Network News Transfer Protocol: A Proposed Standard for the Stream-Based Transmission of News." RFC 977, UC San Diego, UC Berkeley, February 1986.

S. Kille, N. Freed, "Network Services Monitoring MIB", RFC1565, January 1994.

S.Kille, N.Freed, "Mail Monitoring MIB," RFC1566, January 1994.

A.Leinwand, K.Fang. "Network Management: A Practical Perspective", Addison Wesley, 1993.

G. Mansfield, S. Kille, "X.500 Directory Monitoring MIB, RFC1567, January 1994.

K.McCloghrie, M.Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II," STD 17, RFC1213, Hughes LAN Systems, Performance Systems International, March 1991.

C. Picoto, P. Veiga, "Management of a WWW Server using SNMP," JENC6.

J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821, USC/ISI, August 1982.

J. Postel and J. K. Reynolds. "File Transfer Protocol (FTP)." STD 9, RFC 959, USC/ISI, October 1985.

J. Postel. "Media Type Registration Procedure." RFC 1590, USC/ISI, March 1994.

S.Rabie. "Integrated Network Management: Technologies and Implementation Experience", Infocom '92, IEEE, 1992.

J. Reynolds and J. Postel. "Assigned Numbers." STD 2, RFC 1700, USC/ISI, October 1994.

M.T.Rose, "The Simple Book: An Introduction Internet Management", 2nd edition, Prentice-Hall, 1994.

J. Saperia, C. Krupczak, R. Sturm, J. Weinstock, "Definitions of Managed Objects for Applications", draft-ietf-applmib-sysapplmib-06.txt, November 1996.

C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia, "Application Management MIB", draft-ietf-sysapplmib-applmib-02.txt, March 1997.

C. Kalbfleisch, H. Hazewinkel, J. Schoenwaelder, "Definitions of Managed Objects for WWW Servers", draft-ietf-sysapplmib-wwwmib-02.txt, March 1997.

H. Hazewinkel, "Survey of Defined Managed Objects for Application Management", draft-hazewinkel-appl-mib-00.txt, January 1997.

K. Sollins and L. Masinter. "Functional Requirements for Uniform Resource Names." RFC 1737, MIT/LCS, Xerox Corporation, December 1994.

F.Stamatelopoulos, T.Chiotis, B.Maglaris, "A Scaleable, Platform-Based Architecture for Multiple Domain Network Management", IEEE International Conference on Communications '95, June 1995.

S.L. Waldbusser, "A Look at the Host Resources MIB", The Simple Times, The Bi-Monthly Newsletter of SNMP Technology, Comment, and Events, Vol. 2, No. 3, May/June, 1993.

T. Chiotis, T. Karounos, M. Grammatikou, C. Stathis, B. Maglaris, R. Meneses, H. Hazewinkel, "Requirements Survey for Quality of Service in Distributed Information Systems"; MUSIQ/DERIRE project deliverable D71, June 1996 http://www.netmode.ntua.gr/musiq/wp71_survey/

R. Meneses - MUSIQ/DESIRE WP7 monthly progress reports (Internal)

The type of server (standalone or inetd-started) is important to know for implementing remote configuration and maintenance. The existence of a MIB variable identifying the server type is essential. In addition, configuration changes made remotely to a standalone server should be followed by a server daemon restart (initiated by the agent). Restarting should be offered by the agent as an automated feature for remote configuration and as an option for resetting crashed servers, etc. However, restarting the server after each single SET operation on configuration MIB variables seems inefficient; time-out/grace period techniques could be used instead: the agent restarts the server when a grace period expires after a set of configuration changes. Restarting on demand could also be implemented through SETting specific MIB variables; this operation should, of course, be restricted to trusted entities.

WWW Servers

Objects associated with the remote configuration of http entities (with an emphasis on servers/proxies) will be defined in the MIB. Only generic parameters that are supported by all major servers will be considered. Implementation-specific parameters and options will only be included as variables only if they are considered extremely useful and expected to be supported by all vendors in the near future. All these should be generalized for the other information service entities that will be supported by the proposed management framework, i.e. ftp, wais, gopher. Note, also, that the analysis of configuration and logging mechanisms that is presented in this section will not only provide objects and requirements for the MIB design, but will also assist the instrumentation design phase of the agent implementation.

The NCSA HTTP server

During startup, the server reads a number of configuration files, that customize various aspects of its behavior. Configuration modifications require restarting of the server daemon for taking effect (unless the server is started by inetd). There are four text configuration files: httpd.conf, srm.conf, access.conf and localhost_srm.conf. Every file contains a set a variable/value pairs. A description of the v1.4 configuration files follows.

1. httpd.conf: This is the main configuration file. Its variables are described below:
   • ServerType, defines whether the server will be run from the system process (inetd), or as a standalone daemon.
   • Port, the port that the server listens to.
   • User, Group, set the user and group id, by which the server runs.
   • ServerAdmin, the e-mail address for reporting server problems.
   • ServerRoot, the directory, where the main server binary, configuration and log files are kept.
   • ServerName, sets a hostname for the machine where the server is running, thus overriding the gethostbyname call.
   • StartServers, sets the number of server's children to be created during startup.
   • MaxServers, the maximum number of server's children that can be created.
   • TimeOut, the time waiting for a client to send a query, after connection has been established.
   • AccessConfig, specifies the global access configuration file.
   • ResourceConfig, specifies the resource configuration file.
   • TypesConfig, gives the file specifying the typing configuration
   • IdentityCheck, enables or disables the RFC931 compliant logging of remote user names.
   • BindAddress, binds the server to listen to a specific IP address only.
   • VirtualHost, binds the server to a number of addresses and customizes the way it responds to each one of them. Any number of such directives can be specified, limited only by the system resources.
   • ErrorLog, defines the file for logging the errors.
   • TransferLog, defines the file for logging the client transfers.
   • AgentLog, defines the file for logging the client agent software.
   • ReferrerLog, defines the file for logging referrers.
   • RefererIgnore, prevents the server from logging certain referrers.
   • PidFile, the file that records the process id of the Httpd daemon. It's information especially useful for restarting the server.
   • LogOptions, allows switching between the Common Log File (CLF) format and an extended CLF format.
2. srm.conf: Controls how the httpd server accesses documents and scripts in the system and how the namespace that the client views translates to the filesystem.
   • DocumentRoot, sets the directory where the files offered by the server are located.
   • UserDir, sets the directory inside user homes to which requests for specific user files are diverted. The DISABLE value disables user-supported directories.
   • AccessFilename, the name of the file that in each directory specifies access control, defaults to .htaccess.
   • Redirect, redirects requests for virtual documents on the system to other locations
   • Alias, creates a virtual document, sending all requests for it to an existent document.
   • ScriptAlias, creates a virtual directory, thus satisfying requests for it by returning the output of a CGI script in that directory.
   • AddType, creates additional types that associate a file to a type, according to its extension.
   • AddEncoding, associates an encoding type with a document, by its extension.
   • DefaultType, the default type given to documents, for which their type cannot be determined.
   • DirectoryIndex, sets the file from which a pre-written index for the requested directory will be given. In any other case the full directory index is returned.
   • FancyIndexing, sets fancy (icons, and file sizes) picture for the directory index.
   • DefaultIcon, the icon shown for a file inside an index, for which no icon information exists.
   • ReadmeName, the file that httpd should read for adding a small description to the end of a directory index.
   • HeaderName, the file that httpd should read for adding a header to the directory index.
   • AddDescription, creates a description for files of a specific extension in the directory index.
   • AddIcon, associates an icon with files of a specific extension in the directory index.
   • AddIconByType, associates an icon with files of a specific type in the directory index.
   • AddIconByEncoding, associates an icon with files of a specific encoding in the directory index.
   • IndexIgnore, the files we want the httpd to ignore, when creating an index.
   • IndexOptions, gives the opportunity to set options for the creation of indexes.
   • ErrorDocument, sets a CGI script to be executed each time an error occures, according to the type of error.
3. access.conf: This configuration file defines access restrictions to Web browsers (access rights and directories). The variable are:
   • Directory, a sectioning directive that specifies a directory for which access control directives apply.
   • Options, specifies which server features are available for a directory.
   • AllowOverride, the access control directives that can be overridden by directory specific directives.
   • AddType, DefaultType, AddEncoding, AddDescription, AddIcon, IndexIgnore, DefaultIcon, ReadmeName, act as the corresponding variables in srm.conf.
   • AuthName, sets the name of the authorization realm, so the users know which username and password to supply.
   • AuthType, sets the authorization type for a directory, currently only "Basic" has been implemented.
   • AuthUserFile, sets the file that contains the usernames and passwords for accessing a directory.
   • AuthGroupFile, sets the file that contains a list of user groups for user authentication.
   • Limit, a sub-sectioning directive, that controls which clients can access a directory. This is associated with the following directives:
     • order, sets the order of the allow and deny directives.
     • deny, allow, control which clients can access the directory.
     • require, controls which authorized users or groups can access the directory.
     • referrer, it is used to force users to enter a document through a specified path.
     • satisfy, specifies how the directory is accessed if both allow and require directives are used.
   • OnDeny, defines a URL to which failed requests are redirected.
4. localhost_srm.conf: This file defines the name space that the clients view if they access the server from localhost. Its directives are the same as in srm.conf.

AccessConfig, AccessFileName, AddDescription, AddEncoding, AddIcon, AddIconByEncoding, AddIconByType, AddLanguage, AddType, AgentLog, allow, AllowOverride, AuthGroupFile, AuthUserFile, AuthName, AuthType, BindAdress, DefaultIcon, DefaultType, deny, Directory, DirectoryIndex, DocumentRoot, ErrorDocument, ErrorLog, FancyIndexing, Group, HeaderName, IdentityCheck, IndexIgnore, IndexOptions, Limit, Options, order, PidFile, Port, ReadmeName, RefererIgnore, RefererLog, require, ResourceConfig, ServerAdmin, ServerName, ServerRoot, ServerType, StartServers, TimeOut, TransferLog, TypesConfig, User, UserDir, VirtualHost. The following variables are introduced only in Apache:

• AuthDBMGroupFile, AuthDBMUserFile, handle DBM files for access authentication on group or user/password level accordingly.
• LanguagePriority, defines the precedence of language variants in a MultiViews request.
• MaxClients, limits the number of simultaneous requests that can be serviced, thus limiting the number of child server processes that can be created. It's the same as MaxServers of NCSA.
• MaxRequestsPerChild, limits the number of requests that a server child will handle, thus limiting its lifetime.
• MaxSpareServers, sets the maximum number of the servers that can be idle at any time.
• MinSpareServers, sets the desired minimum number of idle child server processes.
• XBitHack, controls whether the parsing of ordinary html documents will have special treatment, according to the user or group bit that have been set.
• CookieLog, defines the file for logging cookies.
• LogFormat (an experimental directive), defines user-specified log formats.
• LoadFile, LoadModule, (experimental directives) allows loading of certain files or modules upon startup.

• HostName, the same as ServerName in NCSA
• UserId, GroupId, the same as User and Group in NCSA.
• Exec is the same as ScriptAlias of NCSA.
• AccessLog, is the same as TransferLog of NCSA.
• LogFormat, this is different than the NCSA LogOptions, because it specifies, whether the logs will be in CLF or an older format.
• InputTimeOut, is the same with TimeOut of NCSA, specifies the waiting period for the connected client to send its request.

The rest of the variables are:

• ParentUserId, ParentGroupId, causes httpd to set its user or group id immediately after binding to port.
• Enable, Disable, enable or disable methods that the server accepts (as part of subsectioning).
• DNSLookup, specifies whether httpd will perform a reverse DNS lookup to find the name of the client host.
• IdentityCheck, whether httpd will connect to the ident daemon (RFC931) of the client host for finding the login name of the owner of the client socket.
• Welcome, upon a request of a directory it specifies the filename that will be returned from this directory.
• AlwaysWelcome, makes trailing slash needed or unneeded for presenting the welcome file.
• MetaDir, the directory, in the same path as file being retrieved, where files that keep meta-information are stored. The information is returned together with the HTTP response header and the meta-information files have the same name as the file being retrieved with the suffix specified in the MetaSuffix parameter.
• MetaSuffix, described above.
• MaxContentLengthBuffer, it sets the size of the buffer that the server uses when it's running a proxy server.
• Map, Pass, Fail, Protect, DefProt, Exec, are rules for mapping between virtual URLs and physical file names.
• Map exchanges the requested template with another string.
• Pass just allows use of the specified template
• Fail restricts further access upon request of this template.
• Protect defines a template for documents to be protected.
• Defprot associates documents with a protection file, but without enforcing protection
• SuffixCaseSense, makes file suffixes case sensitive.
• Search, the absolute filename for a script that performs searches.
• POST-Script, PUT-Script, DELETE-Script, the absolute pathnames for scripts that respond to POST, PUT and DELETE requests.
• DirAccess, allows access of the client requests to all, none or selected directories.
• DirReadme, controls the position of a directory description, contained in a README file, or whether it will be shown at all.
• DirShowIcons, DirShowBrackets, DirShowMinLength, DirShowMaxLength, DirShowDate, DirShowSize, DirShowBytes, DirShowHidden, DirShowOwner, DirShowGroup, DirShowMode, DirShowDescription, DirShowMaxDescriptionLength and DirShowCase, control the look of directory listings.
• DirAddHref, makes the icons in listings sensitive for files which end in specified suffixes. This directive cannot be used on a proxy.
• IconPath, defines a location, even on a different server, where the standard icons can be found, when they don't reside in the ServerRoot directory.
• AddIconToSTD, it extends the standard icons by associating an icon to a certain MIME-type.
• AddBlankIcon, AddUnknownIcon, AddDirIcon, AddParentIcon, these are icon definitions for special icons.
• LogFileDateExt, specifies a common extension to all the log files based on a time/date format.
• LogTime, whether the log time will be in local or GMT time.
• NoLog, suppresses log entries for certain Hosts/Domains.
• OutputTimeOut, is the waiting period for responding to a request.
• ScriptTimeOut, this directive specifies the time to allow for server scripts to finish.

CERN provides also an HTTP proxy server. In that case the following additional variables define the proxy's behavior:

• CacheAccessLog, sets a different file than AccessLog for logging cache accesses.
• Caching, turns caching on.
• CacheRoot, set the cache directory.
• CacheSize, sets the maximum cache size in megabytes.
• NoCaching, URLs matching the specified template will not be kept in cache.
• CacheOnly, only the URLs matching the specified template will be kept in cache.
• CacheClean, specifies a template and time that the corresponding documents will be kept in cache.
• CacheUnused, sets the maximum time for keeping unused files that match the specified template.
• CacheDefaultExpiry, the maximum time that files with neither Expires: nor Last-Modified: header will be kept.
• CacheLastModifiedFactor, gives the fraction of time since last modification to give the remaining time to be up-to-date.
• KeepExpired, when this directive is set, expired files are removed only when their space is needed for new cache entries.
• CacheRefreshInterval, it gives the time for which the file is considered up to date, even if it has not expired.
• CacheTimeMargin, defines a time margin for cashing documents according to the time of the document retrieved, thus preventing time difference problems.
• CacheNoConnect, sets the proxy to standalone mode, which allows access only for documents that exist in cache and returns an error message for all other requests to the outside world.
• CacheExpiryCheck, when it is set, the server returns a document from cache, even if it has expired.
• Gc, can be used to deactivate the default garbage collection.
• GcDailyGc, it sets the time for garbage collection, even if the cache limit has not been reached.
• collectGcMemUsage, advises garbage collector about how much memory to use when reading information about the whole cache into memory.
• CacheLimit_1 and CacheLimit_2, set the lower and the higher limit for calculating the size factor of a file to be kept in cache.
• CacheLockTimeOut, sets the amount of time after which a file lock in the cache can be broken.

In the case that there is a need to make an (inner) proxy connect to the outside world via another (outer) proxy server the are the additional directives:

• http_proxy, ftp_proxy, gopher_proxy and wais_proxy, set the proxy that will be searched for each of the above type of requests.
• no_proxy, sets the server so that it should not connect to another proxy for certain URLs.

The file magnus.conf plays the same role as http.conf and srm.conf. The file obj.conf defines and uses objects to control how the server handles documents and other data objects published by the server on the web (html files, CGI programs, images, etc.). In magnus.conf

The various directives in the two files are as follows: magnus.conf

• ServerName, Port, User, identical to the NCSA variables.
• MaxProcs and MinProcs, set the number of maximum and minimum processes that are started by the server.
• ProcessLife, the number of requests served by each child process. It's the same as MaxRequestsPerChild in the Apache server.
• Errorlog, defines the file used for logging errors.
• PidLog, the same as PidFile in NCSA.
• LoadObjects, the startup object configuration file, defaults to obj.conf.
• RootObject, defines the server default object, loaded from an object file. The default object will have all the name translation directives that will affect the server's behavior (these directives are described with obj.conf).
• Chroot, confines the server's access to the specified directory only, for security reasons.
• Init, this directive is used, through the use of functions, for initializing various server subsystems. The functions supported and their parameters are:
  • load-types, maps file extensions to MIME types. The parameters it takes are:
    • mime-types, specifies the filename of the global MIME types file.
    • local-types, MIME types file that is used to maintain types applicable only to the server.
  • init-clf, it initializes the Common Log subsystem by opening files to be used for logging by the system. Which activities and messages will be logged in each file is specified in obj.conf. It takes as parameter at least one filename to be used for logging.
  • init-uhome, defines user home directories.
  • cindex-init defines characteristics of directory indexes (fancy indexing etc.). The parameters used are:
    • opts, specifies indexing options
    • widths gives the column width in the indexing printout.
    • ignore, wildcards for filenames to be ignored.
    • icon-uri, the directory that contains the icons for the indexing.
• DNS, specifies whether the server will use Domain Name Service lookups for connecting clients.
• Security, is a directive not available to all servers and specifies the type of security the server provides.

obj.conf

Object definition and description is done by subsectioning through the object directive. In these subsections the following directives are used:

• AuthTrans, defines the type of authorization checking that will be enforced for the object. The directive uses the function basic-ncsa that takes the parameters:
  • auth-type, for the type of authorization to be used.
  • dbm, the full path name for the file of the user database, in server's native format.
  • userfile, the full path name of the file of the user database, in the NCSA-style httpd format.
  • grpfile, the NCSA-style httpd group file to be used.
• NameTrans, translates a given URL to another that exists locally, or to another site. The functions used for these translations are:
  • pfx2dir, replaces path prefixes with directory names.
  • unix-home, it's the URL prefix that corresponds to user directories.
  • document-root, specifies the directory that contains all the documents. The parameter root is used for giving this root document directory.
  • redirect, changes certain URLs and returns them to the client updated.
  • home-page, gives the homepage of the server, through the use of the path parameter.
• PathCheck, performs a file system path check after the last of the NameTrans conversions. The functions that configure its use are:
  • unix-uri-clean, denies access to URLs that contain dangerous directory specifications (like /./, /../, and //).
  • find-index, determines if the requested path is a directory and then presents a listing or an index file.
  • require-auth, allows access to certain directories only through user or group authorization.
  • deny-existence, sends a "not-found" message if there is an access attempt for the specified path.
  • find-links, returns errors for symbolic or hard links in untrusted directories.
  • find-pathinfo, uses additional information if the server is unable to locate a file in a path.
• ObjectType, specifies how the MIME type of the file returned to the client will be determined. The ways used are set by functions and include typing by extension, wildcard pattern, by assignment of types to objects and server parsed HTML.
• Service, after all other conversions and checks have finished, it collects and broadcasts the requested information. the information broadcasted can be a text plain file, an error message, a text appended to all HTML documents, the results of CGI function, an imagemap, a simple or fancy directory indexing, or a parsed HTML document.
• AddLog, sets logging for a transaction in a file specified in the init-clf function in magnus.conf. Information that can be logged is request-specific data (server-log) and client software (record-useragent).
• Error, defines the type of error information that will be returned to the client upon an unsuccessful request and according to the type of error. It's similar to NCSA's ErrorDocument.

Netscape also provides an HTTP proxy server. In this case the configuration files are mainly the same, but there also is one additional configuration file, sockd.conf, that controls access through the possibly existent firewall and is mainly a list of deny/permit entries for hosts and users.

Also in magnus.conf file the init directive defines different functions, as follows:

• init-proxy, initializes the networking code used by the proxy. It takes the optional parameters:
  • timeout, the time interval between successive data packets from the remote server, after which the proxy will time out.
  • log-format, specifies whether any logging will be in the Common Log Format, or an extended format.
  • supress, sets a wildcard pattern for request header lines that should be filtered out fromt he request and not be forwarded to the remote server.
• init-cache, enables and initializes the cache. It uses the following parameters:
  • cache-root, specifies the directory under which the cache resides.
  • cache-size, the maximum allowed cache size
  • cache-protocols, defines a list of protocols that can be cached (HTTP, FTP and Gopher).
  • gc-times, set the times for garbage collection, by specifying a list of 24-hour clock times.
  • lock-timeout, the time after a hung cache lock can be broken.
  • top-dirs, is the number of top-level cache directories, under the cache root directory.
  • cache-mode, instructs the cache to either keep all documents, except the ones otherwise specified, or no document, except the ones otherwise specified.
  • max-ucheck, defines the time between up-to-date checks in the cache.
  • lm-factor, a floating point number used to estimate the document expiration date, based on its last-modified date.
  • gc-nice, the nice value, between 0 and 39 for the garbage collection process.
  • connect-mode, specifies the network connectivity to outside servers for loading of documents. This can be normal, fast-demo or never.
  • cover-errors, if this parameter is set and greater than zero, returns a document from the cache if the remote server is down and an up-to-date check cannot be performed, provided that the time since the last up-to-date check is not greater than the parameter value.
• init-sockd, enables and initializes the proxy behavior as a SOCKS daemon. The main configuration in this case is done through the default /etc/sockd conf file. Additional parameters are:
  • sockd-conf, specifies the configuration file for SOCKD configuration.
  • ident-check, defines the type of remote identity checking.
  • log-type, specifies the place and type of logs.
  • log-name, the absolute pathname for a separate logfile if one is used for logging SOCKS accesses.
• load-types, it is used initializing mapping of file extensions to MIME types. The parameters used are:
  • mime-types, it specifies the global MIME type file.
  • local-types, it specifies a MIME type file that is used for maintaining mime types applicable only to the server.
• init-clf, it initializes the Common Log subsystem. It takes as parameters filenames for the log files, defined in the obj.conf file.

Proxy Servers	W3C	Netscape
Cache AccessLog	X	init-clf
CacheClean	X
CacheDefaultExpiry	X
CacheExpiryCheck	X
CacheLastModifiedFactor	X	lm-factor
CacheLockTimeout	X	lock-timeout
CacheNoConnect	X	connect-mode
CacheOnly	X	cache-mode
cache-protocols		X
CacheRefreshinterval	X
CacheTimeMargin	X
CacheUnused	X
CachLimit _1 & 2	X
CasheRoot	X	cache-root
CasheSize	X	cache-size
Cashing	X	init-cache
CollectGcMemoryUsage	X
ftp_proxy	X
Gc (garbage collection)	X
GcDailyGc	X	gc-times
gopher_proxy	X
http_proxy	X
init-proxy(log-format)		X
init-proxy(timeout)		X
KeepExpired	X
no_proxy	X	supress
NoCaching	X	cache-mode
top-dirs		X
wais_proxy	X

Most configuration variables supported by the majority of the http servers should be included in the MIB and / or used in the instrumentation of the agent implementation. For example parameters of importance that should be used: log file location (error log, access log), server PID file, user and group id, server name, server port number, document root directory, server type (standalone or not), maximum server processes/connections, caching parameters, etc.

FTP

The WU ftp daemon uses both command line options and various configuration files.

The command line options are:

• a: puts the daemon to use the ftpaccess file (default).
• A: prevents the use of ftpaccess file.
• l: sets ftp session logging to syslogd.
• L: the daemon is set to log all USER commands that are used for changing identity during an active session.
• i: sets ftpd to log all incoming files in the xferlog file.
• o: sets ftpd to log all outgoing files in the xferlog file.
• t: sets the servers inactivity timeout period.
• T: sets the maximum client-requested timeout period.

There are also the following configuration files:

• ftpconversions, this file defines relations between filename extensions of files in the server and conversions that can be executed on them, upon request of the client and before downloading (e.g. compression based on client-requested suffix, etc.).
• ftpaccess, it instructs the server on how to handle certain classes of users, defined there, specifies messages that will be displayed and controls the daemons behavior. The main commands used in this file are:
  • class, defines user classes, that can any of the three types, real, anonymous or guest and groups particular hosts and/or domains, thus categorizing client requests from these sites.
  • deny, it specifies certain IP addresses or domain from where connection is implicitly denied. It can also specify the messages that will be displayed upon denial of the request.
  • limit, it limits the users of a particular class that can be serviced at certain times or dates, together with messages to be displayed upon denial of connection.
  • loginfails, it sets the maximum number of login failures before disconnection.
  • tar, compress, they allow or restrict certain user classes to use these conversion utilities that normally can be used before downloading a file.
  • chmod, delete, overwrite, rename umask, like above they allow or restrict certain classes of users from using these command on the server's files.
  • passwd-check, determines levels of requesting and checking passwords on anonymous logins. Possible options include no checking, trivial or rfc822 compliant and either enforcing or just warning the user.
  • guestgroup, it names one or more UNIX groups whose members are guest users, that is they have more access than anonymous users but still less than normal users of the system.
  • autogroup, set the group id of the anonymous users that belong to particular classes, thus giving them a higher degree of access.
  • private, when it is set, it allows the users to change their effective group, at the time of a session, using the `site group' and `site gpass' commands that accordingly access and authenticate the user for the new group.
  • banner, gives a path and filename that contains messages displayed to every archive user, before he logs in. In this file certain macros can be included, that are replace, during display, by actual information.
  • message, it specifies a path and filename that contains a message and associates it with a certain user action, namely logging in, or changing to a particular directory. When this action takes place, the message is displayed.
  • readme, it associates a filename with a certain user action, and provides a warning to him each time the action takes place, provided that the file has been updated.
  • shutdown, it specifies a filename that is used for configuring shutdown behavior. When the daemon discovers the existence of this file, it uses the information there that tells him, when to start denying access, when to log out any users and the messages that will be displayed. The message can accept macros.
  • log, it specifies, the kind of actions (commands, transfers) that will be logged for any of the types of users (real, anonymous, or guest). In the case of the commands, they are logged in syslogd. The transfers can be of a particular direction (inbound, outbound) and they are logged in the default file, xferlog.
  • alias, it is used for defining aliases for directories that the users access by the cd command.
  • cdpath, many such commands create a list of directories that will be searched when the user issues a cd command.
  • upload, it determines the directories where anonymous users can upload files to. It makes it possible to deny, or allow uploading access for directory hierarchies and specific directories inside them, it sets the user and group id and the permissions uploaded files will have. Finally it is possible to disallow the creation of new directories in this hierarchy.
  • path-filter, limits the pathnames that users of a particular class can specify, for their uploaded files.
• ftphosts, sets access restrictions for particular domains, defined there. It mainly consists of deny and allow directives that specify the various hosts for which the restrictions are to be applied.

Configuring the ftpd daemon is only one step in the process of setting up and maintaining an ftp site. Other tasks are also needed, from simple ones, like setting up the user id for running the server to more complex procedures of maintaining the published information under a "clean" directory structure with searching support.

• An ftp user has to be created at the system level (e.g. an entry in the /etc/passwd file for UNIX systems) in order to support anonymous ftp. For security reasons the ftp user should have a unique user id (and group id) and should not be allowed to log in through standard system utilities (like telnet and rlogin). The login directory is also important since anonymous ftp user access should be restricted; it should be owned by root and should be readable and executable by all users (mode 555).
• The ftp directory structure should include in the top level at least the following directories:
  • The bin directory includes all executable files that ftpd needs for servicing anonymous users. It should be owned by root and be executable, but unreadable and unwritable, by all users.
  • The etc directory contains a password file (not a copy of the system passwd file, as a security precaution) that the daemon uses to determine access privileges to restricted information. A group file is also included. Executables in the bin directory (like ls) use this password and group files for mapping uid and gid values to names and display ownership of offered files to the clients.
  • The pub directory contains the files made available to the outside world. It should be owned by root or the user responsible for maintaining the offered files. The whole structure hanging below this directory should be readable and executable by all users. If the archive allows user uploading some sub-directories (e.g. an optional incoming sub-directory) should be writable by all users.
• A useful concept offered by FTP is the sublogin. Sublogins are password-protected identities that anonymous users can assume to gain access to restricted parts of an FTP archive. Sublogins are defined in the password file in the ftp directory structured mentioned above. When sublogins are defined, restricted areas in the archive may be defined by changing ownership and access privileges of files and directories. Notice that sublogins provide limited security since the FTP password file is readable by anonymous users and anyone may download it and crack it off-line. An extended version of the sublogin concept is the class definition supported by the WU Ftp server discussed above.

The configuration of the server is straightforward since nearly all configuration parameters are passed to the server executable through the command line syntax. Configuration files are used only for access control. Some server profile parameters are also set at the package building phase (editing of source header files). The command line parameters of the freeWAIS server that are associated with configuration are the following:

• p [ port ] : defines the port that the daemon listens to. If no port is supplied, then the Z39.50 port (210) is used. This option is used only when the server runs standalone; in the inetd case the port is defined in the configuration file of the superserver.
• s : listen to standard I/O for queries. This is essential when the server runs through inetd.
• d directory : Use this directory as the default location of the indexes. For example if the directory were /usr/local/wais, then the database DB would be found in /usr/local/wais/DB.
• e [ filename ] : Redirect error output to pathname, if supplied, or to /dev/null. Error output defaults to stderr.
• l log_level : Set logging level for the "-e" option. Currently only levels 0, 1, 5 and 10 are meaningful: Level 0 means log nothing (silent). Level 1 logs only errors and warnings (messages of HIGH priority), level 5 logs messages of MEDIUM priority (like client init info). Level 10 logs everything.
• u user : Set the server's user id to the user specified after attaching the tcp-port. This is only used if the server is started as root (if the Z39.50 port is used then the server has to run as root; when ports higher than 1023 are used no root privileges are required).

In addition to these parameters freeWAIS uses two configuration files for server and database access control, respectively. Both files are expected to live in the index file directory and their names are defined at compile time.

The server access control configuration file is used to limit access to the WAIS server to a particular set of hosts and its default filename is SERV_SEC. It should be readable by the user that the WAIS server runs as and writable only by authorized users (or just root). The file consists of entries in the following format:

   domain-name     [IP address]

The domain-name field specifies a host or a DNS zone that are allowed access to the server and potentially to all the resources brokered by the server. If the optional IP address field is supplied then the client can match either the domain name or the address. The WAIS server does not check if the two fields are the same.

The database security file controls access to individual sources offered by the server and its default file name is DATA_SEC. It has a similar form to the server access control file, using entries of the following format:

   source domain-name     [IP address]

Each line in the file grants access to the resource specified by the first field for a specific set of hosts defined by the next two fields in the same way as in the server security file; the source name may appear in multiple lines. Both files allow the use of wildcards for the domain-name and address fields.

The WAIS server offers to remote or local clients access to indexes and actual sources (files of various types) while the WAIS indexing application is responsible for creating and maintaining the search index files. Different kinds of index files are created according to the source file format and search that will be supported; WAIS understands more than 30 file types. Note that usually indexes are stored in different directories from the actual documents. Organizing a "clean" and secure structure is part of the WAIS configuration and maintenance task.

Gopher

As in the WAIS case, the Gopher server has many of its configuration parameters defined during compilation (requires editing of source header files). There is also a single all purpose configuration file that controls how the server works for the outside world. The gopherd.conf file (default file name) consists of lines with the "token:value" format. The most important tokens are the following:

• hostalias: defines the host name that the server returns to the client. This alias must also be recognized by the DNS server.
• access: implements access control to the resources offered by the Gopher server. Allows control of access to requesting files, ftp files, browsing directories and performing searches. This token uses the following format:

access: <host-name or ip-address> <access control string(s)> <session limit>

By supplying domain (or host) names and ip addresses sets of hosts can be defined. The default keyword may be used for setting the default access control. Multiple access lines can be inserted in the file for defining permissions for different sets of machines. There are four access control strings:

browse (!browse): allows (prevents) browsing of directories but not reading of files.

read (!read): allows (prevents) actual viewing of files.

search (!search): controls searching.

ftp (!ftp): controls the use of the server as a Gopher-Ftp gateway.

A limit of concurrent sessions can also be set, e.g. access: default browse, !search 15, defines the default access control policy and allows browsing, prevents searches and limits sessions to 15.

• BummerMsg: allows customization of the token sent to a client that tries to access a resource that it does not have permission to.
• viewext: configures extension recognition. The server determines the file types by comparing the filename extension to the viewext tokens. The format is as follows:

  viewext: <extension> <gopher type> <path prefix> <Gopher+ type>

  The second argument defines the Gopher type with one character (e.g. 0-9, s, I, etc.) for the extension stated in the first argument. The next argument is the server selector string, a single character used by server to quickly parse client requests (usually two values, 0 for text and 9 for binary files). The last argument is the Gopher+ type for the document and it is used by the client to determine the viewing application required to launch for the document.

• ignore: defines case-sensitive extensions that should not be presented to the clients.
• ignore_patt: similar to ignore but uses regular expressions.
• decoder: used to define decoder for applying on specific extension files before sent to the client.

The most important configuration command line options of Gopher are:

• l: for specifying a log file
• u: set the user with whose privileges the server runs
• f: for specifying the configuration file that the server will use
• L: set maximum connection limit

Figure 10: The architecture - MIBs and agents

At the second level, the DM / RMMA component plays the dual role of the SNMP manager and agent: it acts as a manager from the isnMIB point of view by polling the MIB and implementing a set of management functions, while it behaves as an agent for higher level managers. The DM/ RMMA management functions produce a set of QoS parameters and other management objects that are mapped directly to the MIB objects of the ismMIB. These objects provide the semantics of the interaction between the manager components.

This three-level hierarchy may be generalized to include more levels by allowing a DM/ RMMA to be responsible for a domain of agents and other DM/ RMMAs. In this case, a hierarchical mesh of MIBs (isnMIBs and ismMIBs) is built with isnMIBs at the leaves and ismMIBs at the higher levels. Notice that a node may maintain both the isnMIB and the ismMIB if it hosts a DM/ RMMA and a managed IS entity. Figure 11 presents such an example.

Figure 11: Architecture overview - an example

• the ismSystem group
• the ismStatistics group
• the ismSummary group
• a set of notifications

The ism Managed-Application table (ismMappTable), on the other hand, maintains "look-up" information at the application level. For each IS entity the table maintains an entry with the host address, the isnMIB entity table index, the protocol role of the entity and the availability (up, down, unknown). Higher level managers may acquire through this table an overview of the entities of the domain and their current operational status; detailed information may be retrieved directly from the corresponding agent (isnMIB).

ismStatistics group

The ismSystemQosTable maintains system level QoS statistics for all nodes hosting managed entities/applications. The table is indexed by the system ip address which the manager acquires by the ismMappTable. The table includes the system and memory utilization, as well as the average downtime. The refresh period for these data is settable by the manager.

The ismEntityQosTable provides QoS statistics for every entity in the managed domain. This information includes: the average entity downtime, the current number of connections, a load percentage, average daily number of connections, throughput in bytes/sec and error rate. Sampling and refresh periods are settable by the manager.

A set scalar objects included in the group provide overall (average or total) domain statistics: total domain connections for all entities, average raw throughput (in bytes/sec) and error rate.

ismSummary group

The behaviour of each alarm/ monitoring procedure is specified in the ismSummaryEventTable. Each entry in the table defines an event that is triggered by the procedure. A triggered event fires a notification, creates a log entry (in the ismSummaryLogTable) or both.

Alarm procedures are defined by adding entries in the ismSummaryAlarmTable. Each entry corresponds to a different threshold alarm characterised by the following parameters:

• an object from the isnMIB of a specific entity in the domain,
• an alarm function (actual value, throughput, average) that is applied to the object before checking the thresholds,
• a sampling period,
• low and high thresholds for activating the alarm,
• the associated event to trigger when the alarm activates,
• last monitored value for the alarm function (sent with the notification, logged or polled at any time), and
• the address of the owner of the alarm (the manager that should receive any notification).

Monitoring procedures are set by adding entries to a similar table, the ismSummaryMonitorTable. Each monitoring procedure (entry) includes the following parameters:

• an object from the isnMIB of a specific entity in the domain to monitor (the monitoring procedure may apply to all entities in the domain),
• a monitoring function (actual value, throughput, average) that is applied to the monitored object values,
• a sampling Ts and report Tr period (the value is sampled every Ts time units for calculating the function; the monitoring event is triggered every Tr time units),
• the associated event for handing the monitored data,
• last monitored value (sent with the notification, logged or polled at any time), and
• the address of the owner (the manager that should receive any notification).

The ismSummaryLogTable provides the "log" to the triggered events for storing log entries (alarms or monitored values). Each entry corresponds to an activated alarm or event procedure and includes:

• the respective entity of the domain,
• an alarm or monitor index that produced the log entry,
• the date, and
• the value of the procedure at the time of activation.

• ismEntityDown is an unconfirmed notification generated by the DM/ RMMA when an entity changes state from up to down.
• ismEntityUp is an unconfirmed notification generated by the DM/ RMMA when an entity changes state from down/ unknown to up.
• ismAlarmNotify is an confirmed notification used to transport alarm information to the owner of the triggered alarm procedure. It is generated upon activation of an alarm.
• ismMonitorNotify is an confirmed notification used to transport monitor information to the owner of the procedure. It is generated every time the monitoring procedure has to report something (report period).

Figure 12: Adopted MIB structure

We present some additional guidelines for MIB authoring.

1. Objects should be put into logical groups. For detailed arrangements, hierarchical sub-grouping should be used.
2. Aggregate objects should be defined as tables. One or more columns of the table are designated as the indices of the rows in the table. Tables can not defined within tables.
3. Before a table that allow row creation and deletion, there is always an object (xNextEntry) that contains the index number of the first unassigned entry in the table. The RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of RFC1902). The status column has six defined values: `active', which indicates that the conceptual row is available for use by the managed device; `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device; `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device; `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device; `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
4. A management station should create new entries in this table using the following algorithm: first, issue a management protocol retrieval operation to determine the value of xNextEntry; and, second, issue a management protocol set operation to create an instance of the xRowStatus object setting its value to createAndGo or createAndWait. If this latter operation succeeds, then the management station may continue modifying the instances corresponding to the newly created conceptual row, without fear of collision with other management stations.
5. It is useful to define textualconventions.
6. At the phase of the implementation the AGENT-CAPABILITIES macro should be used to convey the set of capabilities present in the entity acting in an agent role. The AGENT-CAPABILITIES macro allows an agent implementor to describe the precise level of support which an agent claims in regards to a MIB group.

For the management of distributed information services the following textual conventions are defined or used as is:

TruthValue FROM SNMPv2-TC

TimeStamp FROM SNMPv2-TC

DisplayString FROM SNMPv2-TC

DateAndTime FROM SNMPv2-TC

Tools Used

SMICng has the capability to check MIBs at varying levels of strictness. The checking level is controlled with command line switches, compiler directives, or with options specified in an environment variable. Output from SMICng is specified with command line switches and includes the following: internal data structures used for debugging or analysis by sophisticated MIB developers; an intermediate file to be used by other programs; MOSY version 7.1 output, both .defs and .tcl files (MOSY is a popular SNMP MIB compiler); a list of object name to object identifier assignments and a list of defined traps; a list of object identifier to name assignments, and an SNMPv1 MIB from an SNMPv2 MIB. Programs can be easily written to read one of the outputs from SMICng and then create a new output format. The README file contains information about the components of the SMICng package.

APPENDIX D: MIB ASN.1 Description